apipentest.net

Manual API security testing, explained

Talk to a tester

Manual API penetration testing

API penetration testing: what it covers, what it costs, what you get

A hands-on test of your REST, GraphQL or gRPC API against the OWASP API Security Top 10. Authorization first, scanners second, and a report your engineers can act on the same week.

See the API testing service Estimate your scope
  • REST
  • GraphQL
  • gRPC
  • WebSocket
  • Webhooks
  • OAuth2 / OIDC
  • mTLS

§ 01Coverage

What an API penetration test covers

A test of the interface itself, not of the browser experience sitting in front of it.

An API penetration test is a time-boxed, manual assessment of an application programming interface: every endpoint or operation, every authentication scheme, and every role that can reach them. A tester works with a specification and real accounts, sends requests the client application would never send, and records what the server does about it.

The distinction from a web application test is coverage, not technique. As Secure Ideas puts it: “when we test a web application, we cover the API calls made by the application. However, if the web application only covers a small portion of the API then a lot of that functionality is unexamined.” Mobile clients, partner integrations, admin operations and older API versions are usually in that unexamined remainder.

The work is dominated by authorization. Scanners are good at reflected input and known misconfiguration; only a person who understands your objects, roles and tenants can tell whether order 41,932 should be readable by the account that just asked for it. That is why an API test is scoped in tester-days and not in scanned hosts.

In scope by default

  • Documented endpoints from your OpenAPI document or Postman collection, in every version still reachable
  • Undocumented and deprecated routes found in client bundles, mobile traffic and version enumeration
  • Authenticated and unauthenticated paths, tested from every role and, in multi-tenant systems, from a second tenant
  • Authentication and session mechanics: API keys, OAuth2 and OIDC flows, JWT handling, refresh and revocation, mutual TLS
  • Object, property and function-level authorization across the full role matrix
  • Rate limiting, resource consumption, business-flow abuse, server-side request forgery, injection and mass assignment
  • GraphQL introspection, aliasing and query depth; gRPC reflection; webhook signature verification

Out of scope unless agreed

  • Denial-of-service testing against production, which is scheduled and throttled or moved to staging
  • Source code review of the authentication and authorization middleware, which is a separate discipline
  • Social engineering, physical access and red-team objectives
  • The browser front end, its client-side storage and its content security policy
  • Cloud configuration and network infrastructure beyond the API hosts themselves
  • Third-party APIs you consume, which need their operator’s permission before anyone tests them
How a manual API test compares with the alternatives
Coverage questionManual API testWeb app testDAST scanBug bounty
Undocumented routesFrom spec, traffic and version guessingOnly what the interface callsOnly the seed listIf a hunter looks
Object-level authorization (API1)Every type, role and tenant pairPartiallyRarely: needs contextCommonly reported
Function-level authorization (API5)Every role, every operationInterface functions onlyNoCommonly reported
Injection and misconfigurationYes, after the authorization passYesYes, by designYes
Business-flow abuse (API6)Modeled and exercisedOccasionallyNoOccasionally
Auditor-grade evidenceCoverage matrix and retestSame, for the web appTool outputNo coverage claim
Fixed price and end dateYesYesYesNo, payouts scale

§ 02Failure mode

Why APIs fail differently

The traffic is authenticated, the surface is larger than the inventory, and the bug is usually a missing check rather than a bad string.

Web application testing grew up around what an anonymous browser can do. API attacks look nothing like that. Salt Security reports that nearly all of the attack attempts its labs analyzed came from authenticated sources, and that around two-thirds exploited security misconfiguration, the OWASP API8 category. The attacker is already a customer, a partner or a trial account.

The second problem is inventory. Cloudflare found that organizations had roughly a third more public-facing API endpoints than their own inventories listed, discovered through machine learning on live traffic. You cannot protect a route you do not know you publish, and you cannot claim coverage for one nobody tested.

