Broken object property authorisation exposes API data and privilege gaps

At a glance

What this is: This is an analysis of broken object property level authorisation, where API requests expose or modify fields callers should not access.

Why it matters: It matters to IAM and security teams because API authorisation failures can bypass role controls, expose sensitive data, and create privilege escalation paths that affect both human and non-human identities.

👉 Read Salt's analysis of broken object property level authorisation and API abuse

Context

Broken object property level authorisation is an API access control failure, not just a data leakage problem. A system can correctly protect the object itself and still expose private fields, allow forbidden updates, or trust client-side filtering that attackers bypass by calling APIs directly. This makes API security an identity and privilege issue as much as a development issue, especially where tokens, roles, and delegated access determine what can be read or changed.

The governance gap is that many controls are built to recognise endpoints, not business context. When an API object contains both public and private properties, security teams need property-level authorisation, request baselining, and visibility into unusual field-level changes. For organisations running human IAM, NHI workflows, or agentic AI integrations, the same pattern applies: if the caller can alter attributes outside its intended scope, the access model has already failed.

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 excessive data exposure and mass assignment create the same governance problem?

A: Both issues come from trusting the API contract too loosely. One leaks extra data on output, the other accepts extra fields on input, but each lets attackers reach information or behaviour outside intended scope. The governance response is the same: explicit allowlists, response shaping, and monitoring for property-level anomalies.

Q: How do security teams know if API abuse controls are working?

A: Security teams know API abuse controls are working when repeated credential use drops, abnormal request volume is detected early, and hostile client behaviour is blocked before backend systems see sustained load. Effective controls reduce both attack success rate and the time abuse can persist unnoticed.

Q: Which frameworks apply when APIs expose or modify sensitive properties?

A: OWASP API Security Top 10 guidance, PCI-DSS for cardholder data, and NIST-style access control principles are all relevant where field-level exposure affects regulated information. The practical test is simple: if an API field changes who can see, change, or infer sensitive data, it needs explicit governance.

Technical breakdown

Why object-level checks miss property-level abuse

Object-level authorisation answers a narrow question: may this caller access this record at all? Broken object property level authorisation happens when the answer is yes, but the caller can still read or change fields that should be restricted. That distinction matters because API objects often bundle public and private attributes in the same response or request body. If the application trusts the client to hide sensitive data, an attacker can call the API directly, inspect the payload, and reach fields such as tokens, payment data, or role flags that were never meant to be editable.

Practical implication: move authorisation checks from object scope to field scope for sensitive API operations.

How mass assignment and excess data exposure create privilege risk

Mass assignment occurs when an API binds request parameters to internal object fields without strict allowlisting, letting an attacker submit properties the interface never intended to accept. Excessive data exposure is the mirror problem on the response side, where the API returns more data than the client needs and relies on the front end to hide the rest. Both patterns can enable privilege escalation, tampering, and hidden-data disclosure because the attacker only needs to discover which parameters the backend will honour.

Practical implication: enforce explicit field allowlists on input and response shaping on output.

Why WAFs and API gateways struggle with business logic abuse

Traditional perimeter tools can filter patterns, but they do not understand whether a field is legitimate in a given workflow or whether a parameter change is consistent with the caller’s role. That makes them weak against requests that look syntactically valid but violate business logic. The real control problem is not just payload inspection. It is understanding expected behaviour per endpoint, per identity, and per transaction type so that anomalous property changes can be separated from valid application traffic.

Practical implication: pair gateway controls with behavioural baselining and API-specific authorisation monitoring.

Threat narrative

Attacker objective: The attacker wants to read restricted data, change protected object properties, and gain higher application privileges without using a valid administrative workflow.

1. Entry occurs through a normal API call that includes parameters or response data the attacker can inspect and manipulate.
2. Escalation follows when the attacker adds unauthorised properties or updates hidden fields such as role or account attributes.
3. Impact comes from privilege escalation, sensitive data exposure, or bypassing application security logic.

NHI Mgmt Group analysis

Field-level authorisation is the control gap that matters here: object checks alone do not protect APIs when an attacker can still read or write hidden properties. That makes this a governance problem, not just a secure coding defect, because the real question is what each identity is permitted to see or modify inside the object. For practitioners, the lesson is to treat property-level permissions as a first-class authorisation boundary.

Client-side trust is the wrong security model for sensitive API data: if the browser or mobile app is responsible for masking fields, the attacker will bypass it by speaking directly to the API. This is especially relevant where API traffic carries tokens, account data, or delegated access rights. The operational conclusion is that the server must own exposure decisions, not the client.

API property sprawl: is the hidden risk that emerges when objects accumulate fields faster than authorisation rules are updated. That sprawl creates a mismatch between what developers think the API exposes and what the backend will actually accept or return. Security teams should treat this as a lifecycle problem across design, testing, and change management.

For identity programmes, this is a delegated access issue in disguise: the same weakness that lets an attacker update a role field in an API can also undermine SSO, service integrations, and non-human workflows that rely on trusted claims. Where machine identities or agentic systems call APIs, field-level abuse can become a path to unauthorised automation. The practical conclusion is to align API authorisation with identity governance, not just transport security.

What this signals

Property-level exposure is becoming a governance signal, not just an application bug. As APIs carry more identity claims, tokens, and delegated permissions, the difference between object-level and field-level control will shape how teams assess risk in both human and non-human access paths. The organisations that can baseline property usage and reject unexpected fields will have a clearer view of where business logic is being abused.

Field-level authorisation maps directly to NHI and agentic AI risk. Service accounts, API keys, and AI agents often interact through the same interfaces that users consume, which means hidden-property abuse can become an access-control bypass for automation. Teams should treat API payload governance as part of the broader identity control plane, not a separate developer concern.

The operational priority is to tie API behaviour to the identity that initiated it, then compare that behaviour with the permissions that identity should actually hold. Where that linkage is missing, field-level abuse can hide inside ordinary traffic and evade controls built for endpoints rather than data semantics.

For practitioners

• Implement field-level allowlists for every sensitive API Define which properties each role, token, or service account may read or modify, then reject unknown or disallowed parameters at the API layer rather than relying on the client to hide them.
• Baseline normal requests per endpoint and identity Track the usual parameter sets, method usage, and response shapes for each caller so that unexpected property additions or unusual update paths surface as anomalies.
• Separate public and private properties in API design Refactor object models so that high-risk fields such as role, status, credential, and payment attributes are not returned or writable by default in shared object schemas.
• Test APIs for mass assignment and hidden-field abuse Include negative tests that attempt to overwrite restricted fields, submit extra JSON properties, and force role or account changes through direct API calls.

Key takeaways

• Broken object property level authorisation lets attackers reach sensitive API fields even when object-level checks are in place.
• The practical risk is privilege escalation and hidden-data exposure through requests that look normal to perimeter tools.
• Teams need field-level allowlists, behavioural baselines, and server-side enforcement to close the gap between identity and API behaviour.

Key terms

• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• 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.
• 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.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• API response and request examples showing where excess data exposure appears in real workflows
• A step-by-step breakdown of the POST and PUT manipulation patterns used to alter hidden properties
• Specific detection and baselining ideas for spotting anomalous parameter changes per endpoint and user
• The article's practical discussion of why gateway filtering and regex-based controls are insufficient on their own

👉 Salt's full article covers the attack examples, control failures, and API-specific detection guidance

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme that depends on them.