Testing API security
REST and GraphQL with valid credentials for several roles, along the OWASP API Security Top 10. The most common finding sits between authentication and authorisation.
The interface carries the data, not the screen
An API penetration test examines the interfaces of an application the way an attacker would call them: with valid credentials, with other people's identifiers, with fields nobody intended. What gets tested is not the screen but what the interface behind it actually gives out. Other names for the same thing: API pentest, API security testing, interface testing.
Behind every app and every portal there is an API, and that is where the data sits. The screen shows a user what they are allowed to see. The interface decides what they can actually retrieve.
We test REST and GraphQL interfaces with valid credentials for several roles, along the OWASP API Security Top 10. Where an OpenAPI description exists we work from it; where it does not, we capture the calls the app makes.
Authenticated yes, authorised no
The call carries a valid token, the application recognises the user, and then it hands out another customer's invoice. Between authentication and authorisation sits a check that is missing in the backend, because the screen never offers the other customer number in the first place.
In the OWASP list that stands first, as broken object level authorisation. It is found by changing one digit, and it is the reason we test with several accounts at once: a single account cannot show this gap.
What an API test covers
The OWASP API Security Top 10 names ten categories. Here they stand in five groups, so that the list stays readable; in the report every finding is mapped to its category. Which weighs heavier in your case depends on the interface.
Object and function permissions
Other people's identifiers, other tenants, administrative endpoints with an ordinary token. Plus fields the client is allowed to send although the backend should only read them: a change of role through a JSON field happens more often than expected. The classic, and the one with the largest consequences.
Authentication and tokens
How a token is issued, checked and revoked. Signature method, lifetime, renewal, and whether a logged-out session is really invalid. A token that keeps working after logout undoes every permission above it.
Consumption and business processes
Without rate limiting, a working login becomes the means to try accounts one after another or to pull data out page by page. Plus processes that are permitted individually and harmful in bulk: orders, invitations, vouchers.
Configuration and server-side requests
Error messages carrying too much, open management interfaces, missing security headers, and calls that make the server issue requests of its own into the internal network.
Inventory and third-party interfaces
Which versions of an interface are still reachable, and which of them nobody maintains. A forgotten v1 beside a maintained v3 is one of the most common finds. Plus the interfaces your application calls itself, and how it treats their responses.
How an API test works
The effort follows the number of endpoints and roles. Testing follows the OWASP API Security Top 10 and the BSI practical guide for IS penetration tests; every report goes through a second-pair-of-eyes review.
Fix scope and credentials
Which interfaces, which environment, which time window. We need one set of credentials per role, because the most important findings only show in the comparison between two accounts.
Record the endpoints
From an OpenAPI description if there is one, otherwise from the captured traffic of the app or the front end. Plus the search for versions that still answer but appear in no documentation.
Test
Every endpoint against the categories of the OWASP list, confirmed by hand. Automated runs deliver the surface; the findings come about afterwards, manually.
Chain
What can be joined up: from somebody else's identifier to somebody else's tenant, from a submitted field to a higher role. The rating follows what was reachable in the end.
Report and retest
Findings with reproduction steps as a call your team can repeat, plus the risk rating. On request the check after the fix.
A report your team can work from.
Every finding comes placed: with risk, effort and the route to a fix.
Management summary
The position on one page, readable for management and the board.
Technical findings
Every finding with a unique finding ID, evidence and reproduction steps.
Risk rating to BSI
A traceable rating of every find against a recognised scheme.
Prioritised recommendations
Concrete recommendations in the order in which they take effect.
Closing meeting
On request, a joint walk-through of the results with your teams.
Retest
On request, a re-examination of the fixed weaknesses, with confirmation of the state.
What we need, and what is not included
From you we need the addresses of the interface, one valid set of credentials per role, a contact for the duration of the test and a written release. An OpenAPI description shortens the recording but is not a condition. If there is a test environment we test there; otherwise in production with agreed restrictions, and whatever we change we log and undo.
Not included are attacks on people and on availability. Phishing simulations and social engineering are services of their own, and we do not carry out load or denial of service tests. If the screen belongs to it, we test it in the same engagement as a web application; if the interface sits in a cloud environment, its permissions belong in the cloud test. A source code review is not a penetration test but a service of its own that combines well with one.
Common questions about API testing
Yes, and ideally for several roles. An API test without valid tokens only checks what is reachable without authentication. The findings with substance lie in what a logged-in user reaches that is none of their business.
That is the normal case. We capture the traffic of the app or the front end and derive the endpoints from it. An existing OpenAPI file shortens the recording but is not a condition.
In a modern application the API is the larger part. We test both in the same engagement when front end and backend belong together.
Certifications and memberships.
Talk to us.
A first conversation usually takes 30 minutes. We look at where you stand and tell you frankly whether we are the right partner.