OWASP API Top 10:2023 – Broken Object Property Level Authorization: The Hidden Risk in Data Exposure
While modern applications offer user-friendly interfaces, the underlying API calls carry a major responsibility: delivering the right data to the right users. A small oversight in this process can quickly turn into a critical security flaw. Ranked third on the OWASP API Top 10:2023 list, Broken Object Property Level Authorization is one such risk that is often underestimated. In the second part of our series, we take a closer look at this subtle but dangerous vulnerability.
This type of vulnerability arises when authorization checks are applied only at the object level but not at the property (field) level within that object. In other words, even if access to an object is granted appropriately, individual fields inside that object must also be authorized separately. When this control is skipped, users may be able to view or modify sensitive properties they should have no access to. Frequently, frontend applications only display permitted fields in the UI, giving a false sense of security—while the backend silently delivers everything without enforcing proper field-level access restrictions.
This vulnerability can manifest in several ways. For example, a user may manually add a field such as isAdmin: true in a POST or PUT request to the API, and if the system processes it without verification, the user could escalate their privileges to administrator level. In another case, a user who is supposed to receive only their email address might instead receive additional sensitive fields such as passwordHash, userRole, or createdBy in the API response. These leaks can expose confidential, privileged, or internal system data that should never be publicly accessible.
What makes this issue especially critical is how easily it can be missed. Since client-side interfaces typically show only authorized fields, developers and testers may assume the backend is just as restrictive. However, anyone manually inspecting the API—via tools like Postman or a browser console—can uncover hidden fields returned in the response or attempt to send unauthorized fields in the request. If these fields are not properly filtered or validated on the server side, the attacker could exploit them to alter roles, access privileged data, or even manipulate system behavior.
Mitigating this vulnerability requires a conscious effort both during development and in testing workflows. Field-level authorization must be enforced consistently on the backend. Each field should be protected based on user roles or permissions, regardless of what the frontend displays. Additionally, the API should only return data that the user is explicitly authorized to see. Using DTOs (Data Transfer Objects) to shape and control responses can be an effective way to ensure this separation of concerns.
Robust testing processes are equally essential. Test your APIs with different user roles to observe which fields are accessible. Try sending extra fields manually to see how the system handles them. Examine API responses carefully to identify fields that are returned to the client but are not shown in the frontend UI. These manual tests can be reinforced through automation with tools like APIStrike or Postman, allowing you to continuously monitor for data-level authorization issues.
It’s important to remember: in security, what you don’t return is just as important as what you do. Many data breaches don’t happen because systems are hacked, but because sensitive data was quietly exposed without proper control. For this reason, field-level authorization is not an optional feature—it’s a foundational layer of security in any modern API ecosystem.
