Contact
← Project case studies

Membership-based
service platform

We assessed authentication, access control and API responses, then verified remediation through follow-up assessments.

Project overview

Objective
Verify cross-user data access and the scope of credential validity
Scope
Login and logout · User-specific permissions · Profile API
Deliverables
Vulnerability reproduction steps and evidence, remediation recommendations and follow-up assessments

Testing the boundaries between user permissions and data.

We used separate test accounts to check whether one user could access another user's data. We also examined authentication handling after logout and the information returned by the API.

  • Another account's information exposed by changing a user identifier
  • Validity of existing credentials after logout
  • Unnecessary personal data and authentication-related fields in API responses

Client and product identifiers have been removed. Technical examples have been reconstructed for explanation and reflect observations made during a past assessment. They do not indicate the client's current security status or whether remediation has been completed.

Assessment details

Select an item to review the assessment process and technical evidence.

Access control between users
01ACCESS CONTROL / IDOR · BOLAAnonymised reconstructed case

Changing a user identifier
exposed another account's information.

When a logged-in user changed the target identifier in a request, the server returned information belonging to another account that the user was not authorised to access.

Risk and impact

A feature intended to show only the user's own information exposed other users' personal data. This information was accessible with ordinary user permissions.

Assessment method

We created separate test accounts A and B and requested B's data using A's credentials. We checked whether the server rejected unauthorised requests independently of the menus shown in the interface.

Remediation guidance

We recommended checking data ownership, sharing relationships and user roles on every request. Making identifiers harder to guess does not, by itself, resolve an access control issue.

RETEST CRITERIA

Retest criteria

Verify that requests from accounts without access are rejected, while requests from the owner or authorised users are processed normally.

Authentication handling after logout
02AUTHENTICATION / SESSION LIFECYCLEAnonymised reconstructed case

After logout,
existing credentials remained valid.

The interface showed the user as logged out, but the server did not invalidate the existing credentials.

Risk and impact

If credentials are stolen, unauthorised access may continue after the user logs out. The interface transition and server-side authentication handling must be checked for consistency with the logout policy.

Assessment method

We recorded a protected request while logged in, then sent it again with the same credentials after logout. We examined responses separately according to account status and authentication method.

Remediation guidance

We recommended defining session policies for logout and account deactivation, and checking credential validity on the server. We also recommended reviewing issuance, renewal and expiry handling.

RETEST CRITERIA

Retest criteria

Verify that credentials designated for invalidation on logout are rejected. A legitimate account that logs in again must remain usable.

Information disclosure in API responses
03API SECURITY / DATA EXPOSUREAnonymised reconstructed case

API responses contained
unnecessary personal data.

Although the interface displayed only selected information, server responses also included personal data and authentication-related fields that were unnecessary for the business function.

Risk and impact

Data sent to the browser can be read by the user even when it is not displayed in the interface. The server must restrict which fields it returns.

Assessment method

We compared the fields displayed in the interface with those returned by the API. We also checked whether unnecessary information appeared repeatedly in nested user objects and through different retrieval paths.

Remediation guidance

We recommended limiting responses to the fields needed for the feature rather than returning database objects directly. Authentication-related data should be explicitly excluded, and similar APIs reviewed as well.

RETEST CRITERIA

Retest criteria

Verify that unnecessary fields have been removed from related responses, including lists, details and search results, while information needed by the interface is still provided correctly.

Web & API penetration testing Sample assessment report (Korean)

Authentication and permissions, verified through actual behaviour.

We discuss the assessment scope based on your service's user roles and data flows.

Project enquiry
ANONYMISED / SAMPLE REPORT
FELSEN SECURITY / WEB ASSESSMENT

Security assessment
Sample report

An anonymised Korean-language excerpt following the format of an actual security assessment report. Client identifiers have been removed, and omitted passages are marked in the document.

Executive summary
Summarises the distribution of vulnerabilities and remediation priorities.
Scope and methodology
Specifies the assessment targets, validation methods and scope.
Detailed analysis excerpts
Explains missing HSTS headers and input format validation with sample responses.
Remediation guidance
Sets out the impact of vulnerabilities and the improvements required.

Korean · PDF · 8 pages · 739 KB

Download PDF Open in a new tab ↗

Anonymised and reconstructed from past assessment work. This does not describe a client’s current security status or confirm that remediation is complete.
PRIVACY NOTE

How inquiry information is handled

This site’s inquiry form does not send your entries to its own server or store them in browser storage. We do not use analytics tools or marketing cookies.

The email button opens your email app. You send the message yourself from that app. Include only the information needed for your inquiry, and do not send passwords, access tokens or actual client data.

Copying your inquiry and saving files take place on your device when you press the relevant button. The hosting provider may process connection information needed to operate the service.

For inquiries and requests to delete information: mingi.hong@gainge.com