Limit API Object Properties by Role

An API can authorize the right object and still return the wrong fields. A member may be allowed to see a customer name but not billing notes, internal risk labels, or recovery data. OWASP calls this Broken Object Property Level Authorization. Review the serializer and the permission rule together.

Build a field exposure table

Pick one response shape. List every field, the roles that may read it, whether it is tenant-private, and where the value comes from. Include nested objects and computed fields.

A response schema can document the intended shape, but it does not enforce it. Check the actual serializer, ORM projection, and GraphQL resolver. Avoid spreading a full database model into response objects and then deleting a few fields. An explicit allowlist makes additions visible in code review.

Test each role

Use synthetic records with distinct markers in sensitive fields. Request the object as a permitted member, a limited member, a tenant admin, and an unrelated tenant user. Assert the exact keys and values returned. Repeat for list, detail, export, and error responses when they use different serializers. A denied field must not appear as null if its existence is sensitive.

Record the build and route version. A new field needs a permission decision before release, even if it seems harmless in a type definition. The OWASP Authorization Cheat Sheet supports action and resource checks; this artifact adds the property dimension. Keep the test in an owned system. If a field's owner cannot be identified, mark its exposure pending rather than assigning broad access by default.