API penetration testing for the endpoints your screens never call
GreySurface API penetration testing calls your REST and GraphQL endpoints directly, with a token for each kind of user, so an endpoint no screen uses is still tested.
What does an API penetration test cover?
Every route in scope, including undocumented ones we find. We test who may read and change each object, which operations a plain user reaches and which fields a client should never set.
Object level access
Whether changing an ID in a request returns another user's records.
For example, GET /v1/orders/{id}Authentication and tokens
How tokens are issued, replayed or refreshed past a user's sign-out.
For example, POST /v1/tokensMass assignment
Fields a client should never set, such as role or account owner.
For example, PATCH /v1/users/meSee the sample findingFunction level access
Whether a standard user can call admin or internal operations.
For example, POST /v1/admin/jobsRate and cost limits
Missing limits on costly calls that let one client exhaust the service.
For example, GET /v1/exportsOld and shadow routes
Retired versions and internal paths that still answer when called.
For example, GET /v0/accountsGraphQL and batching
Introspection, nested queries and batching that slip past limits.
For example, POST /graphqlInjection and SSRF
Input that reaches a query, a command or an internal address.
For example, GET /v1/fetch?url=
What we need from you
- A token for each role
- A spec or route list if available
- A test window you agree
On live systems
Live systems by default, inside agreed windows, with a named contact and no destructive actions.
Four steps, every call made as each role
We replay each call as a different user and change one field at a time. Every finding keeps its request and response, so your team can reproduce it.
Build the route map
What the tester does
We list every route from the spec, the traffic and the client code.
What you learn
Every route in scope, including the ones no screen ever calls.
Call as each role
What the tester does
We call each route with a token for every kind of user.
What you learn
Which routes answer a user who should never reach them.
Tamper with each request
What the tester does
We change IDs and fields one at a time to cross a boundary.
What you learn
Where an object check or a scope is missing on the server.
Keep the evidence
What the tester does
Each finding keeps the request and response that showed the flaw.
What you learn
A request your team can replay to see the finding again.
A tester leads every step. AI speeds up recon, triage and reporting, and a person reviews every finding before it reaches you.
Three attack paths that bypass your screens
Each sample calls a route directly, without the screens that normally limit what a user can send.
- Sample
One account reads another's orders
A free account changes the order number in one request. The reply is a stranger's invoice and address.
- Sample
A hidden admin route still answers
Support agents never see the admin screens. Their login still calls the admin API and disables accounts.
- Sample
An old version skips a new check
The new release checks the tenant on every order route. The previous version is still live and skips it.
Sample finding: a role set through the profile endpoint
From Acme Corp, a fictional client: the request we sent, the response that came back, the business risk and the one-line fix.
Users can make themselves admin through the profile endpoint
WherePATCH /v1/users/me
Request, signed in as a customer
PATCH /v1/users/me HTTP/2
Host: api.acme-corp.com
{"role": "admin"}Response
HTTP/2 200 OK
{"id": 2291, "role": "admin"}- Business risk
- Any account could give itself admin rights, and with them every customer's data.
- Fix
- Accept only the fields a user may set, and set role on the server.
Removed: user.update(body)
Added: user.update(allowed(body))
Checked by a tester before it reached the report.
Findings ordered by endpoint, each with its server rule
Each endpoint carries the field at fault and the server rule to add. Leadership receives an executive briefing that states the risk in business terms.
Report
Findings, proof and fixes
Fix guidance
A server-side rule named for every endpoint
Executive briefing
Which endpoints to fix first
One retest within 30 days of the report
Role field now ignored
Built for public, partner and internal APIs
Teams shipping a public or partner API, a mobile backend, or a service mesh where authorisation lives in code rather than on a screen.
Platform APIs
Public and partner APIs where a wrong object check leaks another tenant.
Mobile backends
The API behind an app, tested without the app in the way.
Service meshes
Internal services that trust each other more than an attacker should.
When to book it
- Before a public launchTest the API before partners and customers start calling it.
- After new endpoints shipA release adds routes, roles or fields that change who can reach what.
- For a customer security reviewA buyer's questionnaire asks for a recent API test with proof.
- After an auth changeNew tokens, scopes or single sign-on change what each role can reach.
- Behind a new mobile appA mobile or partner client exposes the API to the open internet.
Aligned with OWASP and CWE for APIs
Testing follows these standards, so your team can read the method against references it already uses.
OWASP Top 10
The most critical web application risks
OWASP ASVS
Application Security Verification Standard
CWE Top 25
The most dangerous software weaknesses
Aligned with, never certified by. Names belong to their owners; no endorsement implied.
Scoping an API test
We reply to every quote request within one business day, from info@greysurface.com.
Do you test GraphQL as well as REST?
Yes. We test REST and GraphQL, including introspection and batched queries, as each kind of user you give us a token for.
What do you need from us to start?
A token for each role you want tested and the address of the API. A specification or route list helps us map it faster.
Do you test authentication and rate limits?
Yes. We check how tokens are issued, replayed and refreshed, and whether costly calls carry the rate limits that stop one client exhausting them.
Do you test the live API?
Yes, by default. We test your live API inside a window you agree, with a named contact and no destructive actions.
Will testing disrupt the API or its users?
Every call stays inside the agreed scope and window, with a named contact and no destructive actions.
Is a retest included?
Yes. Every API test includes one retest of the findings we reported, within 30 days of the report.