Case study
Finding the authorisation gaps before launch, not after
A platform preparing to launch asked for a web, API and cloud assessment. The interesting findings were not missing patches but authorisation decisions the application made correctly in the interface and incorrectly in the API behind it.
Illustrative. Engagement reports are confidential. No client, system, date or figure here is real. This is a composite showing the shape of the work and the class of finding.
The situation
A team was weeks from opening a platform to real users. The application had been built quickly, reviewed internally, and scanned with the usual tooling, which had come back close to clean. The question they asked was the right one: not "are we vulnerable" but "what would someone who actually tried get to?"
How it was approached
- Mapped the roles the product intends to have, then tested each boundary from the account below it rather than from an administrator's view
- Worked against the API directly instead of only through the interface, because the interface hides endpoints and enforces rules the server may not
- Reviewed cloud identity by following privilege paths from a hypothetical initial foothold, rather than linting policy documents in isolation
- Retested every finding after remediation rather than accepting a code change as proof
What turned up
Authorisation enforced in the interface, not the server
Several actions were hidden from users who should not perform them, but the endpoints behind those actions accepted the request from any authenticated session. A scanner cannot find this: every response is a valid 200, and only knowing what the roles are supposed to mean makes it a finding.
Object-level access checks keyed on the wrong thing
Endpoints confirmed the caller was logged in and that the record existed, but not that the record belonged to the caller. This is the most common serious API finding in practice and it is almost always invisible from the front end.
Cloud roles broader than the workloads needed
Individually defensible permissions combined into a path from a low-value workload to data that workload had no reason to reach. Reported as the path an attacker walks, not as a list of policy diffs.
Outcome
Findings were fixed before launch and each fix was verified by retest rather than accepted on trust. The team went live knowing which failure classes had been closed and which residual risks they had consciously accepted.
The lesson
Automated scanning is good at known-bad and blind to "working exactly as written, and wrong." Authorisation is a business-logic question: it needs someone who knows what the roles are meant to mean, testing the server rather than the screen.