Broken Object Property Authorisation

Broken object property authorisation in APIs

Broken object property authorisation happens when an API checks which record or object a caller may access, but fails to enforce limits on the individual fields inside that object. The object is real and authorised, yet its sensitive properties are still exposed or mutable.

This is usually more subtle than object-level failure because the request can look legitimate at the resource layer. The weakness appears when the API trusts client-supplied fields, returns more data than the caller should see, or accepts updates to fields that should be server-controlled.

It often shows up in REST and GraphQL APIs, but the underlying issue is field-level access control, not the transport or the data format. A design that is safe at object scope can still leak secrets, PII, pricing logic, flags, roles, or internal workflow state through a single over-permissive property.

Because field checks are frequently scattered across serializers, mappers, and business logic, the control can fail in one direction only, read or write. That is why property authorisation needs to be treated as part of the application’s authorisation model, not as a cosmetic response-filtering step.

How property-level authorisation differs from object-level control

Object-level authorisation asks whether the caller may access a customer, invoice, device, or project at all. Property-level authorisation asks which fields of that specific object are visible or editable. The two are related, but they protect different boundaries.

A caller may be allowed to view an order while still being denied access to internal cost fields, fraud scores, or admin-only notes. Likewise, a user may be able to update a profile object but should not be allowed to set account status, privilege flags, or verification markers. The API must enforce that distinction explicitly.

Modern APIs often fail here because developers rely on generic object mappers, dynamic payloads, or front-end form restrictions. Those are convenience mechanisms, not security controls. The server has to make the final decision on every sensitive property.

For teams comparing broader authorisation approaches, Authorisation Models Guide is useful because broken property checks are often a sign that the access model is too coarse for the data being exposed.

Common ways the flaw appears

The most common pattern is over-posting or mass-assignment, where a client submits fields that the interface never intended to expose. Another is response over-sharing, where the API returns internal fields simply because they exist on the object. A third is partial-update confusion, where a PATCH or similar request allows a caller to modify a field that should be immutable or server-owned.

GraphQL-style schemas can also create exposure when resolvers do not enforce field-level policy consistently. Even if the query targets one object, the resolver may still hand back nested properties that should be hidden from that role or tenant. The same risk exists in microservices when one service assumes another already performed the necessary filtering.

These failures are especially dangerous when the property itself is control-bearing, such as role assignments, approval states, policy exceptions, recovery contact details, API keys, or flags that affect downstream authorisation decisions. In those cases, a field leak is not just disclosure, it can become privilege escalation.

When API security guidance is needed, OWASP API Security Top 10 is a strong reference point because this class of flaw sits directly in the broken authorisation family.

Why this matters for sensitive data and control planes

Broken object property authorisation is not limited to harmless metadata. It can expose confidential business data, personal data, security telemetry, administrative controls, and hidden state that changes how the system behaves. Once a sensitive property is disclosed, it can often be reused to target other systems, infer privileged workflows, or manipulate later requests.

The impact is amplified when the property is used as an input to downstream decisions. A caller who can alter a supposedly protected field may bypass approval gates, alter routing, or change entitlement state without ever breaking object-level checks. That makes field-level authorisation a control-plane issue as much as a data-protection issue.

For teams that need a broader control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the general authorisation and data-protection control family needed to frame this risk inside an enterprise control set.

How to think about it during design and review

Design reviews should treat every sensitive field as a separate authorisation decision, not as a byproduct of object access. The key question is whether the caller is entitled to see or modify this property, for this object, in this context. If the answer depends only on the object being accessible, the control is too weak.

Development teams should also be careful not to confuse UI restrictions with API protections. Hiding a field in a form or dashboard does not protect it once the endpoint is called directly. The server must enforce the policy, and the policy must distinguish between allowed object access and allowed property access.

For implementation patterns that help reduce this gap, IAM and IGA Basics is useful because property-level checks often depend on the same entitlement and least-privilege logic used elsewhere in access governance.

Practitioner Guidance: Treat sensitive fields as first-class policy objects. If a property can reveal secrets, alter privilege, or influence a downstream workflow, require an explicit server-side rule for reading and writing it, not just object access approval.

Related resources from NHI Mgmt Group

• Why do API gateways struggle with broken object level authorisation?
• What is the difference between broken object level authorization and broken object property level authorization?
• Why do SAST and DAST still miss broken object-level authorisation?
• Why does broken object property level authorization increase risk even when API access is authenticated?