API access control: four questions worth asking
Identity, object, function and property controls belong on the server. A hidden button is not an access boundary.
Who is making the request?
Authentication establishes an identity, but an authenticated user is not automatically entitled to every object or action. Document the identity types your API accepts, including service accounts and integration clients.
Which object can they reach?
An account may be allowed to read one invoice and forbidden from reading another. Test the ownership decision using controlled objects and separate identities. A random-looking identifier does not remove the need for a server-side check.
Which function can they invoke?
An ordinary user and an administrator may share an endpoint family. Sensitive actions still need explicit role or permission checks. Assess those operations directly at the API level instead of assuming that navigation restrictions protect them.
Which properties can they change?
An update endpoint may accept more fields than the interface displays. Review whether writable properties match the role and business purpose. Server-controlled state should not be changed merely because a client supplied it.
Keep the comparison repeatable
A small test matrix records identity, operation, object owner, changed properties and expected decision. Re-run the relevant comparisons after a fix. This creates clearer evidence than a collection of responses without role context.