Access control

Authz bugs hide behind working auth

Logging in proves who someone is. It does not prove they are allowed to do the thing they just asked for.

~5 minSecurity
scroll
01 · the shape

Authentication gets the attention

Teams test login carefully and then accidentally trust any logged-in user too much. Authorization bugs live in the gap between identity and permission.

api · broken object access

The useful signal is usually already there.

controls quiet

Security gets real when the trust boundaries light up. Poke it and see what has to hold.

02 · the move

Check permission at the object

Every sensitive read and write should verify the user can access that specific resource, not just the route or role name.

invoices/authz.ts

Object-level checks stop cross-tenant surprises.

03 · the check

Test the neighbor account

For every important endpoint, test a valid user asking for someone else’s object. That is where many authz bugs become obvious.

security control lab
exposed
hardened0
exposed: the feature trusts too much and records too little

Flip the switches and watch the story turn into a tiny operating model.

0status code for forbidden access
0object-level check per sensitive resource
0trust in client-hidden buttons
04 · the takeaway

Identity is only the start

The dangerous question is not "are you logged in?" It is "are you allowed to do this to that?"

source trail