Why access control is a business risk, not just a technical one
A simple way to think about authorization problems before they turn into customer or operational problems.
A lot of security conversations stop at “broken access control.”
That is useful as a finding. It is not the whole story.
The more useful question is: what does that access actually allow someone to do?
Start with the asset
Imagine an API that returns an invoice when you provide an invoice ID.
If the server only checks whether the request is authenticated, an attacker may be able to change the ID and retrieve another customer's invoice.
Technically, the problem is authorization. From a business perspective, the problem could be customer confidentiality, contractual exposure, regulatory obligations or loss of trust.
The three questions I like
- Who is making the request?
- What are they allowed to access?
- Does the server enforce that decision every time?
A UI can hide a button. That is not authorization. The API needs to make the decision.
Why this matters for growing products
Early-stage products evolve quickly. A feature starts simple, then teams add roles, organizations, administrators, integrations and background jobs. The permission model grows with it.
Sometimes it grows intentionally. Sometimes it grows by accident.
That is why authorization deserves a second look before a product enters a new customer segment.
The practical takeaway
Do not ask only, “Do we have authentication?” Ask: “Can every important action be performed only by the person or service that should be able to perform it?”