IDOR on CoinDepo: Unauthorized Access to User KYC Records
This writeup documents an Insecure Direct Object Reference (IDOR) vulnerability identified during independent bug bounty research against CoinDepo. The issue allowed an authenticated user to retrieve another account's Know Your Customer (KYC) information by manipulating identifier fields in a profile API request. The finding demonstrated a broken object-level authorization control affecting sensitive personal information, including identity details and references to uploaded identification documents. The vulnerability was reported through HackenProof and publicly disclosed. This research highlights the importance of enforcing server-side authorization checks and deriving account ownership from the authenticated session rather than trusting client-controlled request parameters.
IDOR on CoinDepo: Unauthorized Access to User KYC Records
Overview
During independent bug bounty research, an Insecure Direct Object Reference (IDOR) vulnerability was identified in CoinDepo's profile API. The endpoint relied on user-controlled identifiers to determine which account's information to return without adequately validating whether the authenticated user was authorized to access the requested account.
By modifying the relevant account identifiers in a profile API request, an authenticated user could retrieve information associated with another account.
The finding was reported through HackenProof and received a Critical severity rating in the public disclosure.
- Research Classification: Bug Bounty Research
- Target: CoinDepo
- Affected Endpoint:
POST /api/details - Vulnerability Class: Insecure Direct Object Reference (IDOR) / Broken Object Level Authorization (BOLA)
- Severity: Critical, as publicly disclosed
- Researcher: M1S0
1. Technical Background
Insecure Direct Object Reference (IDOR) is an access-control vulnerability that occurs when an application uses client-controlled identifiers to retrieve resources without properly verifying the requesting user's permissions.
In API-driven applications, these identifiers may reference user profiles, financial records, identity documents, or other sensitive objects.
The underlying issue is not simply that an identifier can be modified. The vulnerability exists when the server processes a request for an object without validating that the authenticated user has permission to access it.
Broken Object Level Authorization (BOLA), identified as a major API security risk by OWASP, describes this broader class of authorization failure.
2. Vulnerability Details
The affected functionality used the POST /api/details endpoint to retrieve account profile information.
The request included client-controlled fields such as email and username, alongside other request parameters. The backend did not adequately bind the requested account to the authenticated user's identity.
As a result, changing the account identifiers in the request could cause the endpoint to return profile information associated with another account.
This behavior demonstrated insufficient server-side object-level authorization.
Affected functionality: Profile and identity-verification information retrieval.
Security weakness: The backend relied on client-supplied account identifiers without adequately verifying the authenticated user's authorization to access the corresponding records.
3. HTTP Request and Response Evidence
The following examples illustrate the request structure and the authorization failure. They are sanitized representations, not verbatim captures of the original traffic. Replace them with verified evidence before publication.
3.1 Request
The affected endpoint was observed using an HTTP POST request with multipart form data.
POST /api/details HTTP/2
Host: app.coindepo.com
Content-Type: multipart/form-data; boundary=----boundary
------boundary
Content-Disposition: form-data; name="username"
<SECOND_TEST_ACCOUNT_EMAIL>
------boundary
Content-Disposition: form-data; name="email"
<SECOND_TEST_ACCOUNT_EMAIL>
------boundary
Content-Disposition: form-data; name="client_token"
<VALID_TEST_SESSION_TOKEN>
------boundary
Content-Disposition: form-data; name="cdkey"
<REDACTED_REQUEST_KEY>
------boundary--
The request was evaluated using an authenticated test account. The account identifiers were modified to reference a second account controlled by the researcher.
Authentication tokens, request keys, and account information must remain redacted in public evidence.
3.2 Response
The observed behavior was that the endpoint returned profile information associated with the referenced account rather than adequately restricting access to the authenticated user's own records.
The following JSON illustrates the types of fields involved. It is a representative example and should not be treated as an exact captured response.
{
"user_id": "<REDACTED>",
"email": "<REDACTED>",
"first_name": "<REDACTED>",
"last_name": "<REDACTED>",
"date_of_birth": "<REDACTED>",
"phone": "<REDACTED>",
"address1": "<REDACTED>",
"city": "<REDACTED>",
"state": "<REDACTED>",
"zip": "<REDACTED>",
"document_type": "id-card",
"document_photo1": "<REDACTED_DOCUMENT_REFERENCE>",
"document_photo2": "<REDACTED_DOCUMENT_REFERENCE>"
}
The exposed data fields included personal profile information and references to uploaded identity documents.
3.3 Security Observation
The important observation was that the endpoint returned information belonging to a different test account without adequately enforcing account-level authorization.
The issue was therefore an authorization failure, rather than merely the disclosure of an account identifier.
Evidence note: Include the actual HTTP status code, response body, and screenshots from your original testing only after verifying them against the original request and response captures.
4. Proof of Concept
The behavior was validated using two test accounts controlled by the researcher.
- Authenticate to the application using the first test account.
- Navigate to the relevant profile or email-verification functionality.
- Intercept the request to the profile API endpoint.
- Identify the account-related parameters in the request.
- Modify the relevant identifiers to reference the second test account.
- Submit the modified request.
- Compare the returned information with the permissions expected for the authenticated account.
The endpoint returned profile information associated with the referenced account, demonstrating that the application did not adequately enforce account-level authorization.
Testing was conducted using researcher-controlled accounts to validate the cross-account access condition.
5. Information Exposure
The affected functionality exposed profile and KYC-related information, including the following categories of data, as applicable to the observed response:
- Full name
- Date of birth
- Phone number
- Residential address
- Account-related identifiers
- References to uploaded identity documents
The combination of personal information and identity-verification data can create significant privacy and security risks if accessible to unauthorized users.
Document references may also introduce additional exposure if the corresponding resources can be retrieved without independent authorization checks.
6. Security Impact
The vulnerability could allow an authenticated user to access sensitive information belonging to other users, depending on the identifiers available and the records accessible through the affected endpoint.
Potential consequences include:
Unauthorized disclosure of personal information: Exposure of personally identifiable information can violate user privacy and confidentiality.
Identity-related fraud: Personal details and identity-document information may be misused for impersonation or fraudulent activity.
Targeted social engineering: Information from user profiles can make fraudulent communications more convincing.
Cross-account data exposure: If the same authorization weakness affects multiple records, the impact may extend beyond a single account.
The finding received a Critical severity rating in the public disclosure. The precise severity should be understood in the context of the original program's assessment and the impact demonstrated during testing.
7. Root Cause Analysis
The underlying issue was insufficient server-side object-level authorization.
The backend relied on account identifiers supplied by the client without adequately verifying that the authenticated principal was permitted to access the requested records.
Authentication confirms the identity of a user; it does not automatically authorize that user to access another account's profile or identity documents.
The application should have enforced the authorization decision on the server for every requested object, independently of the values supplied in the request.
8. Remediation Recommendations
8.1 Enforce Server-Side Authorization
Verify that the authenticated user has permission to access the requested profile or KYC record on every request. Deny unauthorized cross-account access by default.
8.2 Bind Account Access to the Authenticated Identity
Derive the requesting user's identity from the validated session or authentication token. Do not treat client-supplied email addresses, usernames, or record identifiers as proof of ownership.
8.3 Apply Authorization Checks to Related Resources
Enforce independent authorization checks for identity documents, profile attachments, verification records, and related API endpoints. Protecting the profile endpoint alone is insufficient if associated resources remain accessible.
8.4 Minimize Returned Data
Return only the information necessary for the requested operation. Avoid including sensitive KYC fields in responses that do not require them.
8.5 Add Authorization Regression Tests
Implement automated tests that attempt cross-account access using separate test users. Include profile retrieval, account updates, identity-document access, and other endpoints that operate on user-owned objects.
9. Key Takeaways
This finding demonstrates how insufficient object-level authorization can expose sensitive records even when an application requires authentication.
The central security requirement is straightforward: every request for a protected resource must be authorized against the identity and permissions of the current user.
For security engineers and API developers, systematic cross-account authorization testing is an essential part of assessing applications that process personal information, identity documents, and other sensitive records.
10. Disclosure Context
This issue was identified through independent bug bounty research and reported through HackenProof.
It is published here as a researcher-led bug bounty finding for educational and defensive security purposes. It was not identified during a Pickel OffSec client engagement, and it should not be interpreted as a client assessment or authorization to test the target.
The publication presents the technical issue, its security implications, and recommended defensive measures while distinguishing independent vulnerability research from commissioned penetration-testing work.
References
- OWASP API Security Top 10 — Broken Object Level Authorization: https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
- OWASP IDOR Prevention Cheat Sheet: Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet
Pickel OffSec Offensive Security Research
Independent research. Reproducible findings. Actionable remediation.