API penetration testing: REST, GraphQL and OAuth security

APIs are the nervous system of your digital business. They connect services, expose data and move money. We assess their security following the OWASP API Security Top 10, with an attacker's rigor and the precision of a specialized technical team.

Scope your project · Audit my API

Rather talk it through? Call us at +34 960 730 013

APIs are the new attack perimeter

The number one risk in the OWASP API Security Top 10 isn't authentication but object-level authorization: "Broken Object Level Authorization" (API1:2023). An endpoint that returns any user's data if you change the ID in the URL. An internal API exposed without protection because "it's only for internal use." A token that never expires. These flaws are silent and easy to exploit for someone who knows how to look for them.

How a request slips through a broken object level authorization flaw

Authentication works, the token is valid, and the API still hands over another customer's data. Follow the same request with and without the missing check.

No object-level check

  1. Ana, a legitimate customer, requests order 48213 with Ana's own token. The order belongs to someone else: only the number in the URL has changed.
  2. The gateway validates the token's signature and expiry. Ana is authenticated, so the request moves on.
  3. The service looks the order up by its identifier and never checks whether it belongs to whoever is asking.
  4. The API returns 200 with another customer's name, address and phone number. A loop over the identifier downloads every order on the platform.

With object-level check

  1. The same request: Ana's token and order 48213, which belongs to another customer.
  2. Authentication passes just the same, because the token is valid. That check alone does not protect the data.
  3. Before returning anything, the service compares the order's owner with the token's user. They do not match.
  4. The API returns 403 and logs the attempt. Repeated in a loop, it raises an alert instead of turning into a data leak.

Illustrative example. In an API penetration test we try this cross-check on every endpoint that takes an identifier, with users from different roles and tenants.

What we audit

  • BOLA (Broken Object Level Authorization): access to other users' resources
  • Broken Authentication: weak tokens, no expiration, no revocation
  • Excessive data exposure: responses with more information than necessary
  • Rate limiting and protection against API abuse
  • SSRF, injections and input validation in API parameters
  • OAuth 2.0 and OpenID Connect flows: redirect_uri, PKCE, scope escalation
  • GraphQL: introspection, batching attacks, field-level authorization

How we audit an API

  1. Endpoint mapping: We identify all endpoints, HTTP methods, parameters and authentication formats. We review the documentation if it exists (Swagger, OpenAPI).
  2. Authentication and authorization analysis: We test the authentication mechanisms and verify that authorization works correctly at object and function level.
  3. Fuzzing and injections: We send malicious payloads to detect injections, unexpected behavior and server error exposure.
  4. Business logic testing: We assess transactional flows: can a standard user perform admin actions? Can they access other users' data?
  5. Exploitation and documentation: We confirm each finding with a clear proof of concept and classify it by severity.

The ten risks we test your API against

