API security audit, every access checked.
An API security audit, or API penetration test, checks that every REST, JSON or GraphQL endpoint exposes only what it should, and only to whoever should reach it. Our in-house tools replay every route with every role, and our hands-on expertise spots the responses that should never have come back. On an API, a large share of serious flaws hide in authorization.
At a glance
- ScopeYour REST, JSON and GraphQL endpoints, with their authentication and their webhooks.
- What we look forObjects reachable by accounts that should not touch them, fields that can be forced, responses that say too much.
- What we need from youTwo accounts at the same level, then one per role. Your OpenAPI specification or GraphQL schema, if you have one.
- What you getA report with the authorization 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
Your app sends "customer". An attacker sends "admin".
And they don't stop at the routes your site uses: old versions, internal routes, forgotten endpoints, anything that still answers. If your API accepts one word too many, a free account becomes an administrator.
Your app only sends the fields it expects and only calls the routes it needs. An attacker reads those requests, then rewrites them: a "role" field added to a sign-up, another customer's identifier, an admin route called with an ordinary token.
None of it takes sophisticated tooling, and none of it leaves an error in your logs: as far as the server is concerned, everything went fine. Yet they are among the most serious flaws we find in APIs.
It is also why a vulnerability scan is no substitute for a penetration test: no signature knows who is allowed to read what.
Before the fix
A customer token opens the list of every account: the route never checks the caller's role.
After the fix
The route checks the role on every call: a customer token gets turned away.
The same token, an admin route. Flip the card to see the fix.
When to audit your API.
An API changes faster than the applications that use it: every new route, every new integration, every new version is surface to check.
Before opening it to partners
The moment a third party gets a key, every route becomes a door they can call however they like.
When a mobile app ships
An app can be decompiled in minutes: the routes it calls, and the ones it no longer calls, become public.
Before a new version
A v2 brings its own routes, and the v1 often stays online, with its old checks.
Once a year
Your frameworks and your customers expect regular testing, and your routes change every sprint.
After an incident or an alert
Find out which route leaked, and make sure its neighbors are not saying the same thing.
What we test.
Six families of API flaws we look for on every audit, and the route where each one hides.
Object level authorization
Reaching another account's object, an order or a file, by changing its identifier in an otherwise legitimate request.: reading or changing another account's data by swapping an identifier.
Function level authorization
Calling a restricted function, such as an admin route, with an account that has no right to it.: exports, deletions or role management called with a standard account.
Forced fields and exposed data
Slipping a field into a request body that the API should never have accepted, such as a role or a payment status., and responses that return the whole object when the screen only shows three of its fields.
Authentication and tokens
Signature and algorithm checks on The signed token that carries the caller's identity. A poorly checked signature is all it takes to forge one., expiry, revocation, refresh flows, OAuth and OIDC, API keys.
GraphQL
The query that asks a GraphQL API to describe its whole schema: a complete map for an attacker if it stays open. left open, expensive nested queries, checks placed on the root query instead of the resolvers, aliases used to get around limits.
Injection, rate limits and integrations
SQL and NoSQL injection through filters, Making your server call an address the attacker chooses, often your internal network. on outbound calls, unsigned or replayable webhooks, routes with no rate limit, old versions still online.
How an API audit runs.
Six steps, from scoping to retest, built around the authorization matrix.
Read the full methodology- 01
Scoping and access
We list the APIs in play, the environments and the roles to cover. Ideally you provide an OpenAPI specification or a GraphQL schema, plus distinct accounts: at least two at the same level, for horizontal access, then one per privilege level. NDA as soon as we get into technical details, penetration test authorization agreement once the quote is signed, before any access.
- 02
Route mapping
A full inventory of endpoints, accepted methods, parameters and response shapes. This step routinely surfaces forgotten routes: old versions still online, internal endpoints reachable from outside, debug routes left active.
- 03
Authorization matrix
The core of the audit. For every sensitive route, we replay the same request with each role, and with object identifiers that belong to other accounts. Our in-house tools run the matrix, and we read every response that should never have come back.
- 04
Data manipulation
Extra fields in request bodies, altered types, boundary values, unexpected nested structures. We look for what the server accepts when it should not, all the way to a demonstrated impact.
- 05
Report and debrief
A report ranked by real severity, with the exact request behind each flaw, what an attacker would get from it and the fix to apply. Then a debrief with your team. See a sample report.
- 06
Retest & close
Once your fixes are deployed, we replay every request involved, with every role concerned. A route fixed for one role and missed for another is still open: the retest is included to make sure.
Black, grey or white box.
What you give us up front determines how far the audit can reach. For an API, our advice: one token per role, plus your specification.
Black box: just the URL
- You provide
- The API's address, or the app that calls it. No accounts, no documentation.
- The test reaches
- The public routes, and the ones we find by watching your apps' traffic. Authentication stops the rest, unless a flaw gets us past it.
- Choose it when
- You want to know what a stranger can get out of your API from the internet. Mapping then takes a good share of the time.
Grey box: one token per role Our advice
- You provide
- Two accounts at the same level, then one per role, and your OpenAPI specification or GraphQL schema if you have one.
- The test reaches
- Every route with every role, including the ones no app calls yet: the full authorization matrix.
- Choose it when
- In almost every case. It is what finds authorization flaws, which are common and often serious in an API.
White box: the tokens and the code
- You provide
- The accounts and the specification, plus access to the code of your controllers and resolvers.
- The test reaches
- Everything above, plus the paths the documentation leaves out and the authorization logic as it is actually written.
- Choose it when
- On a critical, bespoke API, when depth matters more than realism.
What this looks like in practice.
Real flaws found in APIs, 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
BOLA
Any customer's data readable by incrementing an identifier in an otherwise legitimate request.
- CriticalFixed
Mass assignment
A standard account promoted to administrator through an unfiltered field at sign-up.
- HighFixed
Data exposure
An API response returning personal fields the interface never displayed.
- HighFixed
GraphQL
Access control enforced on the root query but missing from nested resolvers, bypassed through a relation.
- HighFixed
Billing bypass
Full use of a paid API without ever triggering the payment.
We never disclose a client's name, nor any detail that would let anyone recognize them.
The report you receive.
Every flaw with the request that proves it, what it exposes and how to fix it: readable for your leadership, usable for your developers.
Any customer's data, readable by incrementing an identifier in an otherwise legitimate request. The whole customer base exposed, without a single error in the logs.
SeverityCritical, one identifier incremented
Requests, responses and reproduction steps: redacted in this sample. Your report contains every one of them, ready to replay.
Check on the server, for every route and every object requested, that it belongs to the calling account, and deny by default.
PriorityImmediate, retest included
A standard account promoted to administrator by adding a single field to the sign-up request: full access to the platform.
SeverityCritical, one field added
Requests, responses and reproduction steps: redacted in this sample. Your report contains every one of them, ready to replay.
Accept only the expected fields on every route, and never bind a request body straight to the data model.
PriorityImmediate, retest included
The access check on the root query was missing from the nested resolvers: other accounts' objects, reached by going through a relation.
SeverityHigh, through a relation
Requests, responses and reproduction steps: redacted in this sample. Your report contains every one of them, ready to replay.
Enforce authorization in every resolver, on the object returned, not just on the entry query.
PriorityHigh, retest included
Authorization matrix
Every sensitive route crossed with every role: what should answer, what should refuse, and what answers when it should not.
Replayable requests
Every flaw with the exact request, ready to replay in your HTTP client or your test suite.
Business impact
Which data, which accounts, which operations are exposed, spelled out plainly for your leadership.
Precise remediation
The fix to apply on each route or resolver involved, for the team that maintains the API.
Retest included
Once your fixes are live, every request is replayed with every role: a flaw is closed only when it no longer gets through.
Debrief with your team
A session with your developers to walk through the routes involved, answer their questions and prioritize the fixes.
What it costs.
Every engagement is quoted, and here is why: the real size of an API only shows during scoping. To get your bearings, here is our pricing by kind of engagement.
From€3,200 incl. tax
Focused API
Four to eight days. One REST or GraphQL API, its roles and its sensitive routes, webhooks included.
From€7,500 incl. tax
Business application or SaaS
Ten to fifteen days or more. The API and the apps that use it, with roles and permissions that overlap.
From€2,700 incl. tax
Brochure site or store
Four to six days. The public site and the light API behind it: forms, customer area, cart.
What moves the price
On an API, two numbers outweigh everything else. First, the number of sensitive routes: not the total route count, but the ones that handle data or permissions. Then the number of roles. They multiply: the authorization matrix to verify is the product of the two.
On top of that, GraphQL calls for its own approach, and inbound webhooks or third-party integrations each add surface. An up-to-date The file that describes every route of your API, its parameters and its responses. cuts mapping time noticeably, and the quote with it.
The first call, with no commitment, is there to pin down those two numbers. If your API turns out simpler than you thought, we will tell you.
25requests to replay
Should answerShould refuse
Every square is a request. The same route, replayed with each role: it should answer, or refuse. Five routes and two roles make ten requests, five roles make twenty-five. On a real API that product runs into the hundreds, and it is what sets the length of the audit.
Evidence for your audits.
The frameworks that require you to test your security controls cover your APIs too. Our report is evidence your auditors know how to read: routes tested, method, proof and verified fixes.
ISO/IEC 27001
Annex A, controls 8.8 and 8.29
APIs fall within the scope of security testing. The report shows which routes were tested, what was found, then fixed.
PCI DSS
Requirement 11.4
An API that touches payments is in scope for penetration testing. The included retest documents every fix.
SOC 2
Criterion CC4.1
A recent test of your API, often requested as an independent evaluation of your access controls.
GDPR
Article 32
An API that serves personal data has to be tested regularly. The report is a dated record of it.
NIS 2
Article 21
Assessing how effective your security measures are, including on the interfaces you open to partners.
DORA
Articles 24 and 25
For financial entities, digital resilience testing that also covers the APIs opened to third parties.
We do not issue certifications: we provide the technical evidence your auditors ask for. Our method covers the A non-profit foundation that publishes the most widely used security references, including the API Security Top 10, the list of API risks we cover. API Security Top 10 and follows the structure of the Penetration Testing Execution Standard: the outline of a penetration test engagement, from scoping to report., detailed here.
Do I need to provide API documentation?
It is not required, but an OpenAPI specification or a GraphQL schema speeds up coverage considerably and lets us test routes no app calls yet. Without one, we map the API by watching the real traffic from your client apps.
My API is protected by a key. Isn't that enough?
No. A key answers the question "who is calling", never "are they allowed to reach this specific object". A large share of the serious flaws we find in APIs are object level authorization failures, not authentication failures.
Is GraphQL riskier than REST?
Not inherently, but it moves the risk. Introspection often exposes the entire schema, nested queries reach objects through paths nobody anticipated, and a single deep query can cost the server dearly. Checks have to sit in the resolver, not on the route.
Do you test webhooks and third-party integrations too?
Yes, when they are in scope. Inbound webhooks are an often forgotten entry point: unverified signatures, replayable requests, or handlers that trust whatever payload they receive. OAuth and OIDC are covered as well.
Can you audit an API in production?
Yes, that is the most common case. Destructive tests and load tests are excluded by default. On write routes, we work on resources created for the occasion rather than on your real data.
How long does an API audit take?
From four days for a focused API to several weeks for a platform with many roles. The length follows the number of sensitive routes multiplied by the number of roles, and it is set during scoping, before anything is signed.
Do you test the API behind a mobile app?
Yes, the API itself: it is often the most exposed part, because anyone can watch or decompile the app and replay its calls. Testing the native app, its local storage or its binary, is not our specialty: we will gladly point you to a specialist we trust.
The other services.
Is your API only part of what you expose? Another engagement can round it out.
Web penetration testing
The application that calls the API, its roles and its user flows, tested the way an attacker would.
See the serviceWordPress penetration testing
WordPress ships a REST API of its own, often open by default.
See the serviceWebsite security audit
Brochure site, online store or CMS: the security of what your visitors see.
See the serviceAuthentication and access control
Login, sessions, SSO and roles: who can get in, and how far.
See the serviceGet your API audited.
Your API is a target.
Tell us how many sensitive routes and roles you have, and whether you have an OpenAPI specification or a GraphQL schema. We'll get back to you with a scoping proposal and a quote. The first call commits you to nothing.