Authentication and access control audit, who can do what.
An authentication and access control audit checks that every account can only reach its own data and its own actions, never those of another user, an administrator or another customer organization. Our in-house tools cross every action with every account, and our hands-on expertise spots the access nobody meant to grant.
At a glance
- ScopeWeb applications, customer portals, back offices and APIs, as soon as there is more than one role.
- What we look forHorizontal access between accounts, vertical escalation, isolation between organizations, sessions and tokens.
- What we need from youTwo accounts per level, and two separate organizations if your platform hosts several.
- What you getA report with your tested permission matrix and proof for every finding, a debrief with your team and a retest within 60 days.
Vulnerabilities found across these sectors
- Public services (.gouv.fr)
- CAC 40 groups
- Luxury leaders
- National media
- Local authorities
An injection gets noticed. One access too many never does.
The attacker logs in with their real account, calls a legitimate address and swaps one number for another. As far as the server is concerned, everything is in order.
That is why these flaws get past tools, web application firewalls and often code reviews. The code does exactly what it was asked to do: it returns the record requested. What is missing is the line that checks the record belongs to whoever is asking, and it gets forgotten above all where a feature was added in a hurry.
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, a mobile API and an internal back office. Nobody holds the full matrix anymore, and its gaps are exactly where the problems live.
The attacker does not even need privileged access to start: an ordinary account is enough, sometimes taken from a data breach. What an ordinary account can reach is exactly what this engagement measures.
Before the fix
A member of organization 12 lists the members of organization 13: another customer on the platform.
After the fix
The server checks the account's organization on every call: 13 is off limits.
The same account, the organization next door. Flip the card to see the fix.
When to audit your access control.
An application's permissions never stay the way they were designed: every role, every customer and every new entry point shifts them.
Before adding a role
A new role crosses every other one: every existing permission deserves a second look.
Before onboarding large customers
Several organizations on one platform: keeping them apart becomes your core promise.
When a mobile app launches
A second door to the same data, which often runs its own checks.
After moving to SSO
Changing how people get in does not change what they can do once inside: both need checking.
Once a year
Roles pile up, exceptions too, and the matrix gets hard to follow.
What we try to get past.
Six boundaries your application is supposed to hold. Our job is to try to get through, methodically.
Horizontal access
Reaching another same-level account's data by changing an identifier, a share link or a document number: an An insecure direct object reference: changing a number in a request is enough to reach someone else's data..
Vertical escalation
Getting an admin-only action out of a standard account, by calling the function the interface merely hides.
Isolation between organizations
Crossing the boundary between two customers on the same platform, one of the costliest flaws a SaaS product can have.
Interface, API and mobile
A rule enforced on screen but missing from the call behind it, or present on the web and forgotten in the mobile app.
Sessions and tokens
Real expiry, logout, password changes, parallel sessions, and The digital badge an account receives at login: as long as it stays valid, it opens doors without asking for the password again. that outlive their revocation.
Account recovery and second factor
Password reset, email changes, invitation links, and the paths where the second factor is never asked for.
How an access control audit runs.
Six steps, from the permission model to the retest, to check every cell of the matrix.
Read the full methodology- 01
Permission model
Together, we write down what each role is supposed to be able to do. Many clients find out at this point that the document exists nowhere, or no longer matches the application. That is already a finding: you cannot defend a boundary you never drew.
- 02
Accounts and data
We create, or you provide, the accounts we need, each with data of its own: documents, orders, messages. Without separate data, there is no way to prove a boundary was crossed.
- 03
Action inventory
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.
- 04
Crossing the lines
Every action is replayed with every role, then with identifiers belonging to another account, then to another organization. Our in-house tools take care of the repetition, and hands-on expertise judges every response, which a scanner cannot do on its own.
- 05
Chaining
One isolated access is worth little. A chain is worth a lot. We check what can be reached starting from a single gap, and how far down the chain goes.
- 06
Report and retest
You get the matrix with what holds and what gives, every crossing with its request and its proof, and the expected fix. Once you have fixed things, we replay every case concerned. See a sample report.
Black, grey or white box.
What you give us up front determines how far the audit can reach. Here, almost everything happens after login: our advice, accounts at every level.
Black box: just the address
- You provide
- The application's address, with no account at all.
- The test reaches
- Login, sign-up and account recovery, seen from the outside. The permissions themselves stay out of reach.
- Choose it when
- Rarely for this engagement, which is about what happens after login.
Grey box: accounts at every level Our advice
- You provide
- Two accounts per level, and two separate organizations if your platform hosts several.
- The test reaches
- The whole matrix: every action replayed with every role, then with another account's and another organization's identifiers.
- Choose it when
- Almost always: this is the setup this engagement is built for.
White box: the accounts and the code
- You provide
- The accounts, plus read access to the code that decides permissions.
- The test reaches
- Everything above, plus the missing checks the interface gives no way to reach, read straight from the code.
- Choose it when
- When the permission model is complex, or spread across several services.
What this looks like in practice.
Real flaws found in access control, all fixed since.
reports sent with a critical vulnerability
Out of more than 485 reports sent, in penetration tests and bug bounty.
reports sent in total
In penetration tests and bug bounty.
Active in bug bounty
Researchers on YesWeHack and Intigriti, two European bug bounty platforms where every flaw is checked before it is accepted.
- CriticalFixed
IDOR
Downloading any customer's invoices by incrementing a document number.
- CriticalFixed
Tenant isolation
A user in one organization able to list the members and projects of another organization.
- CriticalFixed
Vertical escalation
Admin route callable directly by a standard account, the check existing only in the interface.
- HighFixed
Account takeover
Predictable reset token, allowing an account to be taken over from its email address alone.
We never disclose a client's name, nor any detail that would let anyone recognize them.
The report you receive.
Every crossing proven, explained and tied to the check that is missing: readable for your leadership, applicable for your developers.
Every customer's invoices, downloadable from any account by changing a document number.
SeverityCritical, from a customer account
Requests, screenshots and reproduction steps: redacted in this sample. Your report contains every one of them, ready to replay.
Check on every download that the document belongs to the account asking for it, and deny by default.
PriorityImmediate, retest included
Another organization's members and projects, visible from an ordinary account: the platform's promise of isolation, broken.
SeverityCritical, from one tenant to another
Requests, screenshots and reproduction steps: redacted in this sample. Your report contains every one of them, ready to replay.
Tie every request to the logged-in account's organization, on the server, and filter every read by it.
PriorityImmediate, retest included
An admin route a standard account could call: the check existed only in the interface, which hid the button.
SeverityCritical, from a standard account
Requests, screenshots and reproduction steps: redacted in this sample. Your report contains every one of them, ready to replay.
Check the role on the server in every admin function, whatever screen calls it.
PriorityImmediate, retest included
Tested permission matrix
What each role should be able to do, what it can actually do, and every gap proven.
Replayable requests
Every crossing with its request and its proof, which your developers replay with two test accounts.
Business impact
Which data, which customers, which organizations are exposed, spelled out plainly for your leadership.
The missing check
For every flaw, the server-side check to add and where to add it.
Retest included
Once you have fixed things, we replay every case concerned, not just the original flaw.
Debrief with your team
A session with your developers to walk through the matrix and prioritize the fixes.
What it costs.
Every engagement is quoted, and here is why: the work depends on the size of your permission matrix, which only scoping can measure. To get your bearings, here is our pricing by kind of engagement.
From€7,500 incl. tax
Business application or SaaS
Ten to fifteen days or more. Several roles, several customer organizations: the full permission matrix.
From€3,200 incl. tax
Focused API
Four to eight days. An API's access control, checked for every role.
From€2,700 incl. tax
Brochure site or store
Four to six days. The customer area of a site or store, with one or two roles: access between accounts, sessions and account recovery.
What moves the price
First, the number of roles: every role you add crosses all the others, and the number of cases to replay grows fast.
Then the number of organizations sharing the platform, and whether a mobile app runs its own checks: each one adds a boundary to test.
A first call, with no commitment, is enough to size your matrix. If it turns out smaller than you thought, we will tell you.
25permission checks
Should be grantedShould be refused
Every square is a check. Is this role allowed to take this action, and does the server really check it? Add a role, and that is a whole column to push against.
Your access control, proven.
Security frameworks all ask you to restrict access, then to check that the restriction holds. Our report is the proof: matrix tested, method, crossings and verified fixes.
ISO/IEC 27001
Annex A, controls 5.15, 8.3 and 8.29
Access control, information access restriction, security testing: the report shows the matrix tested and what gave way.
PCI DSS
Requirements 7, 8 and 11.4
Restrict access to cardholder data to business need, identify every user, then test it.
SOC 2
Criterion CC6.1
Logical access sits at the heart of the CC6 criteria: an independent test of your access control is the evidence.
GDPR
Article 32
One customer reading another's data is a personal data breach. The report records the tests and the fixes.
NIS 2
Article 21
Access control policies, and an assessment of how well they work: the tested matrix demonstrates it.
DORA
Articles 9 and 24
For financial entities, access limited to what is strictly needed, and tests that verify it.
We do not issue certifications: we provide the technical evidence your auditors ask for. Broken access control is the first category of the A nonprofit foundation that publishes the most widely used security references, including the Top 10 web application risks. Top 10. Our method follows the structure of the Penetration Testing Execution Standard: the outline of a penetration test engagement, from scoping to report., detailed here.
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 your platform hosts several organizations, two separate ones 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 miss 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.
The other services.
Permissions are only one axis? Another engagement can cover the rest.
Web penetration testing
If you want broad coverage rather than a single axis, web penetration testing includes permissions among other families of flaws.
See the serviceAPI security audit
When the application exposes an API, the same boundaries need checking on the routes, where the interface no longer hides anything.
See the serviceWebsite security audit
For a brochure site, an online store or a CMS: exposure, hosting and forms.
See the serviceWordPress penetration testing
If your members area runs on WordPress, its roles and plugins call for an approach of their own.
See the serviceGet your access control audited.
Your customer portal is a target.
Tell us how many distinct roles your application has, whether several customer organizations share it, and whether a mobile API runs its own checks. We'll get back to you with a scoping proposal and a quote. The first call commits you to nothing.