A policyholder could read and approve claims

Insurance

A claims portal let policyholders file and track claims. We were asked whether one policyholder could reach another's records, and whether the approval step could be reached from the wrong side.

Web & API penetration test, Insurance platform, severity CRITICAL, reported 2024

At a glance

• Challenge. A claims portal checked a valid session but not ownership or role, so a policyholder could read any claim and move any claim to approved.
• Approach. We used two policyholder accounts and asked, for each record and action, whether ownership and role were enforced on the object or only the request.
• Result. Ownership is enforced on the resolved record and the approval transition sits behind a server-side role check, then the surface was retested.
• Impact. A policyholder could read other policyholders' claims and approve their own, which is the ability to authorise a payout to themselves.
• Classification. CWE-862 Missing Authorization, OWASP API Security Top 10 (2023): API5 Broken Function Level Authorization. Component: Claim approval transition.

The challenge

An identifier in a request is a claim, not a credential. When the server returns the record named by the identifier without checking that the record belongs to the caller, the identifier becomes a key to every record, because identifiers are guessable in a way keys are not.

A second, quieter problem sits next to the first. Approving a claim is a state change that is supposed to belong to a different role. If the transition is guarded only by the screen the role usually sees, and not by the server that performs it, then anybody who can send the request can perform the transition.

Put together, a policyholder who can read any claim and move any claim to approved is a policyholder who can pay themselves. Each request looks ordinary. The fraud is in which requests are allowed to succeed.

Our approach

We used two policyholder accounts and asked, for each record and each action, whether ownership and role were enforced on the object being changed or only on the request being sent.

Around the two central findings we checked the surface that shared the assumption:

• Whether claim and policy records were scoped to the caller who owned them
• Whether the approval transition verified role on the server, not on the screen
• Whether document downloads on a claim carried the same ownership check as the claim
• Whether the sibling actions on a claim shared the weakness

Delivered with the two accounts, the requests and the resulting state, so each finding could be reproduced against a test tenant without taking our word for it.

From finding to fix

1. Mapped claim and approval actions
2. Read another policyholder's claim by id
3. Moved a claim to approved as the wrong role
4. Enforced ownership and role, retested

The outcome

Ownership is now enforced on the resolved record rather than on the presence of a session, so a policyholder can only read their own claims and policies. The approval transition was moved behind a server-side role check and the sibling actions were brought under the same rule.

We retested the claim surface and the approval path after the fix. Reported as CRITICAL in 2024. Retest included in the engagement.

Check your own system

• Check the caller's role on the server for every state change, not only on the screen that usually performs it.
• Scope each claim and policy record to the caller who owns it, and resolve ownership before returning data.
• Apply the same ownership check to document downloads attached to a claim as to the claim itself.
• Review the sibling actions on a record together, since they tend to share the missing check.

Read more case studies, see Web Application Penetration Testing, or write to hello@yaamlabs.com.