The practical consequence is a division of labor: automated tools sweep for injection, exposed debug endpoints and stale versions, and people spend their days on the authorization matrix. That is the part of the work that cannot be bought as a subscription.

  1. 99%

    of attack attempts analyzed by Salt Labs originate from authenticated sources.

    Salt Security, April 2026

  2. 87%

    of surveyed organizations reported an API-related security incident during 2025.

    Akamai, March 2026

  3. 33%

    more public-facing API endpoints than the organizations themselves had inventoried.

    Cloudflare, July 2024

  4. 59%

    of the API vulnerabilities Wallarm tracked require no authentication at all.

    Wallarm, February 2026

Salt Security and Wallarm publish telemetry from their own customer base and vulnerability tracking, and both sell API security products. Cloudflare reports network-wide traffic. Read all three as directional, not as a census.

§ 03Method

Six phases, in the order that finds things

Planning, discovery, attack and reporting, as NIST SP 800-115 frames a penetration test, applied to an interface rather than a network.

NIST SP 800-115 defines penetration testing as “security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network”, and splits it into planning, discovery, attack and reporting. The guide notes that this is one acceptable grouping among several. The six phases below are that structure with the discovery and attack stages broken out the way an API engagement actually runs.

Order matters. Enumerating the surface before touching authentication wastes the authorization budget on endpoints that turn out to be unreachable, and running the abuse tests before the authorization matrix means every rate-limit finding has to be re-tested once the roles are understood. OffSeq runs the same shape as a six-stage engagement: intake, scope, test, evidence, readout and retest.

  1. 01

    Scoping and access

    Agree the endpoint list, the roles, the environment and the rules of engagement. Decide what is off limits, who gets called if something breaks, and what evidence you need at the end.

    Needs
    OpenAPI or Postman collection, role list, target environment, written authorization
    Produces
    Signed scope, test window, named contact and a kill switch

  2. 02

    Discovery and inventory

    Parse the specification, capture traffic from the web and mobile clients, enumerate versions and hosts, and diff the result against what you thought you published. This is where API9, improper inventory management, is decided.

    Needs
    Specification, client and mobile traffic captures, DNS and host enumeration
    Produces
    Endpoint inventory marking documented, undocumented and deprecated routes

  3. 03

    Authentication and token analysis

    Work through every scheme the API accepts: API keys, OAuth2 and OIDC flows, JWT signature and claim handling, refresh and revocation, mutual TLS. Check what happens when a token is expired, swapped, downgraded or simply absent.

    Needs
    Working credentials for each scheme, client IDs and secrets, client certificates
    Produces
    Token-handling findings and a map of which scheme protects which routes

  4. 04

    Authorization matrix

    The core of the engagement. Every role is pointed at every object, every property and every operation, and each crossing is recorded as allowed or denied. This is the pass that finds API1, API3 and API5, and the reason the work is measured in days.

    Needs
    Two accounts per role, two tenants where the API is multi-tenant
    Produces
    A role by object by operation matrix with every crossing marked

  5. 05

    Abuse, logic and injection

    Rate limits and resource consumption, business flows exercised at machine speed, server-side request forgery, mass assignment, injection through resolvers and parameters, GraphQL depth and aliasing, webhook signature verification.

    Needs
    A rate-limit exemption window, or a staging copy with production-like data volumes
    Produces
    Exploited chains with the request and response that prove them

  6. 06

    Reporting, readout and retest

    Write the findings against the evidence, walk the engineering team through the chains, then re-test the fixes and issue a statement that says what was verified and what was not.

    Needs
    A remediation window and an agreed retest date
    Produces
    Report, engineering readout and a retest statement

§ 04OWASP API Top 10

The OWASP API Security Top 10 (2023), item by item

Ten categories, the official one-line definition, the probe that tests it and a public incident that shows what it looks like when it goes wrong.

The OWASP API Security Top 10 has its own list because APIs fail in ways the web application list never described well. The 2023 edition reached stable release on 5 June 2023 and is published under Creative Commons Attribution-ShareAlike 4.0.

