Authorization

Once a login screen is in place, it feels like the door is locked. But only the front door is locked, and if everyone who gets inside can open every room, that lock doesn't mean much. When a service held data for one person at a time, the distinction never came up, because whatever the person who logged in could see was everything the service had.

That changed once several teams started keeping their own material in the same product. Pagedeck learned it the hard way. Document share links looked like /doc/1042, and the screen Theo built never checked whether the person opening the link was on that document. Change the number to 1041 and another team's meeting notes opened right up. The user had passed login cleanly. What was missing was the one line asking whether this person was allowed to see this document.

Authorization is that question, raised on its own. Who you are gets settled once, at connection time. What you're allowed to do changes from request to request: the same person, at the same moment, can read document A, cannot open document B, and may be able to read a third one without being able to delete it.

Every request gets checked against three things — who is asking, what they are asking about, and what they want to do to it.

1. Take the subject. Use the identity authentication has already established and handed over. Nobody asks who this is a second time.
2. Pin down the object and the action. Document 1042 or document 1041, a read or a delete. Reading is often fine on a document where deleting is not, so checking the object alone blocks half the problem.
3. Compare against the rules. Look up whether this subject may perform this action on this object. If the rules allow it, serve the request; if not, refuse it.

Refusals come in two flavors: telling the caller they lack permission, or telling them the thing does not exist. A shared workspace where everyone can see the document list is fine with the first. For a private project, the second one is the right answer, because "you don't have permission" itself reveals that a document with that number is sitting there.

Where the rules live is the next problem. Attaching permissions to people one at a time collapses as headcount grows, so most teams reach for role-based access control (RBAC). Permissions attach to roles such as admin, editor and viewer, and a person gets only a role. Forty-five people against twenty permission types is 900 decisions to keep straight; with four roles, it is four roles plus forty-five assignments.

Any service where different people see different things needs this on every request. The real question is not whether, but where the check sits. Of the three layers — screen, application programming interface (API), and data access — the one that has to hold is the API. The screen is drawn on the user's side and can be tampered with, and typing a URL directly sends a request that never passes through the screen at all.

The default for granting permissions comes from the principle of least privilege: give only what the job at hand requires, and when in doubt, give nothing. The opposite is more convenient, and it also sets the blast radius of a stolen account at everything that account could reach.

Three limits show up in practice. First, rules multiply until nobody holds the whole picture — six roles crossed with ten resource types is sixty combinations to verify. Second, automated scanners are bad at this. They find known attack patterns, but a check that is missing outright does not look like an error, so it takes a person writing scenarios, as in a penetration test. Broken access control sat at the top of the OWASP Top 10, the list of the flaws that break real web services most often, for years. Third, it costs something. A list screen showing 100 documents needs 100 decisions, so the more elaborate the rules, the sooner list views get slow.

"This endpoint has no authorization check. Change the document number and another team's meeting notes open."

Any logged-in user can open anything, and the verification belongs on the server.

"Stop assigning permissions person by person and group them into roles. We can't hand-attach twenty of them to forty-five people."

Per-person permission management has outgrown what the team can carry, so the proposal is to switch to roles.

"I hid the button on the screen. The server side is still as it was."

An admission that the request still goes through and only its trigger is out of sight.

Pagedeck fixed authorization properly right after the share-link incident. Grace pushed that week's feature schedule back and told the team to put permission checks in first. Theo gathered the conditionals scattered across every place a document got fetched into a single spot, so every path to reading a document went through the same check. Split the check across several places and someone misses one of them the next time a screen gets built.

Noa took the other half: what to show someone who opens a link they are not allowed to open. An error page on its own leaves a colleague who arrived by mistake with nowhere to go, so a button requesting access from the document owner went next to it.

The most common mistake is believing a hidden button is a blocked action. The delete button disappears from view, so the work looks finished. But the button is only a drawing, and a request can be sent without it. Type the URL directly, or replay a request from earlier, and the server processes it without knowing anything is off. That is why these incidents stay quiet: the screen looks properly locked, the team believes it is, and the passage that is actually open sits where nobody is looking. Hiding something on screen is guidance, not authorization.

The second mistake is treating authorization as a setting you configure once. Roles and rules take a lot of thought to design, so it feels finished when that design is done. What keeps moving is people. They switch teams, projects end, contractor accounts linger. Permissions get granted because someone asks and revoked because nobody asks, so left alone they accumulate in one direction. A year later, someone who moved to marketing can still read production data, and that stays invisible until an incident surfaces it.