What Is Broken Object Property Level Authorization?

Broken object property level authorization ranks third on OWASP's API Security Top 10 for 2023, representing a critical gap in how APIs control access to individual data fields. APIs routinely grant access to entire objects while failing to restrict which properties users can read or modify. This guide examines how property-level authorization failures manifest in cloud environments, the business consequences of exploitation, detection methodologies, and implementation strategies for granular access controls across REST, GraphQL, and microservice architectures.

API3:2023 - Broken Object Property Level Authorization Explained

Property-level authorization governs which specific attributes within an object a user can access or modify. While object-level authorization determines whether you can interact with a user record, property-level authorization controls whether you can read the social security number field within that record or change the account balance attribute.

Most APIs grant or deny access at the object level but fail to implement granular controls at the property level. A developer might verify a user has permission to retrieve their profile object but neglects to filter sensitive properties like internal identifiers, salary details, or administrative flags before sending the response. Similarly, an API might validate object-level write permissions but allows clients to modify any property submitted in the request payload.

The Dual Vulnerability Surface

OWASP’s API3:2023 encompasses two distinct attack vectors that share a common root cause. The first involves unauthorized reading of sensitive properties. REST APIs commonly serialize entire objects using methods like to_json() or automatic ORM mappings, exposing internal fields such as is_admin, credit_score, or internal_notes that developers never intended for client consumption. GraphQL amplifies the security risk by allowing clients to explicitly request any field unless the schema implementation actively restricts field-level access.

The second vector API security must address involves unauthorized modification of object properties. Frameworks often bind HTTP request parameters directly to object attributes through mass assignment features. An attacker sends additional parameters beyond the legitimate form fields, injecting values for properties like account_status, discount_rate, or approval_required. The API processes the entire payload without validating which properties the current user should control.

Evolution from Legacy Risks

In API3:2023, OWASP merged two previously separate vulnerabilities.

1. Excessive data exposure described the read-side problem where APIs leaked sensitive information through overly verbose responses.
2. Mass assignment referred to the write-side issue where APIs accepted unauthorized property modifications through parameter injection.

Combining these risks reflects the technical reality that both stem from identical authorization gaps. Development teams implementing object-level checks assume the work is complete. Property-level enforcement requires additional logic at every endpoint, examining each field individually rather than applying blanket permissions to entire resources. The cognitive load increases substantially when APIs expose dozens of properties across hundreds of endpoints.

Cloud-native architectures compound the problem. Microservices frequently share data models across service boundaries, and a property considered safe in one context becomes sensitive when exposed through a different API gateway. Autogenerated API documentation tools display all available properties, inadvertently creating reconnaissance maps for attackers. The velocity of modern development cycles means property-level authorization rules rarely receive the same scrutiny as authentication or network security controls.

Understanding Broken Object Property Level Authorization

Object properties represent individual fields or attributes within a data structure. A user object might contain username, email, password_hash, account_balance, is_verified, and role. Each property holds distinct information requiring separate access controls based on context and user privileges.

Serialization Creates Exposure Points

APIs transform internal objects into transmittable formats through serialization. Framework defaults typically serialize every accessible property unless developers explicitly configure filters. An ORM query like User.find(id) returns a complete object with all database columns. When passed to response.json(user), the serializer converts everything into the HTTP response body.

Java's Jackson library, Python's Marshmallow, and Node's JSON.stringify() all exhibit this behavior. GraphQL schemas define available fields but rely on resolver-level authorization to restrict access. Without field-level permissions, clients can query any property defined in the schema.

Deserialization presents the inverse problem. Web frameworks bind incoming JSON or form data directly to object attributes through parameter binding mechanisms. Rails' strong parameters, Laravel's mass assignment protection, and Spring's @ModelAttribute all attempt to solve the binding problem, but developers must actively configure which properties accept input. Default configurations often permit any submitted field to update the corresponding object property.

Granular Authorization Requirements

Least privilege demands that users access only the specific properties necessary for their role and context. An employee viewing their own profile needs name, email, and department but shouldn't see salary_band, performance_rating, or termination_eligibility. A manager reviewing team members requires different property access than HR administrators processing payroll.

Authorization systems traditionally operate at the resource level, checking whether a user can GET /api/users/123. Property-level authorization extends this model to individual fields: can the current user read users/123/salary? Can they modify users/123/role? Each property becomes an authorization decision point.

Cloud APIs compound the complexity because properties serve multiple consumers. Microservice A might legitimately access internal identifiers for cross-service calls while the public API gateway must strip those same fields from client responses. The authorization context shifts based on the caller's identity, transport channel, and intended use of the data.

How Broken Object Property Level Authorization Manifests in Real-World APIs