Three changes from the 2019 edition matter when you read an older report. Excessive data exposure and mass assignment were merged, because OWASP found the root cause was the same: “object property level authorization validation failures”. A category was added for unrestricted access to sensitive business flows, covering “most of those that can be mitigated using rate limiting”. And unsafe consumption of APIs was added because “attackers have started looking for a target’s integrated services to compromise those, instead of hitting the APIs of their target directly”.

  1. API1:2023

    Broken Object Level Authorization

    “APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues.”

    We test Every object identifier is requested from an account that should not own it, in both directions and across tenants. Sequential, guessable and leaked identifiers are enumerated.

    GET/v1/orders/{id}

    Seen in Optus 2022, T-Mobile 2023, McHire 2025

  2. API2:2023

    Broken Authentication

    “Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws.”

    We test Token signature and claim validation, algorithm confusion, expiry and revocation, credential stuffing resistance, and every route reached with no token at all.

    POST/oauth/token

    Seen in Peloton 2021, Trello 2024, Authy 2024

  3. API3:2023

    Broken Object Property Level Authorization

    “The lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties.”

    We test Responses are diffed against what the role should see, and writes are attempted on properties the interface never sends, including role, tenant and price fields.

    PATCH/v1/users/{id}

    Seen in Peloton 2021

  4. API4:2023

    Unrestricted Resource Consumption

    “Successful attacks can lead to Denial of Service or an increase of operational costs.”

    We test Pagination and filter limits, concurrency, upload sizes, expensive queries, and metered downstream calls that cost you money per request.

    GET/v1/search?limit=100000

    Seen in Dell 2024, Authy 2024

  5. API5:2023

    Broken Function Level Authorization

    “Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws.”

    We test Administrative and internal operations are called from ordinary accounts, and HTTP methods are swapped on routes that only guard one verb.

    DELETE/v1/admin/users/{id}

    Seen in Common in multi-role B2B APIs

  6. API6:2023

    Unrestricted Access to Sensitive Business Flows

    “APIs expose a business flow without compensating for how the functionality could harm the business if used excessively in an automated manner.”

    We test Your own valuable flows, run at machine speed: checkout, referral credit, invitation, bulk lookup, price scraping and stock reservation.

    POST/v1/checkout

    Seen in Dell 2024, Trello 2024

  7. API7:2023

    Server Side Request Forgery

    “SSRF flaws can occur when an API is fetching a remote resource without validating the user-supplied URI.”

    We test Every parameter that makes the server fetch something: webhooks, import-by-URL, avatar fetchers, PDF renderers and link previewers, against internal and cloud metadata targets.

    POST/v1/imports?url=

    Seen in A recurring finding in integration-heavy APIs

  8. API8:2023

    Security Misconfiguration

    “Software and DevOps engineers can miss these configurations, or don’t follow security best practices when it comes to configuration.”

    We test Authentication flags on individual routes, verbose errors, permissive cross-origin policies, debug and actuator endpoints, TLS settings and default credentials.

    OPTIONS/v1/

    Seen in McHire 2025, ServiceNow 2026

  9. API9:2023

    Improper Inventory Management

    “A proper inventory of hosts and deployed API versions also are important to mitigate issues such as deprecated API versions and exposed debug endpoints.”

    We test Old versions, staging hosts, forgotten regional deployments and internal documentation portals that are still answering on the public internet.

    GET/v0/users

    Seen in Optus 2022

  10. API10:2023

    Unsafe Consumption of APIs

    “Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards.”

    We test What your API does with data and tokens from the services it integrates, and what a compromised third-party integration could reach on your side.

    GET/v1/partners/sync

    Seen in Salesloft Drift 2025

Item names and the quoted definitions come from the OWASP API Security Top 10 – 2023, © OWASP Foundation, used under Creative Commons Attribution-ShareAlike 4.0. Example paths are illustrative; the commentary is ours.

§ 05Deliverables

What lands in your inbox

Seven sections, three audiences. A report that only an engineer can read has failed the auditor, and a report only an auditor can read never gets fixed.

A finding is only useful if someone can reproduce it, price it and close it. That means the exact request and response, the account it was sent from, the impact in your terms rather than in generic severity language, and a fix that names the layer it belongs in.

