API SECURITY
API Penetration Testing Services
Manual testing of REST, GraphQL and webhook endpoints against the OWASP API Security Top 10, with authorisation checked role by role and object by object.
What an API test covers
- Object level authorisation (BOLA) per role
- Authentication and token handling
- Rate limiting and resource consumption
- REST, GraphQL and webhook endpoints
- Request and response evidence per finding
Fixed scope, fixed tester-days, fixed price, agreed before testing starts.
$2,500 to $5,500 for a standard web application or API test. Priced in tester-days, no hidden fees. How the test works · See a sample report
API penetration testing is a manual security assessment of the endpoints your applications talk to, run by testers who send crafted requests the way a real attacker would, then verify what the API actually returns. It targets the layer underneath the interface: authentication, authorization, input handling, rate control and business logic exposed over REST, GraphQL or webhooks.
The difference from a web application penetration test matters more than most teams expect. A web app has a user interface that hides fields, disables buttons and enforces the order of steps. An API has none of that. Every endpoint has to enforce its own rules, per role and per object, and a single missing authorization check can expose the records of every customer in the database rather than one page of one account.
Key takeaways
- API penetration testing checks authorization per endpoint and per object, because there is no interface layer to enforce it for you.
- Broken object level authorization stays the most damaging class of API flaw: one unchecked identifier can expose every customer record.
- REST, GraphQL and webhooks each fail differently, so the test plan changes with the technology.
- A standard web application or API pentest at Pentestica runs $2,500 to $5,500, typically 1 to 3 weeks of testing plus a few days for the report.
- PCI DSS v4.0, DORA, NIS2 and GDPR all push regulated organizations toward regular, evidence-backed testing of the interfaces that carry sensitive data.
Authorisation first
Most API breaches are broken access control. We test every object and every function against every role.
OWASP API Top 10
All ten categories tested by hand, not matched against a signature list.
REST and GraphQL
Introspection, batching, query depth and per-resolver limits get their own checks.
Evidence per finding
Each issue ships with the request and response that prove it, plus the fix.
Why APIs are tested differently from web applications
APIs are tested differently because nothing between the attacker and the backend enforces intent. The interface that normally guides a user through steps 1, 2 and 3 is absent, so a tester can call step 3 first, call it as the wrong user, call it with fields the form never displayed, or call it ten thousand times in a minute. That freedom is exactly what an attacker has, and it is why API security testing built only on automated scanning tends to look clean while the real problems sit untouched.
Four properties shape how we plan the work:
- No enforced sequence. Multi-step flows such as checkout, KYC or password reset can be entered out of order, which is where state and logic flaws surface.
- Machine speed. Requests arrive as fast as a script can send them, so missing rate limits turn into credential stuffing, inventory hoarding, SMS cost abuse and race conditions.
- Versioning and forgotten endpoints. Old versions, staging hosts and deprecated routes often stay reachable long after the product team stops thinking about them. Those shadow and zombie endpoints rarely receive the patches the current version gets.
- Documentation is an attack map. An OpenAPI or GraphQL schema tells a tester every parameter, type and role boundary in minutes. So we use it, and we also look for what it fails to mention.
If a mobile app calls your API, a mobile app penetration test covers the app side as well.
Know what you want tested?
Send us your scope and get the test type, tester-days, timeline and a fixed price in writing. Prefer to compare first? See our prices.
What we test: the OWASP API Security Top 10
Ten categories, each one tested by hand against your endpoints and your roles.
Our test plan follows the OWASP API Security Top 10, extended with business logic cases specific to your product. Here is what each category means in practice rather than in the abstract:
Broken object level authorization (BOLA)
You change an ID in the path or body and the API hands you another customer’s invoice, message or account.
Broken authentication
A token signature is never verified, a refresh token never expires, or the one-time code endpoint accepts unlimited guesses.
Broken object property level authorization
The response carries fields the role should never see, or the endpoint accepts a field the form never sent, such as adding a role value to a profile update.
Unrestricted resource consumption
No rate cap, size cap or pagination limit, so one script drains your SMS budget, your third-party API quota or your database connections.
Broken function level authorization
A standard user reaches an administrative route by guessing the path or by switching the method from GET to DELETE.
Unrestricted access to sensitive business flows
A bot completes registrations, bookings or promo redemptions at machine speed, and nothing in the flow distinguishes it from a customer.
Server side request forgery (SSRF)
An endpoint fetches a URL you supply, so you point it at internal services or the cloud metadata address.
Security misconfiguration
Stack traces in error responses, permissive CORS rules, debug routes left enabled, or headers that expose the stack and its version.
Improper inventory management
Version 1 is still live and unpatched beside version 2, or a staging copy of the API answers on public DNS with production data behind it.
Unsafe consumption of APIs
Your backend trusts a partner or third-party response and writes it straight into the database without validating it.
REST, GraphQL and webhooks: what changes
REST APIs
REST API penetration testing centers on identifiers and methods. Testers walk every resource path with every role, swap object IDs between accounts, try methods the documentation does not list, and check whether filtering and pagination parameters can be pushed past their intended bounds. Versioned paths get special attention, since older versions frequently miss checks the current one has.
GraphQL APIs
GraphQL penetration testing starts with the schema and ends with the resolvers. Introspection often stays enabled in production and hands over the full type graph. Batched queries let one HTTP request carry hundreds of operations, which defeats rate limits counted per request. Deeply nested or cyclic queries can exhaust the server on their own. Authorization is the recurring problem: a mutation may be protected while a nested field on another query returns the same data unguarded. The OWASP GraphQL Cheat Sheet documents the defensive controls we verify.
Webhooks
Webhooks reverse the direction of trust, so we test your receiver. We check whether the signature is verified at all, whether it is compared in a way that resists timing analysis, whether a captured payload can be replayed later, and whether timestamps and nonces are enforced. We also test what happens when the payload is valid but the content is hostile, since many receivers treat webhook data as trusted input.
How an API penetration test runs
Scoping and rules of engagement
We agree the endpoint list, roles, environment, testing window, excluded actions and escalation contacts in writing before anything is sent.
Endpoint inventory
We reconcile the documentation against what the API actually answers, then hunt for undocumented, deprecated and staging endpoints that belong in scope.
Authorization analysis per role and per object
Every endpoint is called with every role, and every object reference is tested across account boundaries. This stage produces most of the critical findings.
Exploitation with evidence
Confirmed issues are exploited far enough to prove impact and no further, with the exact request and response captured for the report.
Reporting and retest
We deliver the report, walk your team through it, and a retest of the fixes is available once they are deployed.
What we need before testing starts
We need documentation, credentials and a defined environment. Good inputs shorten the inventory phase and put more tester time into authorization analysis, which is where the serious findings come from.
- Specification. An OpenAPI or Swagger file, a GraphQL schema, or an exported Postman collection. A recorded traffic capture works too.
- Test accounts in every role. At least two accounts per role, so we can test one user against another, plus admin, support and partner roles where they exist.
- Environment and access. Target hostnames, any VPN or certificate requirements, and allowlisting for our source addresses so a WAF does not block the test instead of the attack.
- Constraints. Endpoints that trigger payments, messages or irreversible actions, plus traffic limits and the contact who can pause the test.
What you receive
You receive two documents, and a retest is available after fixes. The Executive Summary is written for management and boards: risk in business terms, what an attacker could reach, and what to prioritize. The Technical Report is written for engineers.
Each technical finding includes the affected endpoint and method, a severity rating with the reasoning behind it, the full request and response as proof, the business impact, and step-by-step remediation that names the control to add rather than telling you to “validate input”. After your team ships the fixes, a retest of the affected endpoints is available, and we confirm in writing whether each issue is closed.
How long does it take and what does it cost?
A typical engagement takes 1 to 3 weeks of testing plus a few days to produce the report, and a standard web application or API penetration test costs between $2,500 and $5,500. We price in tester-days with no hidden fees, so the estimate moves with the amount of work rather than with the size of your company.
| What moves the price | Why it matters |
|---|---|
| Number of endpoints | Every endpoint is tested against every role, so effort grows with both counts together. |
| Roles and tenants | Multi-tenant and partner APIs multiply the authorization combinations to check. |
| Technology mix | REST, GraphQL and webhook receivers in one product means three test plans. |
| Compliance scope | Evidence mapped to specific control requirements adds reporting time. |
| Retest depth | Verifying a few fixes is quick; re-validating a reworked authorization layer is not. |
Our pricing page breaks down the ranges for other assessment types, and the services overview shows how API testing fits alongside infrastructure, cloud and red team work.
When does compliance require an API penetration test?
Compliance requires it whenever your APIs carry cardholder data, personal data or a financial service and the relevant framework asks for tested, evidenced security controls. None of these rules names “API” as a separate category, which is the point: the requirement follows the data and the service, and the API is where both live.
| Framework | Requirement | What it means for your API |
|---|---|---|
| PCI DSS v4.0 | Requirement 11.4 | Penetration testing at least every 12 months and after significant changes, so a payment API in scope follows that cycle. |
| DORA (EU) 2022/2554 | Articles 26 and 27 | Financial entities test ICT systems regularly, with threat-led testing for those in scope. Customer-facing and partner APIs are core systems here. |
| NIS2 (EU) 2022/2555 | Article 21 | Risk management measures include assessing the effectiveness of security controls, which means testing rather than documentation. |
| GDPR (EU) 2016/679 | Article 32 | Requires a process for regularly testing technical measures. An API exposing personal data sits inside that process. |
See an API test we ran
A grey box test of a high volume payment API uncovered a critical broken object level authorisation flaw and a race condition that allowed double spending, both missed by automated scans. Read the FinTech API case study.
What can you check before you hire us?
Three things you can verify for yourself: what the report looks like, who does the testing, and how a real engagement went.
What does the report look like?
Every report opens with an executive summary for management, then one page per finding: severity and CVSS score, evidence of exploitation, business impact and step-by-step remediation. A retest is available after fixes, and the updated report shows which findings are closed. Browse our sample pentest report with every section explained.
Who tests your systems?
Senior pentesters from our team of 25, holding hands-on offensive security certifications such as OSCP and OSCE alongside CEH, CISA, CISM and CRISC.
Frequently asked questions
What is the difference between API penetration testing and API security testing?
API security testing is the broad term for any activity that checks an API for weaknesses, including automated scanning, dependency checks and static analysis in the build pipeline. API penetration testing is one part of it: a manual, time-boxed engagement where testers attempt real exploitation and prove impact with evidence. Scanners find known patterns well; only a person can judge that a request is technically valid but should never have been allowed.
Can you test an API without documentation?
Yes. When no specification exists, we build the endpoint inventory from traffic captures, client applications, JavaScript bundles and mobile app analysis, then confirm each endpoint by calling it. Expect more of the schedule to go into discovery, which leaves less time for deep authorization testing at the same budget. Even a rough Postman collection shifts that balance in your favor.
Do you test in production?
We test wherever the agreed rules of engagement allow, and production is common for APIs because staging environments rarely hold representative data or the same configuration. When we work in production, we agree exclusions for destructive and irreversible actions, cap request rates, use clearly marked test accounts, and keep a named contact available to pause testing immediately.
How many endpoints can you cover?
Coverage depends on tester-days and role count rather than a fixed endpoint number, because every endpoint is tested against every role and across account boundaries. For large APIs we agree a priority order during scoping: authentication, payments, personal data and administrative endpoints first, low-risk read-only endpoints last. The report states exactly what was covered and what was not.
Do you retest after we fix the findings?
Yes, a retest is available after fixes. Once your team deploys the remediation, we re-run the original attack paths on the affected endpoints and confirm in writing whether each finding is resolved, partially resolved or still exploitable. Partial fixes are common on authorization issues, where one endpoint gets patched and a sibling endpoint keeps the same flaw.
Fixed-price quote
Request an API penetration test
Tell us what to test. You get a written scope, the number of tester-days and a fixed price before any testing starts. No hidden fees.
See a sample report first (18-page PDF, no email required)
Standard web app or API test: $2,500–$5,500, priced in tester-days. All prices
Compare it with typical pentest budgets by test type.
What happens after you send it
- Tell us what to test Send the number of endpoints and user roles, the spec if you have one, your deadline and any compliance requirement.
- Get a written scope and price We reply by email with scoping questions or a fixed quote in tester-days.
- Test, report, retest Most tests take 1–3 weeks plus a few days for the report. Critical findings are reported during testing. Retesting after fixes is available.
- OSCP, OSCE and CISSP certified testers
- 500+ penetration tests
- Aligned with OWASP WSTG, PTES and NIST SP 800-115
- Executive summary and technical report