The industry's reference list for API security, in its current 2023 edition. Tap a risk to see what it is and how we check it; colors group the risks that share a root cause.

  1. API1:2023 Broken Object Level Authorization (Authorization): The API returns or modifies an object just by knowing its identifier, without checking that it belongs to whoever is asking. We swap identifiers between users and tenants on every endpoint that takes an ID: paths, parameters, body and headers.
  2. API2:2023 Broken Authentication (Authentication): Flaws in how credentials are issued and validated: tokens that never expire or whose signature is not verified, unlimited login attempts or weak account recovery. We test issuance, validation and revocation of JWTs and sessions, brute force and the account recovery flow.
  3. API3:2023 Broken Object Property Level Authorization (Authorization): The object is yours, but not all of its properties should be: responses that expose internal fields, or requests that let you write fields such as role or price (mass assignment). We compare the properties each endpoint returns and accepts with those each role should be able to see or change.
  4. API4:2023 Unrestricted Resource Consumption (Abuse and consumption): Without limits on requests, payload size, pagination or cost, an attacker exhausts resources or runs up the bill for third-party services such as SMS, email or AI. We measure rate limits, payload size, pagination and expensive operations, in a controlled way agreed with you.
  5. API5:2023 Broken Function Level Authorization (Authorization): A standard user calls administrative functions because the control relies on not knowing the endpoint or the method. We replay each privileged role's calls with the other roles' credentials, also changing the HTTP method.
  6. API6:2023 Unrestricted Access to Sensitive Business Flows (Abuse and consumption): Legitimate flows —purchases, bookings, sign-ups or comments— automated at scale to hoard stock, spam or abuse promotions. We identify the sensitive business flows and check whether they can be automated without any brake.
  7. API7:2023 Server Side Request Forgery (Server and configuration): The API fetches a URL supplied by the user, and it can be pointed at internal services or at the cloud metadata endpoint. We test every parameter that accepts URLs (webhooks, imports, previews) against internal and metadata destinations.
  8. API8:2023 Security Misconfiguration (Server and configuration): Permissive headers and CORS, errors with stack traces, unnecessary methods, weak TLS or GraphQL introspection left open in production. We review server configuration, CORS, headers, error messages and schema exposure.
  9. API9:2023 Improper Inventory Management (Inventory and third parties): Old versions, test environments or undocumented endpoints that are still published without the controls of the current version. We discover versions and hosts missing from the inventory and compare their controls with the production version's.
  10. API10:2023 Unsafe Consumption of APIs (Inventory and third parties): The API trusts data received from third parties more than its own users' input and processes it without validation. We review how integrations validate third-party API responses, redirects and transport.

The OWASP API Security Top 10, explained risk by risk

Official names in English, as published by OWASP.

Deliverables

  • Technical report with every in-scope endpoint and its findings
  • Reproducible PoC for each vulnerability (requests, responses, payloads)
  • Attack surface map of your API
  • Specific remediation recommendations (not generic)
  • Closing meeting with the backend development team

Common use cases

  • SaaS platform APIs with multi-user access and sensitive data
  • Internal microservices with service-to-service communication
  • E-commerce APIs with payment and order management endpoints
  • Mobile applications whose logic resides in the backend API
  • APIs exposed to partners or third parties via API keys
  • Banking and fintech APIs subject to DORA or PSD2

Frequently asked questions

Do you need access to the API documentation (Swagger/OpenAPI)?

It's useful but not essential. We can work in black-box mode by intercepting the traffic of the application that consumes the API. Documentation speeds up the process and improves coverage.

Do you audit internal APIs or only internet-facing ones?

Both. In fact, internal APIs are frequently the most vulnerable because of the mistaken assumption that "only employees use them." Lateral movement in an attack usually leverages exactly this type of API.

What's the difference between auditing a REST API and a GraphQL one?

GraphQL has specific attack vectors: introspection can reveal the entire data schema, batching enables application-level DoS, and field-level authorization is harder to implement correctly. We cover both with adapted methodologies.

How long does an API audit take?

Between 3 and 7 business days for the technical phase, depending on the number of endpoints and the complexity of the authentication and business flows.

Do you need the API documentation, or can you work without it?

We can work without it, but the result is poorer and costs more. With an OpenAPI specification or a Postman collection the scope is covered from day one; without it, time goes into discovering endpoints, and whatever is not discovered is not tested. If the documentation is out of date, tell us: an endpoint that exists and is undocumented is itself a relevant finding.

Do you cover GraphQL as well as REST?

Yes, and the approach differs considerably. In GraphQL what matters is introspection left exposed in production, depth and query-complexity attacks that exhaust the server, and field-level authorization: protecting the type but not each field is common, so a nested query returns data the user should not see. In REST the emphasis is more on object-level authorization and identifier enumeration.

How do you avoid exhausting rate limits during testing?

It is agreed beforehand: either the source IP is excluded from rate limiting during the testing window, or intensity is tuned to stay below the threshold. It is worth deciding deliberately, because disabling the limit allows everything else to be tested thoroughly but leaves the abuse control itself unevaluated, and on an exposed API that is a finding in its own right. The usual approach is to test both scenarios at different times.

Related resources

Sources

Ready to protect your business?

Answer the scoping form at your own pace and we'll use it to prepare your proposal. If you'd rather talk first, book a free 30-minute call.

Scope your project · Audit my API