NIST SP 800-115 puts reporting alongside the other phases rather than after them, because notes written during the attack phase are the only ones that survive contact with a remediation argument three weeks later. If you want to see the shape of a finished document first, OffSeq publishes a full sample report.

  1. Section 1

    Executive summary

    What was tested, what an attacker could have done, and the two or three decisions that follow. One page, no tool names.

    Board, CISO

  2. Section 2

    Scope and coverage matrix

    Endpoints by role, with each crossing marked tested, not reachable or excluded. This is the section that turns a report into audit evidence.

    Auditor

  3. Section 3

    Findings with evidence

    Each finding with a severity score, the request and response that prove it, the affected routes and a fix written for the layer that owns the bug.

    Engineers

  4. Section 4

    Attack chains

    How the individual findings combine. A low-severity identifier leak plus a missing object check is not two low findings.

    CISO, engineers

  5. Section 5

    Standards mapping

    Every finding mapped to its OWASP API Security Top 10 category and to the relevant OWASP ASVS 5.0 requirement, so the same test answers several questionnaires.

    Auditor

  6. Section 6

    Remediation roadmap

    Findings grouped by root cause and ordered by what removes the most risk per engineering day, not by raw severity.

    Product owners

  7. Section 7

    Retest statement

    What was re-tested, what is verifiably fixed, what is partially fixed and what remains open, with the date each was checked.

    Auditor, customers

§ 06Price

What actually moves the number

Tests are sold in tester-days. Everything below changes how many days the authorization matrix takes, and nothing else changes it much.

European testing firms publish day rates. Securitum lists time-and-materials work at €640 to €890 per person-day. SECFORCE calls £1,000 to £1,500, roughly €1,200 to €1,800, a fair day rate and warns that anything under £500 per day is a scan rather than a test. Multiply a day rate by an effort band and you have a range you can sanity-check a quotation against.

The width of that range is the honest part. Two vendors can quote the same scope at €4,500 and €18,000 because they are selling different numbers of days at different rates, not because one of them mispriced you. Ask both how many tester-days the authorization matrix gets, and the comparison becomes possible.

  1. 01

    Endpoints or operations

    The count that matters is operations, not paths. One resource with five verbs is five tests, and a GraphQL schema with 200 fields is not one endpoint.

  2. 02

    Roles and tenants

    The authorization matrix grows with roles multiplied by object types. Adding a fourth role costs more days than adding fifty read-only endpoints.

  3. 03

    Authentication schemes

    One API key is an afternoon. OAuth2 with three grant types, refresh rotation and mutual TLS for partners is a phase of its own.

  4. 04

    API styles in scope

    REST, GraphQL, gRPC, WebSocket and webhooks each need different tooling and different abuse tests. A mixed estate costs more than the sum of its endpoints suggests.

  5. 05

    Environments

    Staging with production-like data is the cheapest place to test consumption limits. Production adds scheduling, throttling and a rollback conversation.

  6. 06

    Specification quality

    A current OpenAPI document can save two days of discovery. No specification at all adds them back, and adds uncertainty about what was missed.

  7. 07

    Retest and re-issue

    A retest of the fixed findings and a re-issued statement is typically one to two days. Certification bodies and enterprise customers usually want it.

Published European price and effort benchmarks, collected September 2026
BenchmarkPublished figureSource
Time-and-materials day rate€640 to €890 per person-daySecuritum price list (PL/EU)
Fixed-price single application test€3,500 to €14,000, one to four weeksSecuritum price list (PL/EU)
Fair day rate£1,000 to £1,500, about €1,200 to €1,800SECFORCE pen-testing price guide (UK/EU)
Mobile and API ecosystems€3,000 to €7,500Sectricity, January 2026 (BE)
API penetration test$5,000 to $30,000, drivers: endpoint and auth-flow countBlaze Information Security, June 2026
Under 25 endpoints, one or two roles4 to 5 working daysEJN Labs (UK, CREST)
25 to 100 endpoints, three or more roles7 to 10 working daysEJN Labs (UK, CREST)
Over 100 endpoints, multiple protocols12 to 15 working daysEJN Labs (UK, CREST)
These are other companies’ published figures, quoted so you can benchmark a quotation. They are not an OffSeq price list, and none of them is a quote for your API.

§ 07Estimator

Estimate the scope of your own test

