OWASP API Top 10 testing is the baseline every Indian fintech should apply to the APIs that handle UPI transactions, Aadhaar eKYC, PAN verification, and real-time fund transfers. When these APIs are compromised, the impact is not a data breach — it is direct financial loss. The OWASP API Security Top 10 2023 is the most widely adopted framework for API security testing, but generic checklists miss the India-specific attack surface. This guide explains our methodology for testing Indian fintech APIs against the OWASP Top 10, with regulator-aligned reporting that satisfies RBI, SEBI, and CERT-In expectations.
The article moves top-down: the 2023 Top 10 list, how each risk manifests in Indian fintech, the testing methodology per risk, the tooling stack, and how to structure a report for regulator acceptance.
The OWASP API Security Top 10 2023
| Rank | Risk | Description |
|---|---|---|
| API1:2023 | Broken Object Level Authorisation | Users can access other users’ data by manipulating object references |
| API2:2023 | Broken Authentication | Weak or missing authentication mechanisms |
| API3:2023 | Broken Object Property Level Authorisation | Excessive data exposure through unfiltered object properties |
| API4:2023 | Unrestricted Resource Consumption | DoS via unbounded API consumption |
| API5:2023 | Broken Function Level Authorisation | Users can access admin or privileged functions |
| API6:2023 | Unrestricted Access to Sensitive Business Flows | Automated abuse of business logic (e.g., OTP flooding) |
| API7:2023 | Server Side Request Forgery (SSRF) | APIs fetch resources from attacker-controlled URLs |
| API8:2023 | Security Misconfiguration | Default configs, verbose errors, missing patches |
| API9:2023 | Improper Inventory Management | Shadow APIs, deprecated versions, missing documentation |
| API10:2023 | Unsafe Consumption of APIs | Trusting third-party APIs without validation |
How each risk manifests in Indian fintech
API1: Broken Object Level Authorisation — UPI transaction history
A wallet app API returns transaction history using a wallet_id parameter. If the API does not verify that the authenticated user owns the wallet_id, an attacker can view any user’s transaction history by iterating IDs.
India-specific impact: UPI transaction history includes payer/payee VPA, amount, and merchant name. This is sensitive financial data under RBI guidelines.
API2: Broken Authentication — Aadhaar eKYC replay
A lending platform API accepts Aadhaar eKYC responses without nonce or timestamp validation. An attacker can replay a captured eKYC response to authenticate as the victim.
India-specific impact: Aadhaar-linked authentication is a regulated activity. Replay attacks violate UIDAI’s authentication API guidelines.
API3: Broken Object Property Level Authorisation — PAN response over-fetching
A tax-filing helper API fetches PAN details from an internal service. The internal service returns the full PAN record (name, DOB, father’s name, address), but the API only needs name and PAN number. The excess data is returned to the client.
India-specific impact: PAN + DOB + address is sufficient for identity theft and fraudulent loan applications.
API4: Unrestricted Resource Consumption — UPI collect request flooding
An attacker sends thousands of UPI collect requests to a merchant API. The API processes each request synchronously, exhausting database connections and payment-gateway quota.
India-specific impact: UPI has per-VPA transaction limits, but collect-request flooding can disable merchant checkout during peak hours (salary day, festival season).
API5: Broken Function Level Authorisation — Admin endpoints exposed
A neobank API has an admin endpoint at /api/v1/admin/accounts/approve that is not protected by admin-role verification. A regular user who discovers the endpoint can approve their own KYC.
India-specific impact: KYC approval is a regulated activity under RBI PMLA guidelines. unauthorised approval is a compliance violation.
API6: Unrestricted Access to Sensitive Business Flows — OTP brute-force
A payment API allows unlimited OTP verification attempts with no rate limiting. An attacker can brute-force a 6-digit OTP in minutes.
India-specific impact: OTP is the primary second factor for Indian fintech. Brute-force bypass undermines the entire authentication model.
API7: SSRF — Internal metadata service access
A cloud-hosted fintech API fetches webhook URLs provided by users. If the API does not validate the URL, an attacker can direct it to the cloud provider’s metadata service (169.254.169.254) and extract IAM credentials.
India-specific impact: Indian fintechs are predominantly AWS or Azure-hosted. SSRF to metadata services is a well-known attack path with high impact.
API8: Security Misconfiguration — Exposed Swagger docs
A fintech API has Swagger/OpenAPI documentation exposed on a public URL with no authentication. The documentation includes internal endpoint paths, parameter schemas, and error codes.
India-specific impact: Exposed docs accelerate reconnaissance for targeted attacks on Indian fintech infrastructure.
API9: Improper Inventory Management — Deprecated API version
A fintech maintains /api/v1/ and /api/v2/ versions. /api/v1/ has known vulnerabilities but is still accessible for backward compatibility. Attackers target the deprecated version.
India-specific impact: Deprecated API versions often lack security patches applied to current versions. They are low-hanging fruit for automated scanners.
API10: Unsafe Consumption of APIs — Trusting third-party KYC providers
A fintech consumes a third-party KYC API and trusts the response without signature verification or schema validation. An attacker who compromises the third-party API or the network path can inject fraudulent KYC data.
India-specific impact: KYC data integrity is a regulatory requirement under RBI KYC Master Direction. Compromised KYC data leads to PMLA violations.
Testing methodology per risk
For each of the ten risks, our methodology includes:
- Reconnaissance — API discovery, documentation review, parameter enumeration
- Test case design — Specific payloads for the Indian fintech context (UPI, Aadhaar, PAN, OTP)
- Exploitation — Manual + automated testing with Burp Suite, Postman, and custom scripts
- Impact assessment — Financial loss, regulatory violation, data breach classification
- Remediation guidance — Code-level fixes, configuration changes, and architectural recommendations
Tooling stack
| Tool | Purpose |
|---|---|
| Burp Suite Professional | Proxy, repeater, intruder, and scanner |
| Postman | API collection management and manual testing |
| OWASP ZAP | Automated scanning and passive analysis |
| Custom Python scripts | India-specific test cases (UPI ID enumeration, OTP brute-force) |
| ffuf / feroxbuster | API endpoint discovery |
Regulator-aligned reporting
Our API security reports for Indian fintech clients include:
- Executive summary with financial-impact quantification
- Detailed findings mapped to OWASP API Top 10 2023
- RBI Cyber Security Framework control mapping
- SEBI CSCRF application-security domain mapping
- CERT-In incident-reporting guidance if critical findings are discovered
- Remediation roadmap with priority scoring
India-specific test cases beyond OWASP Top 10
The OWASP Top 10 captures the universal API risks. For Indian fintech, additional India-specific test cases produce findings the generic methodology misses.
UPI VPA enumeration and harvesting
UPI VPAs follow predictable patterns (firstname@bankname, mobile@bank, businessname@bank). Many fintech APIs accept VPA as input without rate limiting, allowing attackers to enumerate valid VPAs at scale. The harvested VPA list becomes a phishing-target database for downstream attacks. Test approach: programmatic VPA enumeration with detection of rate-limit thresholds and verification of valid-VPA response patterns.
Aadhaar number validation bypass
APIs that accept Aadhaar numbers must validate the Verhoeff checksum and verify the format. Some APIs fail-open on invalid input, exposing downstream services to invalid-data injection. Test approach: submit Aadhaar values with invalid checksums and verify rejection; submit malformed values and verify proper error handling.
PAN format validation
PAN numbers follow a specific format (5 letters + 4 digits + 1 letter). APIs accepting PAN should validate the format and the structure (4th letter indicates entity type). Test approach: submit PAN values with structural irregularities and verify rejection.
IFSC and account-number routing manipulation
Payment APIs that accept IFSC + account number for fund transfer must validate IFSC format and verify the account-IFSC pairing through downstream NPCI / settlement APIs. Test approach: submit valid IFSC paired with invalid account number; submit IFSC for closed branches; verify proper handling.
KYC document tampering
APIs that accept KYC document uploads must verify document authenticity beyond MIME type checking. Test approach: upload visually similar files with altered content (modified PAN images, fabricated Aadhaar PDFs) and verify the API’s verification chain catches the tampering.
NPCI / banking-channel timeout exploitation
Payment APIs that integrate with NPCI or banking channels must handle timeout and partial-state correctly. An attacker who triggers a timeout during a transaction must not be able to leverage the partial state to claim transaction success. Test approach: induce timeout at various stages and verify atomicity of the transaction state machine.
Reporting structure for Indian regulators
Beyond the OWASP-aligned findings, Indian fintech reports should include sections specifically aligned to RBI, SEBI, and CERT-In expectations.
RBI Cyber Security Framework mapping
Each finding should reference the relevant RBI control area: governance, identity and access management, data protection, network security, application security, or cybersecurity operations. RBI inspections specifically look for this mapping in audit reports submitted as part of vendor onboarding.
SEBI CSCRF mapping for capital-markets entities
For fintech serving SEBI-regulated counterparties (broker integrations, AMC integrations), findings should map to the CSCRF six domains. See our SEBI CSCRF guide for the framework.
CERT-In incident-readiness implications
Critical findings (P0, P1) should trigger CERT-In Direction 20(3)/2022 awareness — if exploited, would the incident require reporting? The report should document this assessment for each critical finding.
Audit-trail and evidence requirements
Indian regulators expect audit-trail evidence — findings supported by request/response captures, screenshots, exploitation videos. Generic CVSS scores without evidence are insufficient for regulator acceptance.
Common implementation failures in Indian fintech APIs
Specific patterns we see repeatedly in Bangalore engagements:
Failure 1 — Authorisation enforcement at the gateway, not the resolver. API gateway validates the user’s authentication token but does not validate per-resource ownership; downstream services trust the gateway’s validation and skip resource-level checks. Result: BOLA at scale.
Failure 2 — Rate limiting on aggregate endpoints, not on sensitive operations. Login endpoint is rate-limited; OTP-verification endpoint is not. Result: OTP brute-force exploitation.
Failure 3 — Synchronous payment processing without idempotency tokens. Retry logic on the client side produces duplicate transactions. Result: unintended financial exposure and customer disputes.
Failure 4 — Webhook receivers without signature verification. Third-party webhook payloads accepted without verifying signature; an attacker who guesses the webhook URL can inject fraudulent events.
Failure 5 — Internal-API exposure via misconfigured ingress. Internal APIs intended for backend-to-backend communication are accidentally exposed to the public internet through misconfigured Kubernetes ingress or AWS API Gateway routing.
Practical next steps
If you need a scoped API security test, see our Web Application Security service page for the methodology and pricing. If you want to understand broader VAPT pricing, see our VAPT cost breakdown. If you are a mobile-first fintech, see our MASVS L2 guide.
For organisations that want a thirty-minute scoping conversation with a partner, the contact form in the site footer books the call directly. We commit to written scope, fixed price in INR, and direct partner-level accountability through the engagement.
OWASP API Top 10 testing FAQ
How is API testing different from web app testing? Different attack surface. Web testing focuses on UI, sessions, and rendering vulnerabilities; API testing focuses on object-level authorisation, business-flow abuse, and direct service exploitation. Many vulnerabilities in modern apps live at the API layer behind a relatively secure UI.
Do I need separate testing for GraphQL APIs? Yes. GraphQL has unique attack surfaces (introspection, depth, batched queries, alias amplification) that REST testing methodology doesn’t cover. Specialised GraphQL test plans are increasingly necessary.
Can automated tools find OWASP API Top 10 issues? Partially. Automated tools find injection, misconfiguration, and known-CVE issues. They miss BOLA, business-flow abuse, and authorisation logic flaws — which require manual analysis.
How long does an API security engagement take? 2–4 weeks for standard scope (1 API, 30–80 endpoints). Larger scopes (multi-API, microservices estate) take 4–8 weeks.
Do you test internal APIs or only public-facing? Both, depending on scope. Internal APIs frequently have weaker authorisation than public APIs and are a common compromise vector once an attacker gains a foothold.
Should I provide source code for API testing? White-box testing finds approximately 30% more issues. Most engagements use grey-box (credentials + documentation) as default; white-box adds 10–15% to fee but improves coverage materially.
Are these tests RBI / SEBI / CERT-In acceptable? Yes, when delivered by a CERT-In empanelled firm with the appropriate methodology. The report should map findings to relevant regulator framework controls.
Can I do API testing in-house? Yes for routine pre-release validation; harder for comprehensive security assessment. In-house security teams can use OWASP ZAP, Burp Community, and custom scripts; comprehensive testing typically requires external expertise.
What is the most-common finding in Indian fintech APIs? BOLA (API1) — broken object-level authorisation. APIs that authenticate users but don’t verify resource ownership. Found in approximately 70% of first-time engagements.
Does API testing find privacy issues like over-fetching? Yes — API3 (broken object property level authorisation) covers exactly this. APIs that return fields the client doesn’t need create privacy and DPDP exposure.
Are APIs that use GraphQL inherently more secure than REST? No. Different attack surfaces, similar overall risk. GraphQL-specific issues (introspection, depth bombs) replace REST-specific issues (verb tampering, path traversal).
How frequently should APIs be re-tested? Major releases trigger re-testing. For continuous-deployment fintechs, quarterly external testing supplemented by internal security testing in CI is the typical cadence.
API security as a shift-left discipline
Beyond periodic VAPT, the most-mature Indian fintech engineering organisations integrate API security into the development lifecycle. The shift-left practices that matter:
API contract validation in CI. OpenAPI / Swagger specifications validated against actual implementation. Drift between specification and implementation produces undocumented endpoints that bypass security review.
Authorisation testing in CI. Automated tests verify that endpoints reject unauthorised requests, that BOLA-style cross-tenancy attempts are rejected, that admin-endpoint access is properly restricted. These tests run on every PR.
Schema fuzzing. Tools that generate request payloads based on the API schema and verify the API handles malformed input gracefully. Catches input-validation gaps before deployment.
Rate-limit testing. Automated tests that verify rate limits apply to sensitive endpoints (login, OTP, password-reset). Catches rate-limit drift between code changes.
Dependency vulnerability scanning. API dependencies (libraries, runtimes) scanned in CI. Most modern API frameworks (Express, FastAPI, Spring) have rich vulnerability ecosystems; staying current is operationally important.
Secret management discipline. API credentials, third-party-service keys, signing keys all managed through secrets-manager (AWS Secrets Manager, HashiCorp Vault, Doppler) rather than environment variables or config files. Reduces credential leakage risk.
API observability and threat detection
Production API observability is a security control as much as an operational control. Specific patterns:
Per-endpoint metrics. Request volume, error rate, latency p50/p95/p99 per endpoint. Anomalies often indicate security issues.
Per-tenant metrics. For multi-tenant SaaS, per-tenant rate observation catches BOLA exploitation attempts that aggregate metrics miss.
Authentication-failure metrics. Spikes in 401 / 403 responses indicate brute-force attempts or credential-stuffing campaigns.
Authorisation-failure metrics. Cases where authentication succeeds but authorisation fails — often indicate enumeration attacks or escalation attempts.
Outbound API call metrics. APIs that fetch external resources (webhook callbacks, file fetches, integration calls) should be monitored for unusual destination patterns.
Indian fintech production environments increasingly invest in this observability layer; the security visibility benefits are material.
How API security testing scales with growth
For Bangalore fintechs, API security testing approach should scale with company growth.
Pre-launch / seed stage. Single API, basic authentication. Test plan covers OWASP API Top 10 fundamentals; manual testing sufficient. Annual cycle.
Series A. Multiple APIs, partner integrations beginning. Test plan extends to inter-API authorisation, partner-API security. Manual + automated testing. Quarterly external testing supplemented by CI checks.
Series B. Microservices architecture, multiple environments. Test plan covers service-mesh security, API gateway security, internal-API authorisation. Continuous testing with quarterly external validation.
Series C+. Enterprise-grade testing — bug-bounty programmes, red-team exercises, continuous penetration testing. Specialised testing for compliance frameworks (PCI-DSS, SOC 2, regulatory requirements).
The investment trajectory should match growth trajectory; under-investment at later stages produces compliance risk; over-investment at early stages produces poor capital allocation.
Choosing between pure-API testing and broader VAPT
For Bangalore fintechs deciding between pure-API testing and broader VAPT engagements, the right answer depends on context.
Pure-API testing is preferred when: APIs are the primary interface; mobile and web are thin clients; partner integrations are extensive; API-specific compliance requirements apply.
Broader VAPT is preferred when: Multiple interface types share common backend; first-time engagement establishing baseline; budget supports comprehensive scope; regulator-required reporting.
Combined engagements work best when: Mature security programme with budget for both; testing fatigue from multiple separate engagements; reporting unification benefits from single auditor.
Most Bangalore fintech engagements combine API security testing within a broader VAPT scope rather than running them as separate engagements. The unified approach produces better cross-finding correlation.
API security in the Indian fintech regulatory context
Beyond OWASP framework, Indian fintech APIs operate within specific regulatory contexts that affect testing scope.
RBI Master Direction on Digital Lending. Lending fintech APIs handling customer financial data face specific RBI expectations on data protection, customer consent, and grievance redressal. API testing for lending fintechs typically extends to digital-lending-guidelines compliance.
Account Aggregator framework. Fintechs integrating with the AA framework face specific API security expectations defined by the AA framework. Testing must verify AA-protocol-specific security controls beyond generic OWASP coverage.
SEBI CSCRF for capital-markets fintechs. Trading and wealth platforms operating under SEBI registration face CSCRF Domain 5 (application security) expectations. API testing produces CSCRF-evidence beyond OWASP coverage.
FIU-IND for crypto-adjacent fintechs. Crypto exchanges and wallet providers face FIU-IND VDA framework expectations on transaction monitoring API security and customer-due-diligence integration.
UIDAI for Aadhaar-integrated fintechs. Fintechs using Aadhaar eKYC face UIDAI authentication API guidelines including specific security expectations for replay protection, biometric handling, and consent management.
API security testing for Indian fintech should explicitly map findings to relevant regulatory frameworks rather than treating regulatory compliance as separate concern.
Continuous improvement in API security posture
Beyond periodic testing, mature Indian fintech API-security programmes operate continuous improvement cycles.
Quarterly threat-model refresh. Threat models updated based on emerging attacker patterns observed in industry incidents. Static threat models age poorly.
Annual architecture review. Architecture review identifies design-level issues that persist across multiple test cycles. Architectural fixes are higher-leverage than per-finding fixes.
Continuous developer training. Engineering teams trained on emerging API security patterns. Investment in training reduces finding rates over time.
Bug bounty integration. External-researcher reports complement formal testing. Bug-bounty program maturity correlates with finding diversity.
Security champion programmes. Engineers within product teams trained as security champions extend testing capability beyond the central security team.
These continuous-improvement practices distinguish mature Indian fintech API-security programmes from periodic-testing-only programmes.