API security testing checks whether your APIs can be abused: whether one user can read another user's data, whether tokens can be forged or replayed, whether rate limits hold, and whether business flows like OTP verification or coupon redemption can be gamed. If your web app, mobile app and partner integrations all talk to the same backend, that backend's APIs are where an attacker will spend their time.
Done properly, it combines automated scanning with manual testing against the OWASP API Security Top 10 (2023), using real accounts for every role in your system. This guide explains what each OWASP category means in practice, what changes for REST and GraphQL, how authentication is tested, and how to prepare so the engagement finds real issues instead of scanner noise.
Key takeaways
- APIs are the attack surface: modern apps are thin clients over APIs, so the API is what attackers test, not the UI.
- Scanners are not enough: the most damaging API flaws (BOLA, broken function-level authorization, business flow abuse) are logic bugs that need a human with multiple test accounts.
- Use the OWASP API Security Top 10 (2023) as the coverage baseline, from API1 Broken Object Level Authorization to API10 Unsafe Consumption of APIs.
- GraphQL needs its own checks: introspection, batching, query depth and field-level authorization.
- Preparation drives quality: share an OpenAPI/Swagger spec or Postman collection, test tokens for each role, a stable environment and rate-limit whitelisting.
Why APIs are now your main attack surface
A fintech or SaaS product today is usually a web app, an Android and iOS app, and a set of partner integrations, all calling the same REST or GraphQL APIs. The UI only decides what to show; the API decides what is allowed.
That creates three problems. First, attackers skip your UI and call the API directly with Burp Suite or Postman, so any check done only in the front end does not exist for them. Second, mobile apps ship your endpoints, and sometimes keys, inside a binary anyone can download and decompile. Third, APIs multiply quickly: versions, internal routes, partner-only endpoints and forgotten staging hosts that nobody is testing.
API security testing vs API penetration testing vs API scanners
These terms get used interchangeably, but they are not the same thing, and the difference matters when you compare quotes.
| Approach | What it does | Good at | Misses |
|---|---|---|---|
| API scanner (DAST) | Sends known attack payloads to endpoints from a spec or crawl | Injection, misconfiguration, known CVEs | Authorization logic and multi-step flows |
| API security testing / API security assessment | Broad review of design, configuration, authentication and inventory, plus scanning | Coverage across all APIs and inventory gaps | Can stay shallow if it stops at tools |
| API penetration testing (API pentesting) | Manual, expert-led exploitation with proof of impact | BOLA, privilege escalation, token flaws, business flow abuse | Limited by time, scope and documentation |
A good engagement blends all three: tools for breadth, a manual tester for depth, and hand-verified findings so developers are not chasing false positives.
OWASP API Top 10 (2023): what each risk means and how it is tested
The OWASP API Security Top 10 (2023 edition) is the standard reference for API risks. It lists risk categories, not test steps, so the table pairs each with an example and what a tester does.
| Risk | Example | How a tester checks it |
|---|---|---|
| API1 Broken Object Level Authorization | GET /api/accounts/1043/statement returns another customer's statement when the ID is changed | Uses two accounts and swaps object IDs across every endpoint and method |
| API2 Broken Authentication | Login or OTP endpoint with no lockout; JWT accepted with a tampered signature | Tests brute-force protection, token validation, expiry, logout and password reset |
| API3 Broken Object Property Level Authorization | Profile API returns PAN and KYC fields; a user sets "role":"admin" in an update call | Compares responses with what the UI needs and adds extra fields to requests (mass assignment) |
| API4 Unrestricted Resource Consumption | Export accepts limit=1000000; SMS endpoint can be called endlessly | Tests pagination, payload and upload limits, timeouts and paid third-party calls |
| API5 Broken Function Level Authorization | A normal user calls DELETE /api/admin/users/88 and it works | Calls admin and partner endpoints with low-privilege tokens; tries method switching |
| API6 Unrestricted Access to Sensitive Business Flows | A script redeems a sign-up coupon thousands of times with new accounts | Maps money-sensitive flows and tries automating them at scale |
| API7 Server Side Request Forgery | A webhook or "fetch from URL" field makes the server call internal or cloud metadata addresses | Supplies internal IPs, localhost and metadata URLs to URL parameters |
| API8 Security Misconfiguration | Stack traces, permissive CORS, debug endpoints, weak TLS | Reviews headers, CORS, error handling and HTTP methods across environments |
| API9 Improper Inventory Management | Old /v1/ still live without the checks added in /v2/; staging API exposed | Enumerates versions, hosts and undocumented endpoints against your spec |
| API10 Unsafe Consumption of APIs | Your backend trusts a partner or KYC provider's response without validation | Reviews how third-party responses, redirects and webhooks are validated |
API1, API3 and API5 are all authorization problems, and that is exactly what scanners cannot judge: they do not know which user should own which record.
REST API security testing vs GraphQL security testing
REST APIs
REST API security testing is endpoint-centric: each route and HTTP method is checked for authorization, injection and over-sharing in responses. REST-specific checks include method tampering, ID enumeration, content-type switching (JSON to XML, which can open XXE) and drift between /v1/ and /v2/.
GraphQL APIs
GraphQL security testing is different, because one endpoint exposes the whole data graph and the client shapes each query. Key checks:
- Introspection: if enabled in production, anyone can download your full schema, including internal mutations. Even when off, field suggestions in errors can leak names.
- Batching and aliases: many servers accept arrays of queries or one mutation repeated under aliases, letting an attacker try hundreds of OTPs while your rate limiter counts a single request.
- Depth and complexity limits: deeply nested or circular queries can exhaust the server; testers check depth limits, cost analysis and timeouts.
- Field-level authorization: resolvers must check permissions on every field and nested object; testers reach restricted data through a different path in the graph.
Testing authentication: JWT, OAuth 2.0 and API keys
JWT
JSON Web Tokens are convenient but easy to get wrong. A tester checks whether the server accepts alg: none, whether an RS256 token can be re-signed as HS256 using the public key (algorithm confusion), whether the HMAC secret is weak enough to crack offline, and whether expiry, issuer and audience are validated. They also check that tokens stop working after logout or password change.
OAuth 2.0 flows
For OAuth 2.0 and OpenID Connect, testing focuses on the flow, not only the token: loose redirect_uri matching that leaks authorization codes, a missing state check, PKCE not enforced for mobile and single-page apps, the implicit flow (which current OAuth security guidance discourages), and over-broad scopes. For partner and open banking-style integrations, consent and scope handling deserve extra attention.
API keys in mobile apps
Anything inside an Android or iOS app should be treated as public. Testers decompile it with Jadx or apktool, and use Frida or Objection at runtime, to extract hard-coded keys and hidden endpoints. Keys in the app should identify the app, not authorize sensitive actions. If your API mainly serves mobile clients, test the two together; our guide to mobile app penetration testing covers the app side.
Shipping a new API version, onboarding a bank or enterprise partner, or answering a security questionnaire? Our API penetration testing service covers the OWASP API Top 10 with manual testing and verified findings.
Rate limiting and business flow abuse
For fintech and consumer apps, rate limiting's real job is protecting business flows, not just stopping denial of service. Testers look at:
- OTP flows: can a 4 or 6-digit OTP be brute-forced within its validity window? Can "resend OTP" flood a victim with SMS and run up your bill?
- Coupons, referrals and cashback: can one person repeat a reward with many accounts, or send parallel redemption requests (a race condition) to apply it twice?
- Bypass tricks: rotating
X-Forwarded-Forheaders, switching API versions or using GraphQL batching.
These map to API4 and API6, rarely show up in scans, and are exactly what fraud rings automate.
The API penetration testing process, step by step
- Inventory and documentation: agree scope (hosts, versions, partner APIs, environments) and compare your OpenAPI/Swagger spec or Postman collection with what is actually live.
- Authentication setup: confirm test accounts and tokens for every role and how they are refreshed.
- Automated testing: run Burp Suite or OWASP ZAP against the spec for breadth.
- Manual testing: the core of the work: cross-account authorization, role escalation, token attacks, business flow abuse and chaining small issues into real impact.
- Reporting: each finding with CVSS severity, reproducible request and response, business impact, OWASP API Top 10 mapping and step-by-step fixes.
- Retest: after your fixes, the tester verifies each one and issues an updated report for clients or auditors.
If your API sits behind a web front end, test both together; see our guide to web application penetration testing.
API security testing checklist
Use this API penetration testing checklist to self-assess or to check a vendor's scope.
- Every endpoint, version and partner API is in the inventory.
- Object IDs are checked against the logged-in user on every request.
- Admin and partner functions reject lower-privilege tokens.
- Responses return only needed fields; requests ignore fields users should not set.
- JWTs: algorithm pinned; signature, expiry and audience enforced; revoked on logout.
- OAuth 2.0: exact
redirect_urimatching,statechecked, PKCE for public clients, minimal scopes. - No secrets in mobile or front-end code that authorize sensitive actions.
- Rate limits on login, OTP, password reset, export and paid third-party calls.
- Coupons, referrals and transfers tested for automation and race conditions.
- GraphQL: introspection off in production, depth limits, batching controlled.
- URL parameters and webhooks protected against SSRF.
- CORS, error messages and TLS reviewed in every environment.
- Third-party API responses validated before use.
How to prepare for an API security assessment
Preparation decides how much a tester can cover in the agreed time. Have these ready:
- API documentation: an up-to-date OpenAPI/Swagger spec or Postman collection; for GraphQL, the schema.
- Test tokens per role: at least two accounts per role so cross-user tests are possible.
- A stable test environment: ideally staging that mirrors production, with non-real data.
- Rate-limit and WAF whitelisting: whitelist the tester's IPs for automated phases, but keep limits on a few flows so they can be tested.
- Rules of engagement: a technical contact, an escalation path for critical findings, and exclusions such as live payment gateways.
When comparing vendors, ask for a sample report, how findings are verified, whether a retest is included and whether they test with multiple roles. Some regulators and clients ask for a CERT-In-empanelled auditor, so check your requirement.
What does API penetration testing cost in India?
Cost depends mainly on the number of endpoints and roles, REST versus GraphQL, how complex the business flows are, and whether web or mobile front ends are included. At Xtreme InfoSec, API testing starts from ₹15,000, and the final price is a fixed quote after scoping. Timelines also depend on scope and are confirmed in the quote. For a quick ballpark, use our VAPT cost estimator.
Frequently asked questions
What is API security testing?
API security testing checks your APIs for weaknesses that let attackers access data or functions they should not, such as broken authorization, weak authentication, missing rate limits and misconfiguration. It combines scanning with manual testing.
What is the OWASP API Top 10?
It is OWASP's list of the most critical API security risks. The current 2023 edition runs from API1 Broken Object Level Authorization to API10 Unsafe Consumption of APIs.
Can an automated scanner replace API penetration testing?
No. Scanners catch injection and configuration issues, but they cannot tell whether user A should see user B's data. Authorization flaws and business flow abuse need a manual tester with multiple accounts.
Is GraphQL security testing different from REST API testing?
Yes. GraphQL exposes one endpoint and lets clients shape queries, so testers add checks for introspection, batching, depth limits and field-level authorization on top of the usual tests.
How often should APIs be tested?
At least once a year, and before major releases, new partner integrations or changes to authentication. Regulators such as RBI expect regulated entities to run periodic VAPT, so check your circular.
What do I need to share before an API pentest?
An OpenAPI/Swagger spec or Postman collection, test accounts and tokens for each role, a stable test environment, and IP whitelisting for automated phases.
Get your APIs tested properly
Xtreme InfoSec runs manual, expert-led API penetration testing for REST and GraphQL APIs, mapped to the OWASP API Top 10. You get verified findings, an OWASP-mapped report with step-by-step fixes, and a free retest after you fix them.