API3:2023 vulnerabilities appear through two distinct attack patterns that exploit missing property-level controls. Developers implement object-level authorization but skip the granular inspection required for individual fields.

Excessive Data Exposure Through Unfiltered Serialization

APIs leak sensitive properties when serialization methods convert entire objects into response payloads without field filtering. A social platform API returns user profiles through GET /api/users/{id}. The endpoint retrieves the complete User object from the database and passes it to a serializer. Ruby on Rails developers call render json: @user, Python FastAPI returns UserModel directly, and Node Express uses res.json(user). Each framework serializes every property accessible on the object.

The response includes intended fields like username and bio alongside sensitive properties like email_verification_token, password_reset_timestamp, internal_user_id, and account_flags. A dating application demonstrates the risk when users report inappropriate behavior. The mutation response returns the reported user's profile, exposing fullName and recentLocation coordinates. The reporting user gains access to geographic tracking data and identity information that should remain private.

GraphQL amplifies the exposure because clients explicitly request fields in their queries. Developers define comprehensive schemas with every database column mapped to a GraphQL type. Without field-level authorization in resolvers, clients query sensitive properties by reading the schema documentation. A query requesting user { id username salary creditScore } succeeds because the schema defines all four fields, even though only id and username should be publicly accessible.

Unauthorized Property Modification Through Mass Assignment

Web frameworks bind HTTP request parameters to object properties automatically. Rails accepts nested attributes, Laravel fills model properties from request data, and Spring Boot maps JSON to entity objects. Attackers exploit the behavior by injecting unauthorized parameters into legitimate requests.

A rental marketplace requires hosts to approve guest bookings. The approval endpoint accepts POST /api/bookings/{id}/approve with a payload containing approved: true and comment: "Check-in after 3pm". An attacker replays the request with an additional property: total_stay_price: 1000000. The framework binds the malicious parameter to the Booking object's price field. Without property-level authorization, the database update modifies both legitimate and injected fields.

Content moderation systems exhibit similar vulnerabilities. A video platform allows creators to edit metadata through PUT /api/videos/{id} with fields like title and description. An attacker includes content_status: "approved" or blocked: false in the request body. The API updates the moderation flag because the framework binds all submitted parameters to the Video object's properties. Role elevation attacks follow the same pattern when attackers inject is_admin: true or account_type: "premium" into profile update requests.

The Business Impact of Broken Object Property Level Authorization

Property-level authorization failures translate directly into quantifiable business harm. Organizations face regulatory penalties, financial losses, and reputational damage when APIs expose or accept unauthorized property modifications.

Privacy Violations and Regulatory Exposure

Leaked object properties frequently contain personal identifiers governed by data protection regulations. APIs exposing social security numbers, medical records, or location coordinates violate GDPR's data minimization principle. Each unauthorized property disclosure constitutes a separate processing violation under Article 5.

CCPA imposes penalties when APIs knowingly expose consumer data without proper authorization. PCI DSS failures occur when payment APIs leak cardholder data beyond the minimum required fields. Acquiring banks revoke merchant accounts when card metadata, CVV codes, or track data appear in API responses. Compliance frameworks demand field-level access controls with audit trails proving which users accessed sensitive properties.

Financial Fraud Through Property Manipulation

Mass assignment vulnerabilities enable direct monetary theft. E-commerce platforms suffer losses when attackers inject discount_percentage: 100 or price: 0.01 into checkout requests. Marketplace platforms lose revenue when transaction fees are modified through commission_rate parameter injection. Financial services APIs face fraud when attackers alter account_balance, credit_limit, or transaction_amount properties.

Insurance claim processing APIs demonstrate the risk when attackers modify claim_status, payout_amount, or approval_override flags. Healthcare billing systems lose revenue when procedure codes, patient responsibility amounts, or insurance coverage percentages get manipulated through unvalidated property updates.

Content Integrity and Platform Trust

Content moderation bypass through property manipulation destroys platform trust. Social networks struggle with policy violations when creators unblock flagged content by modifying moderation_status or violation_flags. Streaming platforms face copyright claims when users inject content_rights: verified into upload requests. Marketplaces lose seller and buyer confidence when product ratings, verification badges, or featured listing status can be self-modified through API exploitation. Platform integrity depends on immutable properties remaining protected from user manipulation.

Identifying Broken Object Property Level Authorization in Your APIs

Security teams must actively probe APIs for property-level authorization gaps using both manual inspection and automated tooling. Detection requires examining response payloads for unauthorized data exposure and testing whether APIs accept modifications to protected properties.

Response Analysis for Unauthorized Property Exposure

Start by capturing API responses across different user contexts. Authenticate as a low-privilege user and invoke endpoints that return objects. Document every property in the response payload. Repeat the same requests using administrative credentials or different user roles. Properties appearing consistently across all roles warrant scrutiny.

