Broken object property authorisation exposes API data and privilege gaps

At a glance

What this is: Broken object property authorisation is an API control gap where attackers can reach sensitive fields or alter protected properties even when object-level checks pass.

Why it matters: It matters to IAM and security teams because authorisation must account for property-level exposure, not just whether a request reaches the right object.

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.

Context

Broken object property authorisation is an API governance failure, not just an application bug. The problem appears when an API returns or accepts more data than the caller should be allowed to see or change, even though the object itself was authorised.

This matters because modern API controls often stop at endpoint or object checks, while the real risk sits in the fields inside the object. In IAM terms, the access decision is too coarse for the data and actions the API actually exposes, especially where client code is trusted to filter or hide sensitive properties.

Salt's example is typical of a wider API pattern: business logic and authorisation are evaluated too late, and the client is trusted with data minimisation it should not carry.

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. That leads to hidden-data exposure, privilege escalation, and business logic bypass even when object-level access appears correct. Field-aware checks are essential whenever one object contains both low-risk and sensitive attributes.

Q: Why do property-level API flaws create privilege escalation risk?

A: Because some fields carry security state, not just data. If an attacker can change role flags, account status, or other privilege-bearing attributes, the API can transform a normal request into an authorisation bypass. The risk is highest when client-side code is trusted to remove or hide those fields before the server sees them.

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. Security teams should also look for bulk scraping patterns, inconsistent authorization checks, and data that remains accessible after privacy settings are changed.

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.

Technical breakdown

Why object-level checks can still fail at the property layer

Object-level authorisation answers whether a caller may reach a record, resource, or account. It does not necessarily answer which fields within that record may be read, updated, or inferred. Broken object property authorisation appears when APIs expose private attributes alongside public ones, or accept extra parameters that alter protected state. That creates two control gaps: excessive data exposure on the response path and mass assignment on the request path. Traditional gateways can see traffic, but they rarely understand business meaning, so a request that changes privilege-bearing properties can look valid unless the API itself enforces property-aware rules.

Practical implication: Map sensitive fields and writable attributes separately from object access, then enforce field-level allowlists in the API layer.

Why gateways and WAFs miss property abuse

Gateways and WAFs are useful for coarse filtering, but they do not know the intended business logic behind each API call. They may detect a known pattern such as a PAN or token, yet they cannot reliably distinguish legitimate extra parameters from malicious ones that rewrite role, identity, or payment properties. That limitation matters because attackers can call the API directly and bypass client-side masking or browser controls. The result is a governance blind spot: controls that inspect syntax but not authorisation intent. API security therefore needs context about who may change which property, under which operation, and for which workflow.

Practical implication: Treat gateway filtering as a boundary control and move property authorisation enforcement into the application and API policy layer.

How behavioural baselines expose property-level abuse

Property abuse often reveals itself through unusual parameter sets, atypical field combinations, or changes that do not match historical user behaviour. Baselines are valuable because they help distinguish expected variation from hidden privilege expansion. In practice, this means tracking which fields are normally requested, which properties are normally updated, and which identities should never see or modify sensitive attributes such as tokens, role flags, or payment details. This is not just a detection problem. It is an authorisation design problem, because the safest alert is the one that points to a request that should never have been possible in the first place.

Practical implication: Monitor parameter drift and privilege-bearing field changes, then block the request patterns that fall outside normal API behaviour.

Threat narrative

Attacker objective: The attacker wants to read hidden data, modify protected object properties, and elevate their access without passing the controls that protect the object itself.

1. Entry occurs through API endpoint manipulation, where the attacker submits a request that reaches an otherwise legitimate object.
2. Credential or privilege bypass follows when the API exposes hidden properties or accepts unauthorized parameters that the client should never control.
3. Escalation happens as the attacker changes role-bearing fields or extracts sensitive attributes that expand what they can do next.
4. Impact is unauthorized data exposure, privilege escalation, and bypass of intended application controls.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Excessive data exposure and mass assignment are the same governance failure seen from two directions. One side leaks data the caller should not receive, the other lets the caller alter properties they should not control. The common weakness is failure to separate read scope from write scope at the property layer. Teams should map which properties are sensitive, which are mutable, and which identity or role can touch each one.

Property-level abuse exposes the limits of perimeter security around APIs. A WAF or gateway can filter syntax, but it cannot reliably interpret intent, workflow, or business meaning. That is why API authorisation has to move closer to the decision point and be informed by context such as user, operation, property sensitivity, and typical behaviour. Practitioners should assume that anything left to the client can be bypassed.

Broken object property authorisation is a direct signal that identity and API governance are still misaligned. When an API lets a caller change privilege-bearing fields, the identity system is no longer the only source of truth for access. That increases the value of tighter policy enforcement, sensitive-field inventory, and behavioural controls at issuance time. The practical conclusion is simple: if the API can change trust state, it must govern trust state explicitly.

From our research library:

• 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.
• Read next: Authorisation Models Guide

What this signals

Property-level authorisation gaps are the point where API governance becomes identity governance. If an API can expose hidden fields or accept unauthorized updates to security-bearing properties, the identity model has been defined too loosely. Teams should review where their authorisation decisions stop at the object boundary and where property state quietly changes trust.

Field-level policies will matter more as APIs carry more sensitive state. The practical issue is not just who can reach an endpoint, but which attributes inside that endpoint can alter account status, roles, or data visibility. Practitioners should treat every privilege-bearing field as a control point, not a payload detail.

For practitioners

• 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. Use that inventory to create explicit allowlists for response shaping and update operations.
• 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. Require server-side validation of every writable property.
• 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.
• Stop relying on client-side filtering Assume attackers can call APIs directly and bypass browser or mobile logic. Move all security-relevant masking, filtering, and authorization checks into the server-side API path.

Key takeaways

• Broken object property authorisation shows that a correct object-level decision can still leave sensitive fields exposed or editable.
• The attack pattern combines excessive data exposure and mass assignment, so response filtering and request validation both need property-level enforcement.
• Teams should inventory privilege-bearing fields, validate parameters server-side, and baseline normal API behaviour to catch abuse earlier.

Key terms

• Broken Object Property Authorisation: A flaw where an API correctly recognises the object being accessed but fails to control individual fields inside that object. The result is that sensitive properties can be read, changed, or inferred even when object-level checks appear to work.
• Excessive Data Exposure: Excessive data exposure occurs when an API returns more information than the caller actually needs. The issue is usually a design and authorization problem rather than a coding typo, and it increases breach impact because a stolen credential can reveal far more data than intended.
• Mass Assignment: An API vulnerability where request parameters are automatically bound to internal fields without a strict allowlist. Attackers exploit it by submitting hidden or unexpected properties, which can overwrite privileged attributes, alter account state, or bypass intended application logic.
• Property Level Authorization: Property level authorization is the control that decides which individual fields within an object a user may read or modify. It extends ordinary authorization by enforcing rules at the data element level, which is essential when APIs expose complex objects with mixed sensitivity.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect access control, identity lifecycle, and secrets management to broader security programmes.