Eight questions, an honest effort band and a euro range built from published day rates. Nothing is sent anywhere; the arithmetic runs in your browser.

Interactive mode is not available. You can read the full reference content below. No answers are assessed and no result is calculated.

  • Effort bands published by CREST-registered testers. Under 25 endpoints with one or two roles: 4 to 5 working days. 25 to 100 endpoints with three or more roles: 7 to 10 days. Over 100 endpoints across several protocols: 12 to 15 days.
  • Day rates published in Europe. €640 to €890 per person-day at Securitum; £1,000 to £1,500, about €1,200 to €1,800, described as a fair day rate by SECFORCE. Multiply the band by the rate for a sanity-check range.
  • What adds days. Each additional role or tenant, each extra authentication scheme, GraphQL or gRPC alongside REST, production testing instead of staging, and a missing or stale OpenAPI document.
  • What to have ready. A current specification, two accounts per role, two tenants where the API is multi-tenant, credentials for every authentication scheme, and logging left switched on.
  • What the depth means. Grey box, with the specification and real accounts, is the default. Black box wastes days rediscovering what you could have handed over. White box adds a review of the authorization middleware.
Draft this scope with OffSeq

Endpoints or operations in scope

API styles in scope

Roles and tenancy

Authentication schemes

Environment

Specification quality

Compliance driver

Retest after fixes

Indicative scope200 OK

8–10tester-days of hands-on testing

At published EU day rates, roughly €5,000–€18,000

The euro band multiplies the day band by €640 to €1,800, the span between Securitum’s published rate and the upper end of SECFORCE’s fair day rate. The width is real: the rate you pay moves the total more than the scope does.

Recommended depth

Grey box

Specification plus one account per role

The default and the best value. You hand over the specification and real credentials for each role; the tester spends the budget on authorization rather than on rediscovering your endpoints.

Grey box + discovery

Two days to rebuild the inventory first

With no current specification, the first two days go on building one from client traffic, bundles and version enumeration. Budget for it explicitly, and keep the inventory afterwards.

Grey box + assurance

Independence and evidence, not more testing

A regulated driver adds requirements around the paperwork rather than the testing: an independent tester, a documented methodology, a coverage matrix and a dated retest statement.

What the plan will be dominated by

  • API1:2023 BOLA
  • API2:2023 Broken authentication
  • API4:2023 Resource consumption
  • API5:2023 BFLA
  • API8:2023 Misconfiguration

What to have ready

  • A current OpenAPI document or schema for every version still served.
  • Two accounts per role, plus a second tenant where the API is multi-tenant.
  • Logging and alerting left on, so you can compare what we did with what you saw.
  • A traffic capture from the web and mobile clients, so undocumented routes surface early.
  • Working credentials for every authentication scheme, including client certificates.
  • A named production contact, a rate-limit exemption window and an agreed kill switch.
  • A remediation window and a retest date agreed before the engagement starts.
Draft this scope with OffSeq

A planning aid, not a quotation. It knows nothing about your data sensitivity, your deployment cadence or your engineers’ availability, and no serious tester will price an engagement without a scoping call.

§ 08Compliance

Which rules actually expect this

None of the three instruments below uses the word “API”. All three reach your API anyway, and each one wants different evidence.

Regulators write about systems and applications, not about protocols. That is deliberate: naming a technology dates a law. What it means in practice is that you have to argue the mapping yourself, and the argument is short. If an API supports a critical function, stores cardholder data or belongs to an essential entity’s network and information systems, the testing obligations apply to it.

What differs is the cadence and the paperwork. DORA sets a frequency, NIS2 makes you derive one from your own risk assessment, and PCI DSS sets both a frequency and a methodology requirement. All three want the test documented rather than merely performed.

DORAArt. 24 to 26

Everything supporting a critical or important function, tested yearly

the execution of appropriate tests, such as vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testingRegulation (EU) 2022/2554, Article 25(1)

Cadence At least yearly on all ICT systems and applications supporting critical or important functions (Art. 24(6)), by independent parties, internal or external (Art. 24(4)). Threat-led penetration testing at least every three years for entities identified for it (Art. 26(1)). The regulation has applied since 17 January 2025.

