🔒 Academy Room 10 · Hard

API Security — BOLA & Mass Assignment

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.

⚡ Start the API Security Lab Build a free API test plan How it works →
// Overview

What Is API Object-Level Security?

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.

// Why It Matters

Real-World Impact

Broken Object Level Authorization

Read data that isn't yours

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.

Mass Assignment

Become something you shouldn't

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.

// OWASP

Where These Sit in the OWASP API Security Top 10

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 Workflow

How PhantomRed Fits Into an API Assessment

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:

Autonomous scan maps the surface exposed paths, forbidden endpoints, open ports
↓
Human finds the object-level authorization gap an authenticated route that never checks ownership
↓
Manual exploitation escalates privilege read another user's object, then abuse mass assignment

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.

// What You'll Learn

Learning Objectives

Concepts

  • Why authentication and authorization are different guarantees
  • How object-level and property-level authorization fail in APIs
  • How BOLA and mass assignment map onto the OWASP API Top 10

Hands-On Skills

  • Reading a scan report to map a JSON API attack surface
  • Reaching another user's objects through a missing ownership check
  • Escalating privilege by abusing an over-trusting update handler
// FAQ

Frequently Asked Questions

What is Broken Object Level Authorization (BOLA)?
BOLA is an API vulnerability where an endpoint verifies that a caller is authenticated but never checks that the specific object they requested actually belongs to them. A valid token plus another user's object identifier is enough to read or modify data that was never theirs. It is the #1 risk on the OWASP API Security Top 10.
What is mass assignment?
Mass assignment happens when an API merges a client-supplied JSON body onto a stored object without a field whitelist. An attacker can include fields they were never meant to control — privileged flags, roles, ownership — and the API trustingly writes them. It maps to the property-level authorization risk on the OWASP API Security Top 10 and can lead directly to privilege escalation.
Are BOLA and mass assignment in the OWASP Top 10?
Yes — both sit on the OWASP API Security Top 10, which is distinct from the main web Top 10. Broken Object Level Authorization is API1 and mass assignment falls under API6 (Broken Object Property Level Authorization). They are the two most common object-level logic flaws in modern JSON APIs.
What is the difference between BOLA and IDOR?
IDOR (Insecure Direct Object Reference) is the classic web term for accessing objects you shouldn't by manipulating an identifier. BOLA is the API-focused framing of the same root cause: missing object-level authorization. In practice the terms overlap heavily — BOLA is simply how the OWASP API project names the object-authorization failure that IDOR describes.
Can an automated scanner detect BOLA or mass assignment?
Not reliably. Scanners are excellent at mapping attack surface such as open ports, forbidden paths, and exposed files, but object-level authorization and mass assignment are business-logic flaws. Every request is well-formed and authenticated; nothing matches a signature. Finding them requires understanding who should own what, which is human work. PhantomRed maps the surface automatically and the human closes the gap — that workflow is the core lesson of the room.
How do you prevent BOLA and mass assignment?
For BOLA, enforce an object-level ownership check on every request — confirm the authenticated caller is authorized for the specific object, not just logged in. For mass assignment, bind incoming JSON to an explicit allow-list of writable fields and reject everything else, so privileged properties can never be set by a client. Both defenses come down to never trusting the caller beyond what they are provably allowed to do.
// Related

Related Rooms & Guides

Room 5
IDOR & Broken Access Control
Room 9
XML External Entity (XXE) Injection
Academy
All Phantom Academy Rooms
Guide
Autonomous Penetration Testing
Framework
Bug Bounty Automation Framework
Fundamentals
Reconnaissance vs Enumeration
// Get Started

Practice API Security Against a Live Target

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.

⚡ Open the API Security Lab Start a Free Scan →