What is API3 Broken Object Property Level Authorization?

Authorization is checked for the whole object but not for individual fields — so a user can read or change a property they shouldn't, like GET /users/me returning everyone's isAdmin flag, or a PATCH letting a customer set their own accountBalance.

This is field-level authorization, a finer-grained cousin of API1. The app correctly decides "you may access this object," then naively exposes or accepts all of its properties. Concrete example: a profile endpoint serializes the entire user record — including passwordResetToken or role — into the JSON response, leaking fields the client should never see. The flip side is the input direction (a client setting a field it shouldn't), which is the Mass Assignment case. Fix: explicitly choose which properties to expose and which to accept, never the whole object.

Issues:

• Sensitive properties returned that user shouldn't see
• Sensitive properties modifiable by unauthorized users

Countermeasures:

• Verify access rights before exposing object properties
• Return specific values only - not entire objects
• Avoid direct binding from input to internal objects
• Validate responses - ensure only permitted data returned
• Minimize data returned - principle of least privilege

Go deeper:

• OWASP API3:2023 — Broken Object Property Level Authorization — excessive data exposure + mass assignment.