Evidence A dated report from an independent tester, the scope it covered, and the record of what was remediated.

Regulation (EU) 2022/2554

NIS2Art. 21(2)

Assess the effectiveness of your own measures

(e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure; (f) policies and procedures to assess the effectiveness of cybersecurity risk-management measuresDirective (EU) 2022/2555, Article 21(2)

Cadence Derived from your risk assessment. Commission Implementing Regulation (EU) 2024/2690, Annex point 6.5, requires relevant entities to establish “the need, scope, frequency and type of security tests” from that assessment and to run them “according to a documented test methodology”. Its recital 15 names penetration tests explicitly.

Evidence The documented methodology, the recorded type, scope, time and results of each test including criticality, and the mitigating actions taken for critical findings.

Directive (EU) 2022/2555

PCI DSS v4.0.1Req. 6.2.4 · 11.4

Application-layer testing has to reach the API

Requirement 6.2.4 lists the attack classes custom software must be engineered against, including attacks on access control mechanisms and on business logic. Requirement 6.4.2 has required an automated technical solution in front of public-facing web applications since 31 March 2025. Requirement 11.4.1 asks for a documented methodology whose application-layer testing covers, at minimum, the vulnerabilities in 6.2.4.

Cadence Internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change (11.4.2 and 11.4.3), by a qualified resource with organizational independence.

Evidence The test report against the documented methodology, plus results and remediation activities retained for 12 months.

PCI SSC document library

The PCI DSS requirement text sits behind the council’s licence acceptance, so the PCI entry above is a summary rather than a quotation; the numbering and the 31 March 2025 date come from the standard itself. PCI DSS says “web applications”, not “APIs”: an API is in scope where it stores, processes or transmits cardholder data or can affect the security of the cardholder data environment. ISO/IEC 27001 and SOC 2 do not mandate penetration testing at all, but auditors routinely accept a current report as evidence for technical vulnerability management. OffSeq also publishes dedicated pages on DORA compliance and on NIS2 and DORA together.

§ 09Incidents

Nine API incidents and the category each belongs to

Every entry is drawn from a published disclosure, a regulator statement or a filed report. The pattern is monotonous, which is the point.

None of these required a novel exploit. An identifier was guessable, an endpoint was reachable without a token, a rate limit was absent, or a flag on one route said authentication was optional. The category tags map each case to the OWASP API Security Top 10 items it demonstrates.

  1. 2021

    Peloton

    Unauthenticated endpoints, including api.onepeloton.com/api/user/search/, returned user IDs, instructor IDs, group membership, location, workout statistics, gender and age, even for profiles set to private. Disclosed 20 January, partially fixed 2 February and largely fixed within seven days once the press became involved.

    • API1
    • API2
    • API3
    Pen Test Partners

  2. 2022

    Optus

    Australia’s ACMA found that a 2018 coding error broke an access control on an API. The fix reached one domain in 2021, but the internet-facing target domain “was not decommissioned despite a lack of any need for it”. 9.5 million people were affected, through what the regulator described as a simple process of trial and error.

    • API1
    • API9
    The Register

  3. 2023

    T-Mobile US

    An SEC filing recorded that a bad actor “obtained data from this API for approximately 37 million current postpaid and prepaid customer accounts”: names, billing addresses, email addresses, phone numbers, dates of birth, account numbers and plan features. Access began on 25 November 2022 and was detected on 5 January 2023.

    • API1
    • API2
    • API4
    BleepingComputer

  4. 2024

    Trello

    An open endpoint let any unauthenticated caller map an email address to a Trello account. Feeding it 500 million addresses produced 15,115,516 matching records. Atlassian changed the behaviour so unauthenticated callers can no longer request another user’s public information by email.

    • API2
    • API4
    • API6
    BleepingComputer

  5. 2024

    Dell

    Fake partner accounts were approved in 24 to 48 hours, then used against a partner-portal API at 5,000 requests per minute for roughly three weeks. 49 million records were retrieved, including names, service tags, installed locations and order numbers. The portal reportedly had no rate limiting.

    • API2
    • API4
    • API6
    BleepingComputer

  6. 2024

    Twilio Authy

    Twilio confirmed that “threat actors were able to identify data associated with Authy accounts, including phone numbers, due to an unauthenticated endpoint”. The resulting dataset contained 33,420,546 rows of multi-factor authentication phone numbers.

    • API2
    • API4
    BleepingComputer

  7. 2025

    McDonald’s McHire

    Default credentials on the Paradox.ai administrative login, combined with an object-level authorization flaw on PUT /api/lead/cem-xhr, allowed the personal data of more than 64 million applicants to be retrieved by decrementing an identifier. Disclosed at 17:46 ET on 30 June; the credentials were disabled by 19:31 ET the same evening.

    • API1
    • API2
    • API8
    Ian Carroll

  8. 2025

    Salesloft Drift

    Google’s threat intelligence team reported that between 8 and 18 August, the actor tracked as UNC6395 used compromised OAuth tokens from the Salesloft Drift third-party application to export data from Salesforce customer instances, hunting specifically for AWS access keys, passwords and Snowflake tokens. The tokens were revoked on 20 August.

    • API2
    • API10
    Google Cloud Threat Intelligence

  9. 2026

    ServiceNow

    A scripted REST endpoint, /api/now/related_list_edit/create, shipped with requires_authentication set to false. Exploitation was observed on 2 and 3 June; a hotfix followed on 5 June. ServiceNow stated that “a subset of customer instances were queried successfully as part of this activity”.

    • API2
    • API8
    CSO Online

§ 10Guides

Four guides that go further

Long-form, sourced and written for the person who has to sign the purchase order.

  1. OWASP API Security Top 10 (2023) The ten categories in the official words, what each one looks like in a REST or GraphQL API, the probe that finds it, and a public incident for every category that has one. Read
  2. API penetration testing cost Published European day rates and effort bands, the seven drivers that decide how many days you buy, two worked scopes, and the questions that make three quotations comparable. Read
  3. The API pentest report Four readers, seven sections and one worked finding. How to tell a report that will get fixed from a scanner dump with a cover page, before you commission either. Read
  4. DORA, NIS2 and PCI DSS None of the three names APIs. All three reach them. The clauses, the cadence each sets, the evidence each auditor accepts, and how to write the obligation into your own policy. Read

§ 11Questions

Frequently asked questions

Short answers. Each one is expanded in a guide or a section above.

How much does an API penetration test cost?
European testing firms publish day rates between roughly €640 and €1,800: Securitum lists €640 to €890 per person-day, SECFORCE calls £1,000 to £1,500 a fair rate. Effort bands published by CREST-registered testers run from 4 to 5 days for a small API with one or two roles, to 7 to 10 days for 25 to 100 endpoints with three or more roles, to 12 to 15 days for a large multi-protocol estate. Multiplying the two gives a realistic €3,000 to €25,000 range, which the cost guide breaks down driver by driver.

How long does an API penetration test take?
The testing itself is normally 5 to 15 working days. The whole engagement is longer: scoping and access provisioning before, reporting and readout after, and a retest once your team has shipped fixes. Four to eight weeks end to end is typical, and KirkpatrickPrice tells clients to expect two to three months for large scopes including remediation and retest.

Do I need an API test if my web application was already tested?
Usually yes. A web application test exercises the API calls the interface makes, which is a subset of what the API accepts. Mobile clients, partner integrations, administrative operations and older versions typically sit outside that subset. The report guide explains how to read a coverage matrix to see exactly which routes a previous test reached.

Black box, grey box or white box?
Grey box is the default for APIs: you hand over the specification and one account per role, and the tester spends the budget on authorization instead of on discovery. Black box is appropriate only when you specifically want to measure what an outsider can find, and it costs days to reach the same place. White box adds a review of the authentication and authorization middleware and pairs well with a secure code review.

Will testing hit production?
Authorization, authentication and injection testing can usually run against staging if the data volumes and configuration are close to production. Resource-consumption and business-flow tests are the ones that need care: they are scheduled, throttled and run inside an agreed window with a named contact and a kill switch, or moved to a staging copy with production-like data.

What is BOLA and why is it number one?
Broken Object Level Authorization is the case where an endpoint accepts an object identifier and returns the object without checking that the caller is entitled to it. OWASP describes it as APIs tending “to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues”. It is number one because it is invisible to scanners, trivial to exploit and present in most APIs that were not tested for it: Optus, T-Mobile and McHire are all versions of the same bug.

Does DORA require API penetration testing?
DORA does not use the word “API”. Article 24(6) requires appropriate tests at least yearly on all ICT systems and applications supporting critical or important functions, Article 24(4) requires independent testers, and Article 25(1) lists penetration testing among the tests a resilience programme must be able to execute. An API supporting a critical or important function is therefore in scope by definition rather than by name. Identified entities also face threat-led penetration testing at least every three years under Article 26.

Does NIS2 require penetration testing?
Article 21(2)(f) of Directive (EU) 2022/2555 requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures, and 21(2)(e) covers security in acquisition, development and maintenance. For the sectors covered by Commission Implementing Regulation (EU) 2024/2690, Annex point 6.5 is explicit: establish the need, scope, frequency and type of security tests from the risk assessment, run them to a documented methodology, and record type, scope, time and results. Recital 15 names penetration tests as one acceptable form.

What does PCI DSS say about APIs?
It says “web applications”, and it reaches APIs through scope rather than through wording. Requirement 6.2.4 lists the attack classes software must be engineered against, including access control and business logic. Requirement 6.4.2 has required an automated technical solution in front of public-facing web applications since 31 March 2025. Requirement 11.4.1 requires a documented penetration-testing methodology whose application-layer testing covers at minimum the 6.2.4 vulnerabilities, and 11.4.2 and 11.4.3 set the annual and post-change cadence. An API in or affecting the cardholder data environment is in scope for all of it.

What do I actually get at the end?
A report with an executive summary, a scope and coverage matrix, findings with severity scores and request and response evidence, the attack chains those findings combine into, a mapping to the OWASP API Security Top 10 and OWASP ASVS, a remediation roadmap and a retest statement. Plus a live readout for the engineers who have to fix it. OffSeq publishes a full sample report if you want to see the format before committing.

Sources

  1. OWASP API Security Top 10 – 2023 OWASP Foundation · 2023 Stable release 5 June 2023. Category names and definitions, CC BY-SA 4.0.
  2. Release notes: what changed from 2019 to 2023 OWASP Foundation · 2023
  3. Technical Guide to Information Security Testing and Assessment (SP 800-115) NIST · 2008 Definition of penetration testing and the four-phase structure.
  4. OWASP Application Security Verification Standard 5.0, V4 API and Web Service OWASP Foundation · 2025 Released 30 May 2025. V4 covers generic web service security, HTTP message structure, GraphQL and WebSocket.
  5. Web Security Testing Guide: API testing OWASP Foundation
  6. Regulation (EU) 2022/2554 (DORA) EUR-Lex · 2022 Articles 24, 25 and 26 on digital operational resilience testing.
  7. Directive (EU) 2022/2555 (NIS2) EUR-Lex · 2022 Article 21(2) risk-management measures.
  8. Commission Implementing Regulation (EU) 2024/2690 EUR-Lex · 2024 Annex point 6.5, security testing.
  9. OpenAPI Specification OpenAPI Initiative · 2026 Version 3.2.1, published 10 September 2026. Security scheme types: apiKey, http, mutualTLS, oauth2, openIdConnect.
  10. Salt Security 1H 2026 State of AI and API Security Salt Security · 2026 Vendor telemetry, 327 respondents.
  11. Apps, APIs and DDoS State of the Internet report Akamai · 2026
  12. Application Security report, 2024 update Cloudflare · 2024
  13. 2026 API ThreatStats report Wallarm · 2026 Vendor telemetry.
  14. Penetration testing price list Securitum
  15. Pen testing price list: UK and EU guide SECFORCE · 2026
  16. API penetration testing effort bands EJN Labs
  17. What is the difference between API and web application pentests? Secure Ideas
  18. API penetration testing service page and FAQ KirkpatrickPrice Source for the two-to-three-month end-to-end engagement expectation.