Attack a modern JSON REST API the way a bug bounty hunter does — hands-on, against a live target. Map the surface with automated scanning, then exploit the object-level logic flaws no scanner will find for you.
Modern applications are built on JSON REST APIs, and the most damaging bugs in those APIs are rarely about malformed input or a missing patch. They are about trust. An API can authenticate every request perfectly and still hand the wrong data to the wrong person, because authentication answers “who are you?” while authorization must answer “are you allowed to touch this?” When an API skips that second question, the door is open.
Two failures dominate this space. Broken Object Level Authorization lets an authenticated caller reach objects that belong to someone else. Mass assignment lets a caller set fields they were never meant to control by smuggling them into a request body the API trusts wholesale. Together they are the #1 and #6 risks on the OWASP API Security Top 10 — and they are the reason API security is its own discipline.
The endpoint confirms you hold a valid session, then serves whatever object you asked for — without ever checking that the object belongs to you. Swap in another identifier and the API cheerfully returns someone else's record. This is the single most common and most serious flaw in production APIs today.
When an API merges a client-supplied body onto a stored object with no field whitelist, it will happily write properties you were never supposed to set — including the privileged ones that govern roles and access. A benign-looking update request turns into a privilege-escalation primitive.
The OWASP API Security Top 10 is a separate list from the classic web Top 10, written specifically for the failure modes of JSON APIs. Object-level and property-level authorization flaws lead it — because they are pervasive, easy to introduce, and invisible to signature-based tooling. The impact classes below are what make them high-severity findings.
| OWASP API Risk | What the attacker gains | Severity |
|---|---|---|
| API1 — Broken Object Level Authorization | Read or modify other users' objects with a valid token | High |
| API6 — Broken Object Property Level Authorization | Set client-forbidden fields via mass assignment | High |
| Privilege escalation | Elevate a normal account to an administrative context | High |
| Broken authentication (context) | Weak session handling that amplifies the above | Medium |
The core lesson of Room 10 is that automation and human judgment are a pipeline, not a competition. An autonomous scan maps the attack surface in minutes — the exposed paths, the forbidden endpoints, the open ports. But object-level authorization and mass assignment are business-logic flaws: every request is well-formed and authenticated, so nothing trips a signature. Proving them means reasoning about who should own what — and that's the gap a human closes.
In the lab, you run a real PhantomRed scan against the DriftCard API, read the surface it surfaces, then take over manually to prove the logic flaws the scanner can't see:
This is the same object-authorization theme Room 5 introduced with a dedicated IDOR lab — Room 10 reframes it for the API world and chains it into a full privilege-escalation path.
The DriftCard lab is live and free to play. Run a real autonomous scan, then exploit the object-level logic flaws the scanner can't see — broken object authorization, then privilege escalation, end to end.