Imagine you are looking up the progress of a loan request you sent in. You have logged into your account. This is your specific application, so you have permission to view it.
The API confirms that you own this record and then sends back the information. However, the reply also contains
internal_risk_scoreandunderwriter_notes. These two data points were always intended solely for the underwriting department. No one questioned if you, as the applicant, should specifically see those particular details. The API simply checked if you possessed the record and went no further.
This difference between “can you access this object” and “can you access this precise piece of information within it” is what BOPLA describes. Broken Object Property Level Authorization holds position API3 on the 2023 OWASP API Security Top 10 list, and once you recognize this issue, you begin to notice it everywhere.
So a short description of What Is BOPLA? – Broken Object Property Level Authorization (BOPLA) is an incident that occurs when an API fails to enforce permissions on individual object properties, allowing unauthorized users to view or modify sensitive fields.
Two Failures, One Root Cause
The issue appears in two forms, which are really the same mistake in different guises.
When a system reads too much, you get the earlier loan example: a response that delivers the entire internal record because, at the time, filtering it field by field seemed like too much work. While the frontend might only display three specific fields, all other data remains in the raw response, accessible to anyone who checks a browser’s network tab.
If a system writes too much, the problem goes the other way. Suppose someone updates their own display name, and the request also contains a field that manages account permissions. If the API simply maps whatever data arrives in the payload directly onto the record without verifying field by field what changes are actually permitted, that update will go through without issue.
This is especially common with frameworks that allow direct binding of a request body to a database object with a single line,offering a convenience that precisely bypasses the necessary checks for BOPLA prevention.
It Is Not as New as the Name Suggests
BOPLA is not a new idea. The 2023 OWASP list combined two issues that were separate in 2019: Excessive Data Exposure and Mass Assignment. Grouping them makes sense, as they almost always represent the same basic flaw, appearing on either the reading or writing end of the same system point.
BOPLA Is Not Just a REST Problem
Most discussions of this subject focus on REST examples, and that is reasonable. REST API endpoints typically return all data for an object automatically. This means simply looking at the response is usually enough to identify information that should not be there. GraphQL operates differently. A client must specifically name each field in its query; therefore, a hidden property will only appear if someone explicitly asks for it.
This might suggest GraphQL is the safer choice, and in a narrow sense, it does mean less accidental over-fetching of data. However, it does not solve the problem, only shifts it. GraphQL schemas are frequently self-documenting through introspection. This means the complete list of fields a type exposes, including ones not intended to be accessible, is often readily available for querying. Finding a sensitive field takes just one more step than with REST, which provides it automatically, and tools quickly bridge that step. The failure remains the same, just reached through a different path.
Closing the Gaps Caused By BOPLA
The solution is about treating two questions as separate : whether you own an object, and whether you should be able to view or modify a particular field on it. Practically speaking, this means creating responses using a clear list of allowed fields. You should avoid a general serializer that just outputs everything by default. A simple method like to_json() often allows you to bypass this necessary choice.
It involves checking write requests against the exact fields a role is permitted to modify, rejecting anything outside that specific list rather than quietly accepting it. Also, these rules need reviewing whenever an object gains new fields. Authorization often gets set up early when an object is small, and no one goes back to confirm if a new field has the same restrictions as the first one.
Why It Keeps Slipping Through
A BOPLA request does not appear unusual to an outside observer. It uses a proper login, a correct endpoint, and a correctly formed payload, meaning its traffic pattern that shows no irregularities. However, anyone examining the response content directly can quickly identify it, which makes inspecting responses important. Automated systems that only monitor for strange request patterns will completely miss this kind of activity.
APIs Under Attack, Prophaze Secures Every Call
Discover every API, block zero‑day attacks and bots, and enforce policies at scale without slowing your developers down.