Compare the response schema against intended data access policies. Look for database column names, internal identifiers, timestamps, status flags, and computed fields. Properties like created_by_user_id, internal_notes, last_modified_timestamp, or is_verified often indicate implementation details rather than user-facing data. GraphQL introspection queries reveal the complete schema with __schema and __type queries, exposing every field developers defined.

Proxy tools like Burp Suite or OWASP ZAP intercept API traffic and highlight response differences between user sessions. Security testers examine JSON responses for nested objects containing sensitive properties. A user profile might expose address.latitude, payment_methods.last_four, or preferences.internal_flags deeper in the object hierarchy. Array responses amplify the risk when each list item contains unnecessary properties multiplied across hundreds of records.

Parameter Injection Testing for Mass Assignment

Legitimate API requests establish a baseline of expected properties. An account update accepts email and display_name in the request body. Testers replay the request while injecting additional properties systematically. Add is_admin: true, account_balance: 999999, subscription_tier: premium, or approval_status: approved to the payload.

Monitor response codes, error messages, and subsequent state changes. A 200 response with updated data confirms that the API accepted the malicious property. Verify exploitation by retrieving the modified object or observing privilege escalation. Role-based testing requires accounts at multiple permission levels. Low-privilege users attempt to modify properties that should require administrative access.

Read-only fields present specific targets. Properties like created_at, user_id, total_orders, or reputation_score should resist modification attempts. Send PATCH or PUT requests containing these fields with altered values. APIs vulnerable to mass assignment update read-only properties despite business logic requirements for immutability.

Automated Detection Through Schema Analysis

API documentation tools expose property catalogs for systematic testing. OpenAPI specifications list every request and response property with data types. Automated scanners compare specification schemas against runtime responses, flagging discrepancies.

Fuzzing frameworks inject randomized properties into requests while monitoring for successful bindings. Burp's Intruder module iterates through common property names like admin, role, status, price, approved across all API endpoints. Response size changes or status code variations indicate accepted parameters.

Property enumeration discovers hidden fields through systematic testing. GraphQL field suggestions expose properties when queries contain typos. REST APIs leak property names through error messages showing rejected fields. Diff analysis between API versions reveals newly added properties requiring authorization review.

Preventing Broken Object Property Level Authorization: Best Practices

Property-level authorization demands intentional controls at each API layer. Security teams must enforce granular restrictions for both data retrieval and modification operations rather than relying on framework defaults.

Restricting Response Data Through Explicit Field Selection

Abandon automatic object serialization in favor of manual property enumeration. Define return values field by field rather than converting entire objects. Python FastAPI responses should specify UserPublicSchema with named attributes instead of passing raw SQLAlchemy models. Node.js endpoints construct response objects property by property: { userId: user.id, name: user.displayName, joinDate: user.createdAt }.

Build presentation layer objects specifically for API consumption. Internal User entities contain authentication tokens, encrypted passwords, and administrative metadata. External representations expose only client-relevant attributes. Map internal objects to external contracts through transformation functions that evaluate caller permissions before adding each field.

GraphQL requires resolver-level inspection for every requested field. Wrap field resolvers with authorization checks verifying that the requesting identity has read access. A salary field resolver queries permission rules before returning values. Unauthorized requests receive null or throw field-level errors rather than exposing protected data.

Validation layers inspect outbound payloads against declared contracts. Define expected response structures through JSON Schema, OpenAPI specifications, or type definitions. Compare serialized output against contracts before transmission. Mismatches indicate leaked properties from configuration drift or unauthorized access paths.

Blocking Unauthorized Modifications Through Input Control

Explicitly enumerate acceptable input parameters for every mutation endpoint. Frameworks offer filtering mechanisms but require active configuration. Define permitted fields through decorator patterns, configuration arrays, or validation classes. Reject HTTP requests containing undeclared parameters rather than silently ignoring extras.

Create dedicated request classes divorced from persistence models. Profile update operations accept ProfileUpdateRequest structures defining modifiable attributes. Controller logic extracts values from request objects and applies changes to domain entities through dedicated setter methods. Separation prevents direct parameter binding to database-mapped objects.

Authorization checks precede property mutations. Evaluate whether the authenticated principal holds modification rights for each submitted field. Price updates require financial permissions, while profile pictures need only content management access. Implement attribute-based access control, evaluating user context against property sensitivity classifications.

Applying Contextual Response Filtering

Tailor property exposure to operational requirements and consumer trust levels. Mobile applications receive condensed profiles while administrative dashboards access extended attributes. Service-to-service communication includes internal identifiers unavailable to public consumers. The authorization context determines field inclusion rather than returning maximum data to all requesters.

Broken Object Property Level Authorization FAQs