API security testing for REST and GraphQL
Gjethe tests APIs directly, the way attackers do: authorisation on each object, authentication, how much data responses return, mass assignment, rate limits and business flows. Testing follows the OWASP API Security Top 10, and each finding comes with evidence, a fix and a retest.
- Free first consultation
- Written quote for your project
- Flexible payment milestones
At a glance
- API types
- REST, GraphQL, WebSocket
- Standard
- OWASP API Security Top 10
- Focus
- Authorisation, data exposure, rate limits
- Output
- Report, fixes and retest
Definition
What is API security testing?
API security testing is the assessment of an application programming interface for weaknesses that let callers reach data or functions they should not, by sending crafted requests directly to its endpoints.
Mobile apps, single-page web apps, partners and integrations all talk to your API. The interface may hide fields and buttons, but the API answers anyone who sends the right request. That is why APIs often expose more than intended: full records when the app shows only a name, actions reachable by changing an address, or no limit on how fast someone can try logins or pull data. API testing sets the interface aside and checks what the server itself allows.
Who is it for?
Teams with a public or partner API
Anything exposed to other developers is exposed to anyone who reads your docs.
Mobile app backends
The app is just one client; the API has to defend itself against any request.
Microservice architectures
Internal services often trust each other too much; we check those boundaries.
Products with payments or credits
Money, balances and quotas are prime targets for logic and rate-limit abuse.
What's included, and what you keep
What's included
- Review of API documentation and schema
- Endpoint and operation discovery
- Object-level authorisation testing
- Function-level authorisation testing
- Authentication and token handling review
- Excessive data exposure checks
- Mass assignment and input handling tests
- Rate limiting and resource abuse testing
- Business flow and sequence testing
- GraphQL-specific checks where relevant
- Transport and configuration review
- Report with evidence, fixes and a retest
What you receive
Handed over at the end. Yours to keep.
- API security test report
- Findings mapped to the OWASP API Top 10
- Clear write-up for each confirmed issue
- Fix recommendations per finding
- Retest report
OWASP API Security Top 10 areas we cover
| Area | Example of what we check |
|---|---|
| Broken object-level authorisation | Reading another user's record by changing an identifier |
| Broken authentication | Weak tokens, missing expiry, guessable credentials |
| Broken object property authorisation | Setting fields the caller should not control |
| Unrestricted resource consumption | No rate limits on costly or sensitive operations |
| Broken function-level authorisation | Calling admin operations as a normal user |
| Unrestricted access to business flows | Automating a flow meant to be done once |
| Server-side request forgery | The API fetching addresses a caller controls |
| Security misconfiguration | Verbose errors, debug endpoints, loose settings |
| Improper inventory management | Forgotten old versions still accepting requests |
| Unsafe third-party use | Trusting data from an external API without checks |
Why APIs leak more than the app shows
A web page shows a customer their own name and nothing more. The request behind it, though, might return the whole user record, including fields the page quietly ignores. Attackers read responses directly, so anything the server sends is effectively public to whoever can call the endpoint.
We test from the caller's side: every endpoint is exercised as different users and roles, with identifiers and fields changed, to see whether the server checks who is asking and returns only what they are allowed to see. GraphQL gets extra attention, because a single flexible query can reach far more than a fixed REST route if the rules are not enforced per field.
Why APIs need their own testing
It is tempting to assume that testing the website also tests the API behind it. It does not. The website uses the API in the ways its designers intended, through the buttons and screens they built. An attacker ignores all of that and calls the endpoints directly, in any order, with any values, as any account they can obtain. Whole categories of problem only appear from that angle: an endpoint that trusts a user ID from the request, a field that should be read-only but can be written, an operation with no limit on how often it runs.
Testing the API on its own also protects every client that depends on it. A single API usually serves a web app, a mobile app and often partner integrations at once. A weakness there is exposed to all of them, so fixing it at the API level protects the whole product rather than one screen.
How API security testing works, step by step
Every step has a clear output you can review. Timing is agreed in your quote.
- 1
Scope
APIs, environments, roles and test credentials agreed in writing.
- 2
Map
Endpoints, operations and roles catalogued from docs and traffic.
- 3
Test
Authorisation, authentication, data exposure and abuse tested by hand.
- 4
Verify
Each finding confirmed carefully, with safe evidence.
- 5
Report
Findings mapped to the API Top 10, with fixes.
- 6
Retest
Fixes verified and the report updated.
Tools, and what shapes your quote
Pricing is based on your project and agreed in your quote. These are the things that move it.
| Factor | Why it matters |
|---|---|
| Number of endpoints | More operations mean more authorisation and input tests. |
| Number of roles | Each role must be tested against each sensitive operation. |
| REST vs GraphQL | GraphQL needs per-field checks and query-cost testing. |
| Documentation quality | Good schemas and collections make testing faster and more complete. |
| Business flows | Payments, quotas and multi-step flows need careful logic testing. |
| Area | Tools |
|---|---|
| Testing | Burp Suite, Postman, custom scripts |
| GraphQL | schema introspection tools, query tooling |
| Support | OpenAPI tooling, traffic capture |
| Guidance | OWASP API Security Top 10, OWASP ASVS, CVSS |
Common mistakes to avoid
What we see go wrong most often, and how a good project avoids it.
Checking permissions only in the app
If the API does not re-check on every request, the app's restrictions mean nothing.
Returning whole objects
Sending full records and letting the client pick fields exposes everything to anyone reading responses.
No rate limits
Without limits, logins can be guessed and data can be pulled in bulk.
Forgotten old versions
Old API versions left running often lack the fixes added to the current one.
Frequently asked questions
Do you need our API documentation?
It helps a lot. A schema, Postman collection or OpenAPI or GraphQL definition speeds testing and improves coverage. Where it is missing, we map endpoints from your clients' traffic.
Can you test a GraphQL API?
Yes. GraphQL needs per-field authorisation checks and query-cost testing, which we cover alongside the standard API areas.
Will testing affect our production data?
We prefer a staging environment with test data. If we must test production, we use test accounts, agree windows and avoid actions that change real records.
Do you test authentication providers like OAuth?
We test how your API uses tokens and sessions: expiry, scope, validation and handling. The identity provider itself is usually out of scope unless you run it.
How is this different from a web app test?
A web app test works through the interface; an API test works directly against endpoints, which is where mobile apps, integrations and single-page apps actually connect.
Do you include a retest?
Yes. After you fix the findings we retest them and update the report.
Can you help fix the findings?
Yes. Our developers can implement the fixes or review your team's changes before the retest.
Do you sign an NDA?
Yes. Findings are confidential and shared only with the contacts you name, and test data is removed afterwards.
Do you test older API versions too?
Yes, when they are in scope. Old versions left running are a common weak point, because the fixes added to the current version are often never applied to them.
What do you need from us to start?
The base address of each API, credentials for each role, any schema or documentation you have and a named contact in case anything needs attention during testing.
Related services
Penetration Testing
Authorised, scoped security tests with a fix-it report.
Web App Penetration Testing
Manual OWASP testing of logins, access control and logic.
Secure Code Review
Review your codebase for security flaws before release.
Custom API Development
Documented REST, GraphQL and WebSocket APIs.
API Integration
Connect the tools you already use so data flows on its own.
Vulnerability Assessment
Find, rank and plan fixes for known weaknesses.
API Security Testing by industry
See what your API really allows.
Tell us what you need. You get an honest assessment, a clear plan and a written quote. The first consultation is always free.
- What happens next
- 1You tell us what you need
- 2We aim to reply within 24 hours with questions
- 3You get a written quote for your project