Function and Property Level Authorization

The previous lesson fixed a specific gap: does the caller own this particular object? That check alone still leaves two questions unanswered. First, is this caller even allowed to perform this operation at all, on any object — should a regular user be able to call the endpoint that promotes a user to admin, regardless of whose account they target? Second, for an object the caller genuinely does own, is every field on it something this caller should be able to read or write — should a customer support agent viewing a user's account see that user's stored payment method in full, or should a regular user be able to set their own `role` field to `admin` through the same endpoint that lets them update their display name?

These are two related but distinct failure modes. Broken Function Level Authorization (BFLA) is about the operation itself: an endpoint that performs an administrative or elevated action exists, but doesn't check that the caller holds the role required to invoke it — often because the endpoint was only ever hidden from the regular UI, not actually protected server-side. Broken property-level authorization is about which fields of an object a given caller may read or write, even on an object they're entitled to touch at all — a check most APIs apply, if they apply it, only at the object level, leaving every field on that object equally exposed once object-level access is granted.

Both failures share BOLA's underlying cause: authorization logic that isn't actually enforced on the server, resting instead on an assumption — that the client's UI won't expose the dangerous action, that a hidden field won't be guessed, that nobody will think to send an extra key in a request body. A server that only trusts what it itself checks doesn't have that assumption to rely on, and doesn't need it.

This lesson builds the check for both: role- and permission-based gating on the operation itself, independent of any object-level check, and an explicit allowlist of which fields a given role may read and write on a given object type, applied on every request regardless of what the client happened to send.

Analogy🏏Cricket

🏏 Think of it like cricket: A stadium's accreditation system controls two separate things, and confusing them is exactly how gaps appear. First, it controls which zones a given pass can enter at all — a general spectator pass simply cannot open the door to the broadcast gantry, no matter whose seat the spectator legitimately owns in the stand below. Second, for the zones a pass can enter, it controls what that pass-holder can actually do once inside — a groundskeeper's pass gets them onto the outfield to work on the pitch, but that same pass doesn't let them touch the scoring system sitting in the same building, even though both are technically 'inside' a zone they're cleared for. A ground that only checks 'is this a valid zone for this pass' and stops there has answered the first question and skipped the second one entirely — it knows where someone is allowed to stand, but not what they're allowed to do once they're standing there. Function-level authorization is the first check: can this caller invoke this operation at all. Property-level authorization is the second: for an object this caller can touch, which specific parts of it can they actually read or change.