Permission to open a customer record does not necessarily include permission to read every field or change every value. A sales representative may view contact details while a finance role controls the credit limit. Both users refer to the same record, but their authority differs within it.
An API can enforce record ownership correctly and still expose an internal note or accept a field the interface never offers for editing. This review focuses on those property-level decisions.
Separate record access from field access
OWASP's API Security Top 10 describes broken object property level authorization as unauthorized reading or modification of object properties. The category includes excessive data exposure and mass assignment. OWASP's API3 guidance explains the distinction.
For an illustrative business account, write down who may read and change the contact name, billing address, credit limit, and internal review note. A field may be readable but not editable, or unavailable to a role in either direction. This becomes a concrete contract between the product policy and the API response.
Inspect what the server actually returns
A browser can hide a field after the server has already sent it. Examine the API response using synthetic records rather than relying on what the screen displays. Include nested objects, search results, and the response returned after an update.
Explicit response models can limit which properties leave the service. Check whether adding a database column automatically adds it to a serialized response. A schema change intended only for internal reporting can otherwise alter the information available to existing clients without changing their requests.
Limit what an update can bind
Mass assignment occurs when client-provided values are bound to object properties without appropriate restrictions. OWASP describes allowlists and dedicated data transfer objects as ways to restrict editable fields. Its mass-assignment guidance sets out these approaches.
In the account example, changing a contact name should not also permit changing the credit limit by adding another property. Review full replacements, partial updates, nested values, and bulk operations because they may use different binding code. The policy should define whether an unexpected field is rejected or ignored; either way, it must not change protected state.
Verify allowed changes and protected values together
Use test identities for each relevant role. Confirm an ordinary update first, then include a protected property with a harmless test value. Inspect the stored record and downstream events as well as the HTTP response. A validation error after a partial write can leave a business value changed despite the rejected request.
Retest when introducing fields or changing serializers. The assessment can produce a field-permission matrix, observed response shapes, and evidence of protected state remaining unchanged. Those records make the boundary reviewable by both the engineer implementing the endpoint and the business owner defining which roles may handle its data.
Sources
The OWASP references above define property-level authorization and mass assignment. The business account, roles, and test values are illustrative.
