Topic starter
02/08/2026 9:44 am
TL;DR: Broken object property level authorisation lets attackers expose hidden fields, tamper with object properties, and escalate privileges even when object-level checks exist, according to Salt. The issue shows why API governance must move from endpoint filtering to property-aware authorisation and behavioural baselining.
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: 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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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