In January 2023, T-Mobile disclosed that an attacker had pulled data on 37 million customer accounts by abusing a single API starting in late November 2022 — no malware, no phishing, just an API endpoint that handed back more fields than it should have to a caller who shouldn't have been trusted with any of them. That pattern has a name now: Broken Object Property Level Authorization, or BOPLA, ranked API3:2023 in the OWASP API Security Top 10. It is one of the least understood and most frequently shipped API flaws, because it doesn't look like a bug at the object level — the API correctly checks whether you can touch a record. It just fails to check which fields inside that record you're allowed to read or write. That gap between "authorized to the object" and "authorized to the property" is where account balances get edited, admin flags get flipped, and private profile data leaks in bulk.
What Is Broken Object Property Level Authorization?
BOPLA occurs when an API authorizes a user to access an object but fails to restrict which individual properties of that object the user can read or modify. A support ticketing API might correctly confirm you own ticket #4521, then return every field on that ticket object — including an internal assigned_engineer_notes or customer_lifetime_value field never meant for the requesting party. OWASP formalized this in the 2023 API Security Top 10 by merging two categories from the 2019 list: Excessive Data Exposure (API3:2019) and Mass Assignment (API6:2019). Both are property-level failures — one on the read path, one on the write path — and OWASP grouped them because they share a root cause: authorization logic that stops at the object boundary instead of extending to the schema.
Why Did OWASP Merge Two Vulnerabilities Into One Category?
OWASP merged them in the 2023 revision because excessive data exposure and mass assignment are the same defect viewed from two directions. Excessive data exposure happens when an API response includes properties the client shouldn't see — commonly because a backend serializer dumps an entire database object (user.to_json()) and relies on the frontend to hide sensitive fields, a pattern OWASP explicitly calls out as unsafe since attackers can read raw API responses with a proxy like Burp Suite regardless of what the UI renders. Mass assignment is the write-side mirror: an API accepts a JSON body and binds it directly to an internal object, so a request meant to update {"nickname": "alex"} also succeeds when the attacker appends "role": "admin" or "account_balance": 999999, because the binding layer never validated which fields were writable. Treating them as one category (BOPLA) reflects that the fix is identical in both directions: define an explicit, per-endpoint allowlist of properties rather than trusting the object's full schema.
How Is BOPLA Different From Broken Object Level Authorization (BOLA)?
BOPLA and BOLA fail at different layers of the same authorization decision. BOLA (API1:2023, the OWASP API Security Top 10's number-one risk) is about whether a user can access a given object at all — the classic example is changing /api/orders/1001 to /api/orders/1002 and retrieving someone else's order because the server never checked ownership. BOPLA assumes the object-level check passed — you are legitimately viewing your own order — and asks whether every property returned or accepted on that object was appropriate for your privilege level. A billing API can be fully BOLA-safe (it correctly scopes orders to the authenticated account) and still be BOPLA-vulnerable if the order object it returns includes an internal supplier_cost field, or if the PATCH endpoint for that order accepts a status field that lets a customer mark their own order "refunded" without staff involvement.
What Do Real-World BOPLA Breaches Look Like?
Real-world BOPLA incidents typically involve API responses or update endpoints that expose far more of an internal object than any client-side control implied. The Peloton API disclosure in January 2021 is a textbook case: researchers at Pen Test Partners found that Peloton's API returned full user profile data — age, weight, city, gender, and workout history — for any account marked private, because the object-level privacy flag was enforced in the app UI but not in the API's property-level response filtering; Peloton didn't ship a fix until May 2021, months after initial disclosure. The USPS Informed Delivery API incident, reported by KrebsOnSecurity in November 2018, exposed data on roughly 60 million users because an authenticated account could query account-detail properties for arbitrary other users, and in some cases modify them, through the same endpoint. And while T-Mobile's January 2023 disclosure has been described in general terms as an API abuse case, the underlying mechanism — an API returning name, billing address, phone number, account number, and plan details to a caller with no business receiving bulk records — is the excessive-data-exposure half of BOPLA at massive scale: 37 million accounts.
Why Does BOPLA Slip Past Code Review and Standard Testing?
BOPLA slips through because the vulnerable behavior is invisible unless you inspect the raw API contract rather than the application UI. A functional QA pass, a manual pen test scoped to the web app, or a code reviewer scanning for missing @RequiresAuth decorators will all see an endpoint that correctly checks the user's session and correctly scopes the query to their own object — the object-level control looks fine. The defect only surfaces when someone diffs the full JSON schema an endpoint can return or accept against the subset the frontend actually uses, which most manual reviews skip because it requires knowledge of every downstream field, including ones added months later by a different team. This is compounded by ORMs and serialization frameworks that make it trivially easy to return or bind an entire model object with one line of code — the insecure default is also the fastest one to write, so it ships under deadline pressure and rarely gets revisited until a schema change quietly adds a new sensitive field to an already-exposed object.
How Can Teams Detect BOPLA Before It Ships?
Teams catch BOPLA reliably only by testing at the schema level, not the endpoint level — verifying, for every field in every response and request body, whether the current caller's role should see or set that specific field, rather than just confirming the endpoint responds with a 200 for authorized users. That means maintaining a source-of-truth data classification (which fields are internal, PII, or privileged) and running automated contract tests that fail the build when a new field appears in an API response without an explicit authorization rule attached to it. It also means banning direct-to-model serialization and mass-assignment binding (Model.update(request.body) or User(**request.json())) in favor of explicit DTOs or allowlisted schemas, since the former makes every new database column a potential exposure by default. Static analysis and API security testing tools that model authorization at the property level — rather than just confirming an auth check exists somewhere in the call path — are necessary because manual review, as shown above, structurally can't catch this class of bug at scale across a growing API surface.
How Safeguard Helps
Safeguard treats BOPLA as a software supply chain and dependency-hygiene problem as much as an application-security one, because most property-level exposure originates in generated or auto-serialized code paths pulled in from frameworks, SDKs, and internal libraries that teams don't fully audit field-by-field. Our platform continuously inventories the API surface across your services, mapping every endpoint's actual request and response schema against the fields your code paths reference, so a new property silently added to a serialized object — the exact mechanism behind incidents like Peloton's — gets flagged before it reaches production rather than after a researcher finds it. Safeguard's policy engine lets security teams define allowlists for sensitive object properties (PII fields, financial data, privilege flags) once, then enforces them automatically across every service and pull request that touches those object types, closing the gap where mass-assignment bindings quietly accept fields like role or isAdmin that were never meant to be client-writable. Because BOPLA is fundamentally a drift problem — schemas evolve faster than the authorization logic wrapped around them — Safeguard's continuous monitoring re-evaluates API contracts on every deploy, not just at initial review, so the fix holds even as your API surface keeps growing.