Broken Object Property Level Authorization occurs when an API validates that a user can access an object but fails to validate which properties of that object the user is allowed to read or write. Testing for it means enumerating every property on every object-returning or object-accepting endpoint and confirming, per property, that the authorization logic matches the intended access model. The gap most testers miss: property-level checks are often absent even when object-level checks (tested separately as API1:2023 Broken Object Level Authorization) are implemented correctly.
TL;DR
- BOPLA testing requires checking individual object properties, not just object ownership, across every read and write endpoint.
- API3:2023 merges the former Excessive Data Exposure and Mass Assignment categories into one property-level authorization defect.
- Manual diffing of API responses against role-based expectations finds property leakage that automated scanners routinely miss.
- Mass assignment testing requires injecting undocumented or privileged fields into write requests to confirm the server rejects them.
- CWE-915 is the primary weakness classification behind BOPLA write-side failures.
Why Property-Level Authorization Testing Matters
Object-level authorization tools and checklists are mature. Property-level authorization is not, and that gap is exactly where BOPLA lives. An API can correctly block a user from fetching another user's account object while simultaneously returning that user's own account object with an internal_credit_limit, kyc_risk_score, or is_admin field the frontend never renders but the response body still contains.
The business exposure is direct. In fintech and banking APIs, property-level leakage routinely exposes risk scores, account balances tied to other instruments, or compliance flags that were never meant to leave the backend. In SaaS platforms, it exposes tenant configuration, billing tier internals, or feature flags that reveal pricing logic to competitors scraping the API. On the write side, mass assignment lets an attacker set role, account_status, or discount_percentage fields that a form never exposes but the API endpoint silently accepts.
Auditors evaluating SOC 2 or ISO 27001 controls, and assessors mapping to PCI DSS requirement 6.2.4, increasingly ask for evidence that API testing covers field-level authorization, not just endpoint- or object-level checks. A pentest report that only confirms that users cannot access other users' records, without listing which fields were tested on each object, leaves a documentation gap most auditors will flag.
How to Test API3:2023 Broken Object Property Level Authorization
BOPLA testing is structured around two failure directions: excessive property exposure on read and improper property authorization on write (mass assignment). Both require a documented property inventory before testing starts.
Property mapping
- What You Do: List every property returned by every object-returning endpoint, across every user role
- Evidence to Capture: Full schema export per endpoint per role
Read-side diffing
- What You Do: Compare full API response against what the UI renders and what the role should see
- Evidence to Capture: Response body diffs, field-by-field
Write-side fuzzing
- What You Do: Inject extra, hidden, or privileged fields into POST/PUT/PATCH bodies
- Evidence to Capture: Request/response pairs showing accepted fields
Role escalation checks
- What You Do: Repeat property tests across every role tier (free, paid, admin, support)
- Evidence to Capture: Role matrix with pass/fail per field
Nested object review
- What You Do: Test properties inside nested objects and arrays, not just top-level fields
- Evidence to Capture: Nested schema coverage notes
Retest
- What You Do: Re-run the full property matrix after remediation
- Evidence to Capture: Before/after comparison
Follow this sequence for each endpoint under test:
- Extract the full schema. Pull the OpenAPI/Swagger spec if one exists; if not, capture every field from raw HTTP responses across authenticated sessions at each privilege level.
- Build a property matrix. List every field against every role the API supports. Mark expected visibility (visible, hidden, redacted) per cell before you test.
- Request as each role and diff the response. Any field present in the response but absent from the intended-visibility column is a candidate finding. This is where manual review outperforms automated scanners — a scanner flags status codes, not silent over-disclosure of a field like
stripe_customer_idsitting quietly in a 200 response. - Fuzz the write path. Take a legitimate PATCH or PUT request and append fields the UI never sends:
role,is_verified,credit_limit,tenant_id,subscription_tier. Submit and check whether the server silently applies them. - Test nested and array objects separately. BOPLA findings frequently hide inside nested resources — a
user.billing.internal_notesfield buried three levels deep gets missed by testers who only check top-level response keys. - Validate business logic on accepted writes. If a mass assignment succeeds, confirm the downstream effect: does the escalated role grant new API access, does the credit limit field change actual transaction limits.
This workflow mirrors the authorized testing structure used for API1 object-level authorization and API2 broken authentication — property-level, object-level, and authentication testing should run as one coordinated engagement rather than three disconnected checks, since a broken authentication path often surfaces the exact session context needed to trigger a property-level bypass.
Excessive Property Exposure on Read
This is the legacy Excessive Data Exposure half of BOPLA. It fails when the API returns more fields than the calling context requires, relying on the frontend to filter what gets displayed. Testers exploit it by calling the raw endpoint directly, bypassing the UI entirely with a proxy tool, and reading the full JSON body.
Common findings in this category:
- Internal identifiers (database IDs, foreign keys to unrelated tenants) present in customer-facing responses.
- Financial or risk fields (
credit_score,fraud_flag,internal_pricing_tier) returned to end users whose role should never see them. - Debug or trace fields left in production responses (
stack_trace,query_time_ms,internal_notes). - PII fields returned in list endpoints even when detail endpoints correctly redact them.
A useful resource for structuring this phase is the broader API penetration testing guide, which covers the reconnaissance and schema-mapping steps that precede property-level testing.
Improper Property Authorization on Write (Mass Assignment)
This is the legacy Mass Assignment half. It fails when the API auto-binds request body fields to internal object properties without checking whether the authenticated user is permitted to set that specific field. Frameworks that auto-serialize request bodies into ORM models are structurally prone to this if developers rely on default serialization instead of explicit allow-lists.
Test cases to run:
- Submit a user-profile update with an added
role: adminfield and confirm rejection. - Submit an order-update request with a
discount_percentageorunit_priceoverride field. - Submit account-status changes (
is_verified,kyc_status,account_locked) via endpoints intended only for name and email updates. - Test bulk-update and PATCH endpoints specifically — partial updates are more prone to weak allow-listing than full-object PUT replacements.
- Test nested writes: updating a parent object that contains a child object with sensitive properties, such as a shipment record containing an embedded payment sub-object.
Why BOPLA Test Results Vary Across APIs
The severity and volume of BOPLA findings differ meaningfully by API design pattern. Factors that consistently shift results:
- Serialization strategy. APIs using explicit response DTOs per role show fewer excessive-exposure findings than APIs that serialize ORM models directly.
- Framework defaults. Frameworks with permissive default model binding produce more mass assignment findings than frameworks requiring explicit field allow-lists.
- API maturity and documentation. Undocumented APIs take longer to map and typically hide more property-level issues, since testers cannot rely on a spec to enumerate fields.
- Multi-tenancy design. Multi-tenant SaaS APIs show higher BOPLA risk when tenant-scoping logic is applied at the object level but not re-verified at the property level.
- Role granularity. APIs with many fine-grained roles require proportionally more test matrix cells, increasing both testing time and the chance of missed combinations if testing is not systematic.
- Change velocity. APIs shipping frequent schema changes accumulate BOPLA risk faster than stable APIs, since new fields are added to models without a corresponding review of which roles should see them.
Related Questions on BOPLA Testing
Is BOPLA the same as IDOR?
BOPLA is not the same as IDOR, though the two are related. IDOR and API1 Broken Object Level Authorization concern whether a user can access an entire object belonging to someone else; BOPLA concerns whether a user who is correctly authorized for an object can still see or modify individual fields within it that they should not.
Can automated scanners detect BOPLA vulnerabilities?
Automated scanners detect BOPLA vulnerabilities only in narrow, pattern-matched cases, such as flagging obviously sensitive field names in responses. Scanners cannot determine intended per-role field visibility, which requires business context that only manual testing against a documented property matrix reliably captures.
How does BOPLA differ from the old API3 and API6 categories?
BOPLA merges the 2019 API3 (Excessive Data Exposure) and API6 (Mass Assignment) categories into a single entry in the OWASP API Security Top 10 2023 edition. The merge reflects that both are the same root defect — missing property-level authorization — expressed on the read side and the write side respectively.
Does BOPLA testing apply to GraphQL APIs?
BOPLA testing applies directly to GraphQL APIs, arguably with higher relevance, since GraphQL field selection makes property-level exposure a first-class concern. Testers should validate that resolvers enforce per-field authorization independent of the query shape a client submits.
BOPLA Testing Checklist
- Property inventory built for every object-returning and object-accepting endpoint
- Role-based visibility matrix documented per field before testing begins
- Read-side diffing performed across all roles, including nested and array objects
- Write-side fuzzing performed with privileged and hidden fields on PATCH/PUT/POST
- Bulk-update and partial-update endpoints tested separately from full-object writes
- Findings validated for downstream business impact, not just acceptance of the request
- Retest cycle scheduled after remediation to confirm the allow-list fix holds
AppSecure runs this property matrix as a standard deliverable inside API-focused engagements, alongside the object-level and authentication testing covered in the API1 and API2 guides, and the broader access control testing work that underpins all three.
Get your API tested for BOPLA
Manual property-level authorization testing across every role and endpoint.
FAQ
What is Broken Object Property Level Authorization?
Broken Object Property Level Authorization (BOPLA) is an API vulnerability where authorization checks validate access to an object but fail to validate access to individual properties within that object, letting users read or write fields they should not touch. It is category API3 in the OWASP API Security Top 10 2023 edition.
How do I test for BOPLA manually?
Test for BOPLA manually by building a property matrix listing every field against every user role, then diffing raw API responses against expected visibility, and separately fuzzing write endpoints with privileged or hidden fields to confirm the server rejects unauthorized property changes.
What is the difference between BOPLA and mass assignment?
Mass assignment is the write-side half of BOPLA. BOPLA covers both excessive property exposure on read responses and improper property authorization on write requests, with mass assignment specifically describing the write-side failure where submitted fields get bound to internal object properties without an authorization check.
Do WAFs stop BOPLA vulnerabilities?
WAFs do not stop BOPLA vulnerabilities in most cases, because the requests involved are syntactically valid API calls with legitimate authentication. The flaw sits in application-layer authorization logic, which a WAF operating on traffic patterns cannot evaluate.
Which frameworks are most prone to mass assignment issues?
Frameworks that auto-bind request bodies to ORM models by default are most prone to mass assignment issues. The risk persists unless developers explicitly implement field allow-lists on every write endpoint.
How often should BOPLA testing be repeated?
BOPLA testing should be repeated whenever the API schema changes, new roles are introduced, or new endpoints ship, and at minimum during each scheduled penetration testing cycle. New fields added to an existing model are a common source of newly introduced property-level exposure.
Is BOPLA relevant to GraphQL APIs?
BOPLA is highly relevant to GraphQL APIs because field-selection queries make resolver-level property authorization a primary attack surface. Testers must validate authorization independent of which fields a query requests.
What CWE maps to BOPLA?
CWE-915, Improperly Controlled Modification of Dynamically-Determined Object Attributes, is the primary weakness classification behind the mass assignment half of BOPLA. The excessive exposure half is generally documented as a broken access control weakness at the field level.
Can BOPLA be found through code review alone?
BOPLA can be partially found through code review by inspecting serialization logic and model-binding configuration, but full coverage requires dynamic testing against live responses. Intended field visibility is a business rule that is not always evident from code alone.
Does BOPLA testing require API documentation?
BOPLA testing does not strictly require API documentation, but undocumented APIs take longer to test thoroughly because testers must manually enumerate every field from raw traffic instead of working from a published schema.
One Last Thing
The highest-value BOPLA findings rarely sit in the field an attacker types into a form. They sit in nested objects three levels deep, in list endpoints that return more detail than the corresponding single-record endpoint, and in nullable fields that only populate for certain account states. Testing only the fields visible in the UI misses most of what BOPLA is designed to catch — the property matrix has to be built from the raw response, not from the frontend.
Related Guides
Tejas K. Dhokane is a marketing associate at AppSecure Security, driving initiatives across strategy, communication, and brand positioning. He works closely with security and engineering teams to translate technical depth into clear value propositions, build campaigns that resonate with CISOs and risk leaders, and strengthen AppSecure’s presence across digital channels. His work spans content, GTM, messaging architecture, and narrative development supporting AppSecure’s mission to bring disciplined, expert-led security testing to global enterprises.
.webp)
