Authentication and access control audit, who can do what.
Broken access control sits at the top of the OWASP list, and by a wide margin it is the most common thing we find. What makes it particular: the request that exploits it looks entirely normal. Nothing malformed, no suspicious character, no alert anywhere. Just an account obtaining something nobody meant to give it.
Who is allowed to read record 8340?
SQL injection announces itself: there is a stray quote, syntax that has no business being there, a log file lighting up. A broken access control does none of that. The attacker signs in with their real account, calls a legitimate URL, and swaps one number for another. From the server's point of view, everything is in order.
That is why it survives tooling, web application firewalls and, very often, code review. The code does exactly what it was told: it returns record 8340. What is missing is the line checking that record 8340 belongs to whoever asked for it. That line goes missing most reliably in whatever was added later, in a hurry, for a feature that was supposed to be temporary.
The risk grows with the product's success. An application starts with two roles and a handful of screens. Three years later it has seven, plus exceptions, plus a mobile API doing its own checks, plus an internal back office. Nobody holds the complete matrix in their head any more, and the gaps in it are exactly where the problems live.
The attacker does not always have to create an account to get started. A credential recovered from a data breach is usually enough, replayed against your application until one is accepted, and a free tool already says which breaches an address appears in. What that buys them is not administrator access, it is an ordinary account. What an ordinary account can reach is exactly what this engagement measures.
The lines we try to cross.
Every line below is a boundary your application is supposed to hold. Our job is to methodically try to get past it.
- Horizontal access (IDOR, BOLA): reaching another same-level account's data by changing an identifier, a share token or a document number.
- Vertical escalation: obtaining an admin-only action from a standard account, by calling the function directly rather than through the interface that merely hides it.
- Multi-tenant isolation: crossing the wall between two customers of the same platform, the single most expensive defect a SaaS product can ship.
- Interface and API divergence: a rule enforced on screen but absent from the call behind it, or present on web and forgotten on mobile.
- Session lifecycle: real expiry, invalidation on logout and on password change, parallel sessions, tokens that outlive revocation.
- Tokens and signatures: accepted algorithm, signature verification, role claims editable client-side, validity window and refresh handling.
- Account takeover: password reset, email change, invitation links, one-time codes that are replayable or guessable.
- Second factor: bypass through a route that ignores it, through an alternative signup flow, or through a token issued before it was validated.
How an engagement runs.
Rebuilding the permission model
We write down together what each role is supposed to be able to do. A lot of clients discover at this point that the document does not exist anywhere, or no longer matches the application. That is already a result: you cannot defend a boundary you never drew.
Accounts and data sets
We create, or you provide, the accounts needed, each with data of its own: documents, orders, messages. Without distinct data there is no way to prove a boundary was crossed.
Inventory of sensitive actions
We walk the application with the most privileged account and record every action that reads or changes something that matters. That inventory becomes the list of cases to replay.
Systematic breaching
Every action is replayed with every role, then with identifiers belonging to another account, then to another organization. It is repetitive, it takes time, and it is precisely what no tool can do on your behalf.
Chaining
An isolated access is worth little. A chain is worth a great deal. We check how far a single breach reaches: does an identifier picked up here unlock a function over there, and how far down does it go.
Report and retest
You get the matrix showing what holds and what gives, every breach with its request and its proof, and the fix expected. After your corrections, we replay every affected case. Report example.
What it looks like in practice.
Real findings, reported and fixed. Clients and perimeters are never disclosed.
Common questions.
How is this different from a normal pentest?
A pentest covers a wide front: injection, configuration, exposure, permissions. This engagement covers a single axis, but exhaustively. Where a general test checks a handful of representative accesses, here we build the full permission matrix and push against every cell of it. It is the right call when your application has many roles or several client organizations.
How many test accounts should I prepare?
Two accounts at the same level as an absolute minimum, otherwise horizontal access cannot be tested at all: we need to try reaching one account's data from the other. Then one account per privilege level, and if you are multi-tenant, two separate organizations with data of their own.
Do you test production or a dedicated environment?
A staging environment close to production is ideal, because it allows manipulations one would not risk elsewhere. On production we work only with accounts and data created for the audit, and we do nothing destructive. Both work. What matters is deciding beforehand.
Why do scanners never find these flaws?
Because a tool does not know your permission model. When it sends a request and gets a 200 back with data in it, it concludes everything is fine: nothing in that response tells it this account should not have seen it. That knowledge exists only in your head and in your specifications.
We have SSO and MFA. Doesn't that cover it?
That covers authentication, meaning proof that you are who you claim to be. It says nothing about authorization, meaning what you are allowed to do once inside. Most of what we find here involves perfectly authenticated users, often with a second factor.
Other services.
Web penetration testing
If you want broad coverage rather than one deep angle, web penetration testing includes permissions among the other families.
Read moreAPI security audit
When the application exposes an API, the same boundaries have to be checked at the endpoint level, where no interface hides anything.
Read moreHave your access controls tested.
Tell us how many distinct roles exist in your application, whether several client organizations share it, and whether a mobile API runs its own checks. We come back with a scope and a quote. First conversation with no commitment, full confidentiality.