Broken authorization is one of the most serious problems a web application or API can have. It is also one of the problems automated scanners are worst at finding.
That is not a criticism of scanners. They are good at what they are built for. But authorization flaws are a different kind of problem, and understanding why helps you decide where to spend your testing budget.
What broken authorization looks like
Authentication answers “who are you?”. Authorization answers “are you allowed to do this?”.
Broken authorization means the application gets the second question wrong. Some common shapes:
- A user changes an ID in a URL and sees another customer’s invoice.
- A read-only user calls an admin API endpoint directly and it works.
- A user in one company adds themselves to another company’s workspace.
- A support feature lets staff view any account, and a normal user can reach it too.
None of these involve strange input or broken code in the usual sense. Every request is well formed. The server simply says yes when it should say no.
Why scanners struggle
Scanners don’t know your business rules
A scanner sends requests and looks for signs of trouble: error messages, reflected input, known vulnerable versions. It has no idea that invoice 4512 belongs to company A and must never be shown to company B.
To a scanner, a 200 OK response with a valid invoice looks like success. It looks exactly like normal behaviour, because from the server’s point of view it is.
Scanners usually test as one user
Finding authorization flaws means comparing what different users can do. You need at least two accounts, often in two separate tenants, and sometimes several roles.
Most scanning setups use a single session. Even when they support several, they don’t know which responses each user should or shouldn’t get. That judgement needs someone who understands the product.
The flaw is in the absence of a check
Many vulnerabilities leave a trace you can detect: a database error, a script running, a slow response. A missing authorization check leaves nothing. The only evidence is that the server returned data it shouldn’t have, and only a person who knows the rules can tell.
Logic lives across several steps
Some authorization flaws only appear across a sequence. A user starts an approval flow, skips the approval step, and calls the final “execute” endpoint directly. Each request on its own looks fine. The problem is the order, and scanners don’t reason about workflows.
How a manual tester finds them
Build a map of roles and objects
Before testing anything, a tester works out who the users are and what they should be able to do. Admin, manager, member, viewer. Which tenant each one belongs to. Which objects they own: invoices, projects, files, users.
This is why we ask for test accounts for every role, ideally in two tenants. It turns vague rules into something testable.
Replay requests as the wrong user
The core technique is simple. Capture a request made by one user, then replay it as someone who shouldn’t have access:
- the same request with a lower-privilege session
- the same request with a session from another tenant
- the same request with no session at all
If the response still contains data, or the action still succeeds, that is a finding.
Change identifiers deliberately
Testers look for any value the client sends that the server might trust: object IDs, account IDs, role names, tenant IDs, even hidden form fields. Each one gets changed to point at something the user doesn’t own. Sequential numeric IDs make this easier, but random IDs don’t make it safe. They only make it harder to guess.
Walk the workflows out of order
For multi-step processes, testers try skipping steps, repeating them, or jumping straight to the end. Payment, approval, invitation and password reset flows are common places where the server assumes the user arrived the “right” way.
Prove the impact, then stop
When a tester finds an issue, they confirm it with the minimum access needed and record clear evidence: the request, the response, and which user made it. That evidence goes into the report with steps to reproduce, so your engineers can see the problem for themselves.
What this means for your testing plan
Scanners still have a place. They are useful for catching known vulnerable components, missing security headers and common misconfigurations, and they can run often and cheaply.
But if your application has multiple roles or multiple customers sharing one platform, authorization needs a human. Make sure any penetration test you commission includes:
- testing with accounts for every role
- cross-tenant testing with at least two tenants
- direct API testing, not only the user interface
- workflow and business-logic testing
You can read how we approach this in our methodology, or see what an authorization finding looks like in our sample report.
Want a tester to check your access controls properly? Tell us what you need tested.