Skip to content
SecuriFii

Technical testing

API Security Testing

An API has no screens to hide behind. Every object, field and function it exposes can be called directly, in any order, by anyone holding a token, and the controls that decide who may see what are the ones most often missing. Testing an API means testing those decisions, one role and one object at a time.

Discuss this
Standard
OWASP API Security Top 10:2023
Edition
2023
API1:2023
Broken Object Level Authorization
WSTG category
4.12 API Testing
Retest
Included

Why APIs are tested on their own terms

Web application flaws and API flaws overlap, but the weight falls in a different place. In an API the serious findings concentrate in authorisation: an endpoint that checks you are logged in but not that the record belongs to you, a field the interface never displays but the response still carries, an administrative function a standard user can call. Broken Object Level Authorization leads the OWASP API Security Top 10 for that reason.

The 2023 edition is current. Like the web Top 10, it is a list of risks for prioritising, not a test plan, so we use it to decide where the time goes and work to the OWASP Web Security Testing Guide for the test cases themselves. Version 4.2 of that guide has a dedicated API Testing category, currently covering GraphQL; for REST APIs the authentication, authorisation, session management and input validation categories apply directly to the API rather than to a page.

REST and GraphQL fail differently. A REST API exposes many endpoints, each needing its own authorisation check. A GraphQL API usually exposes one endpoint and lets the client shape the query, which brings its own problems: introspection left enabled in production, nested queries that reach objects the caller should not see, and queries expensive enough to exhaust the server.

The reason this needs a person is that each of these flaws requires knowing what should be allowed. A tool can tell that a request succeeded. Only a tester who understands your permission model can tell that it should have failed.

What it will ask of you

An API test is only as complete as the inventory it starts from and the accounts it is given. These four decide how much of the budget goes on findings rather than on rediscovering your API.

  • A specification or a collection

    An OpenAPI definition, a GraphQL schema or a Postman collection, plus any versions still live. Improper inventory management is itself on the Top 10: the old version nobody retired is often where the finding is.

  • Accounts for every role, twice

    Two users at each privilege level, and two tenants if the API is multi-tenant. Most serious API findings appear the moment one user’s identifier is tried with another user’s token, which cannot be tested with a single account.

  • A safe environment for state-changing calls

    A staging environment with realistic data, or agreed limits for production. Testing writes, deletes and payment flows against live data needs rules agreed in advance rather than discovered during the test.

  • A view of what the API calls

    The third-party services your API consumes, and sandbox credentials where they exist. We do not want to load a payment provider or an SMS gateway with test traffic billed to you.

What it is used for

  • Evidence for ISO/IEC 27001 and SOC 2 where the API is the product, or the main way customers reach their data.
  • Customer due diligence from enterprise buyers integrating with your API, who increasingly ask for an API-specific test.
  • Assurance before opening an API to partners or the public, or before a major version release.
  • Testing the backend a mobile app talks to, which is where most mobile findings with real impact sit.

Not sure this is the standard you need?

Tell us what triggered the question — a customer, an auditor, a contract clause — and we will say which of these applies, including when the answer is none of them.

Ask a practitioner

Where we come in, and where we stop

This is technical testing, so we are the assessor: we test, report and retest ourselves, with no third party in between. What we will not do is test an authorisation model we designed for you and present the result as independent assurance of our own work.

Ours

  • Scope, rules of engagement and the authorisation
  • Mapping the API from its specification and from traffic
  • Testing authorisation, authentication, input handling and resource limits by role
  • The report, remediation guidance and the retest

Yours

  • Authorising the test, including for any third-party services in the call path
  • Providing accounts, the specification and a suitable environment
  • Owning remediation in the code, with our support

How an engagement runs

Testing proceeds only under written authorisation naming the in-scope APIs, environments, accounts and rules of engagement. State-changing tests against production run only within limits agreed in advance.

  1. 01Scope and authorisationWe agree the APIs and versions in scope, the environments, the roles and accounts, the third-party services in the call path, and anything explicitly out of bounds.
  2. 02MappingBuild the inventory from your specification and from observed traffic, then compare the two. Endpoints, fields and versions that appear in one but not the other are the first thing we look at.
  3. 03Authorisation testingEvery object, property and function tested across roles and tenants: one user’s identifiers with another user’s token, a standard user against administrative functions, writes to fields the interface never offers.
  4. 04Authentication, input and resource testingToken handling and session lifetime, injection through every parameter, server-side request forgery, rate limits and sensitive business flows — and, for GraphQL, introspection, query depth and batching.
  5. 05ReportingAn executive summary a non-technical reader can act on, and findings with CVSS severity, the exact requests and responses as evidence, reproduction steps and remediation specific to your framework.
  6. 06Remediation support and retestWe work through the findings with your developers, retest the fixes and issue a retest letter you can hand to a customer or an auditor.

What you get from us

  • Executive summary written for a non-technical reader
  • Findings mapped to the OWASP API Security Top 10 2023, with CVSS severity
  • The exact requests and responses that demonstrate each finding
  • An authorisation matrix showing what each role could reach, against what it should
  • Remediation guidance specific to your framework and gateway
  • Retest of remediated findings and a retest letter for third parties

Common questions

What is in the OWASP API Security Top 10?

The 2023 edition lists Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server Side Request Forgery, Security Misconfiguration, Improper Inventory Management and Unsafe Consumption of APIs.

Is this different from a web application test?

They overlap, and if your web application is a front end on the same API, testing both together usually makes sense. An API test goes further on authorisation, because without an interface every object and field can be requested directly, and it covers clients the web test never sees, such as mobile apps and partner integrations.

Do you test GraphQL?

Yes. GraphQL has its own failure modes — introspection left on, nested queries that cross authorisation boundaries, queries costly enough to exhaust the server — and the OWASP Testing Guide covers it as a specific test case.

Why do you need two accounts per role?

Because the most common serious API flaw is one user reaching another user’s data, and the only way to prove it is to request one account’s objects with the other account’s credentials. With a single account per role, that whole class of finding goes untested.

Can we just run an API scanner?

For breadth and for regressions between tests, yes. A scanner will find missing headers, known vulnerable components and some injection. It cannot tell that a valid-looking response contains another customer’s data, which is the finding that matters most.

Ready to scope it?

Send the date you are working to and roughly how large the organisation is. You will get a reply from a practitioner with an honest read on whether the date is reachable.

Start the conversation

Related services

  • Vulnerability Assessment and Penetration Testing (VAPT)

    Find what an attacker would find, ranked by what it would actually cost you — and get a report your auditor and your engineers can both use.

  • Mobile Application Security Testing

    Your app tested on a device an attacker controls, against the OWASP mobile standard — and the API behind it tested as well, because that is where the data is.

  • Secure Code Review

    A reviewer reading your code for the flaws a scanner cannot see — with the scanner’s output triaged rather than forwarded.

  • Cloud Security Assessment

    Review the part of the cloud that is yours to secure — identities, network exposure, storage, logging and keys — against a published baseline and against how an attacker would actually move through it.

All services

Related insights

All insights