API Data Exposure Review Lab
Most API data leaks are not clever attacks. They are a handler that returns the whole database row, or binds the whole request body to the model. That is OWASP API3:2023, Broken Object Property Level Authorization: excessive data exposure plus mass assignment. Here you are the reviewer on a fictional app's pull requests. Flag the fields this caller should not receive, flag the fields a client must not be able to set, pick the fix, and compare each PR with its fixed version. Includes GraphQL field selection, a "the frontend hides it" PR and clean decoys.
A defensive review exercise. Runs in your browser with synthetic data; nothing is sent anywhere. Free, including the Markdown checklist.
TL;DRWhat this lab is
5 points
- A code-review lab for OWASP API3:2023 Broken Object Property Level Authorization: the 2023 category that merged excessive data exposure and mass assignment.
- You review 5 to 7 seeded pull requests for a fictional marketplace. Each shows the serializer or schema code, a sample response, and for updates the fields the handler will write.
- Flag response fields the caller should not receive (password hashes, MFA seeds, reset tokens, internal notes, other users' emails, risk scores) and request fields a client must not set (role, verification, tenant, balance, price).
- Choose the fix: an allow-list DTO, separate read and write schemas, field-level authorization, OpenAPI readOnly with server-side enforcement, or gateway filtering (a weaker last line of defence). Some PRs are clean and should be approved.
- Scored on precision, recall and fix quality. The debrief shows every PR fixed side by side, and the Markdown review checklist is a free download.
The caller decides what is sensitive
The same field can be correct in one response and a leak in another. Internal notes belong in the support console and nowhere near the customer. Your own email is fine on your profile; everyone's email in a member list is not. A seller sets the price of their own listing; a shopper setting the price in the cart is the oldest e-commerce bug there is. Each PR names its caller, and the scoring punishes false alarms as well as misses, because a reviewer who flags everything gets ignored.
Fix it in the service, not around it
The durable fixes are an explicit allow-list serializer for responses and a strict write schema for requests, with field-level rules where roles differ. OpenAPI readOnly helps only when a server-side validator enforces it. Gateway filtering is a backstop that matches field names. To see what a gateway can and cannot enforce, try the API Gateway Config Lab; to catch missing readOnly and loose schemas in a spec, run the OpenAPI Gap Analyser; and to find the legacy routes that still return everything, the Shadow API Discovery Lab.
Frequently asked questions
What is OWASP API3:2023 Broken Object Property Level Authorization?
It is the third category of the OWASP API Security Top 10 2023. It covers two problems at the level of individual properties of an object: excessive data exposure, where an API returns fields the caller should not see, and mass assignment, where an API lets a caller set fields they should not control. The 2019 list had them as separate items (API3 and API6); the 2023 list merged them because the root cause is the same: no authorization decision per property.
What does the lab ask me to do?
You play the reviewer on a fictional app's pull requests. For each PR you read the code, mark response fields that should not reach that caller, mark request fields the client must not be able to set, and choose a fix or approve the PR. Some PRs are deliberate decoys: well-written changes with fields that look sensitive but are fine for that caller, such as your own email or a seller's own listing price.
How is the review scored?
35% precision (the share of your flags that were real problems), 35% recall (the share of real problems you flagged) and 30% fix quality, all across the whole run. The best fix earns full credit, a workable one half, and gateway filtering a quarter on a read-exposure finding because it is only a backstop. Clear 75% to pass. Difficulty and time then feed the shared PlayCISO grade.
Why is gateway response filtering a weaker fix?
A gateway filter strips fields by name after the service has already produced them. A renamed column (pwd_hash instead of passwordHash), a nested copy or a GraphQL alias slips past it, the data has still left the service, and it does nothing for mass assignment on writes. It is a useful backstop; the fix belongs in the service as an allow-list serializer and a strict write schema.
Is hiding a field in the frontend enough?
No. The full response is visible in the browser's network tab and in mobile app traffic, and anyone can call the API directly without your frontend. The lab includes PRs that rely on "the UI only renders these" and on a hidden role dropdown; both are exposures the server has to fix.
Does it cover GraphQL?
Yes. On Pro and Elite you review GraphQL schemas where the client chooses which fields to select, nested types reached through relations, and an input type shared between a user mutation and an admin mutation.
Is it free, and are the scenarios real?
The lab and the Markdown checklist export are free. Everything is synthetic and runs in your browser: the app, people, IDs and emails are invented (mail.example addresses and documentation IP ranges), and nothing is sent to any API.
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.