Topic starter
02/08/2026 9:44 am
TL;DR: Excessive data exposure and mass assignment can still slip through object-level checks, Salt reports, when APIs leave sensitive fields readable or writable. Property-aware validation and response filtering need to track each field, not just the object.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “API3:2023 Broken Object Property Level Authorization”.
By the numbers:
- Broken object property authorisation sits alongside the OWASP API Security Top 10's earlier excessive data exposure and mass assignment patterns, which Salt says can still bypass object-level authorization.
Key questions
Q: Why do property-level API flaws create privilege escalation risk?
A: Because some fields carry security state, not just data.
Q: What are the signs that an API is leaking more user data than it should?
A: Common signs include unauthenticated access to profile endpoints, unusually rich responses from simple queries, the ability to enumerate users with email addresses or IDs, and public pages exposing fields meant to stay private.
Q: What breaks when API authorisation only protects the object and not its fields?
A: Attackers can still read private attributes or submit unauthorised updates if the API does not validate each property separately.
Practitioner guidance
- Define sensitive properties separately from object access Inventory fields that carry privilege, payment, contact, token, or role data, then classify which identities may read or modify each property.
- Enforce property-aware update policies Block mass assignment by rejecting unexpected parameters on create and update calls, especially where request bodies can influence role, account status, or authorization state.
- Baseline normal API parameter behaviour Track the fields, combinations, and value ranges that each endpoint normally sees, then alert on unusual properties, extra parameters, or privilege-bearing changes that fall outside baseline behaviour.
Bottom line: Broken object property authorisation shows that a correct object-level decision can still leave sensitive fields exposed or editable.
Glossary terms: Broken Object Property Authorisation, Excessive Data Exposure, Mass Assignment, Property Level Authorization
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 12:37 pm
Property-aware authorisation is now a governance requirement, not an API nicety. Endpoint-level control assumes the object boundary is the meaningful boundary, but modern APIs often carry multiple trust zones inside a single object. That creates a mismatch between access control design and data exposure reality. Practitioners should treat field-level authorisation as part of the access model, not as a response-format concern.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: How should teams design API controls for sensitive object properties?
A: Separate read and write permissions for each sensitive field, validate every server-side parameter, and deny any attribute that is not explicitly required for the operation. That approach protects both data exposure and privilege state, and it reduces the chance that a client or gateway can be tricked into accepting unauthorized property changes.
👉 Read our full editorial: Broken object property authorisation exposes API data and privilege gaps
This post was modified 2 days ago by NHI Mgmt Group