API Penetration Testing in India: An OWASP API Top 10 (2023) Checklist for Fintech and SaaS APIs
API penetration testing checklist for Indian fintech and SaaS teams: all ten OWASP API Top 10 (2023) risks with real examples, how testers check them and fixes.
API Penetration Testing in India: An OWASP API Top 10 (2023) Checklist for Fintech and SaaS APIs
API penetration testing checklist for Indian fintech and SaaS teams: all ten OWASP API Top 10 (2023) risks with real examples, how testers check them and fixes.
API penetration testing is a hands-on test where a security expert attacks your APIs the way a real attacker would, to find flaws in login, permissions, data exposure and business logic. The most widely used checklist is the OWASP API Security Top 10 (2023), which lists the ten most serious API risks.
For Indian fintech and SaaS companies, APIs carry your most sensitive data: KYC details, bank statements, loan records and payment instructions.
Below is a checklist for all ten risks: an example, what a tester does, and what to fix.
Why scanners miss most API flaws
A scanner can tell you a header is missing or a library is old. It cannot tell you that user A should never see user B's loan file. That needs someone who understands your business rules.
This is why SecurityLit's VAPT services include manual testing for business logic flaws and custom exploits, with API security testing integrated into web application assessments. Most of the checks below require a human tester with contextual understanding.
The OWASP API Top 10 (2023) checklist
Here is the breakdown of all ten API security risks, detailing how each flaw manifests, how testers validate it, and how engineering teams should remediate it.
Broken Object Level Authorization (BOLA)
GET /loans/10452 returns your loan. Change it to /loans/10453 and you see a stranger's loan, PAN and address.
Log in as two different users and swap every object ID between them, in URLs, request bodies, query strings and headers.
Check ownership on the server for every single request that uses an ID. Hard-to-guess IDs (like UUIDs) help mitigate enumeration, but they are not an authorization fix on their own.
Broken Authentication
An OTP login endpoint with no limit on attempts, or a session JWT token that continues to function long after logout.
Brute-force OTP and password endpoints, replay expired tokens, tamper with JWT claims and signature algorithms, and exploit password reset race conditions.
Strictly rate-limit attempts, expire tokens properly, validate token signatures securely on the server, and protect every authentication-related endpoint, not only the primary login gate.
Broken Object Property Level Authorization
The profile API returns the full user record, including internal credit score fields the app never renders. Or a user sends "kyc_status": "verified" in an update JSON request and the API accepts it.
Compare what the API response payload contains against what the frontend actually needs, and attempt adding unexpected or privileged properties to write/update requests.
Return only the specific data fields each role needs, and enforce server-side allow-lists declaring exactly which attributes a user is permitted to update.
Unrestricted Resource Consumption
The "send OTP" endpoint has no velocity limit. An attacker triggers tens of thousands of SMS messages in minutes, leaving you with an astronomical carrier bill.
Send heavy request volumes, extreme pagination page sizes (?limit=100000), nested queries, and oversized file uploads while monitoring system resource thresholds.
Enforce granular rate limits per user and per IP, enforce strict maximum pagination limits, set upload quotas, and configure spending caps on third-party integrated services.
Broken Function Level Authorization
A standard retail customer calls POST /admin/disburse because the endpoint only validates that a user is logged in, rather than checking if they possess administrative role permissions.
Map every administrative and privileged API endpoint, then invoke administrative functions using a standard consumer or low-privilege user session token.
Deny by default and enforce robust role-based access control (RBAC) checks on the server for every endpoint and action.
Unrestricted Access to Sensitive Business Flows
A promotional referral cashback flow that a bot can automate thousands of times using simulated disposable accounts. Nothing is technically crashing, but the business loses capital.
Identify core business flows that generate money or sensitive value, then attempt automated high-speed execution through scripted requests.
Incorporate targeted friction such as biometric device binding, client integrity verification, velocity limiting, and heuristic fraud signals on high-value business actions.
Server Side Request Forgery (SSRF)
An API that ingests a document or webhook from a user-supplied URL. An adversary points the URL to internal private network addresses or the cloud instance metadata service (169.254.169.254).
Submit internal IP addresses, loopback (localhost), and cloud metadata endpoints to every parameter that accepts a remote URL.
Validate and allow-list allowable target domains, parse hostnames strictly, and block traffic to private and link-local IP ranges at the network level.
Security Misconfiguration
Verbose error messages leaking raw database queries or stack traces, wildcard CORS origins (Access-Control-Allow-Origin: *), or Swagger debug interfaces left exposed in production.
Audit security headers, error response structures, TLS cipher suites, open API documentation endpoints, and gateway routing configurations.
Harden default configurations, suppress technical stack traces in production responses, and conduct regular cloud gateway reviews.
Improper Inventory Management
The mobile app upgraded to /v2, but /v1 is still live on production, lacks current rate limits, and continues returning full unmasked card or account details.
Reconnaissance across historical DNS subdomains, path fuzzing for legacy version strings (/v1, /beta, /test), and traffic interception to discover undocumented endpoints.
Maintain an accurate, continuously updated inventory of all API deployments, versions, and integrations, and actively decommission retired routes.
Unsafe Consumption of APIs
Your application blindly trusts incoming JSON data from a partner KYC, credit bureau, or payment provider without schema validation, allowing compromised third-party responses to poison downstream logic.
Intercept and alter partner API payloads, inject unexpected types or payloads into webhooks, and assess behavior when partner services timeout or send malformed data.
Treat all incoming partner data with the same zero-trust model as raw user input. Enforce strict schema validation, mutual TLS or webhook signatures, and defensive timeouts.
Before you book a test: what to give the testers
The quality of an API pentest depends heavily on what you share at the start:
- API documentation: An OpenAPI or Swagger specification file, or a comprehensive Postman collection.
- Test credentials: At least two test accounts for every user role, enabling testers to systematically swap IDs and evaluate BOLA across boundaries.
- Integration list: A detailed list of third-party integrations, such as KYC verification, payment gateways, and SMS aggregators.
- Target environment: Details on which environment to test (staging vs production) and how closely staging mirrors production infrastructure.
- Business constraints: Known rate limits, transaction velocity rules, loan caps, or cashback thresholds.
SecurityLit's pricing calculator lists API Security as its own dedicated assessment category, with grey box and black box testing options. For APIs, grey box assessments typically yield significantly higher vulnerability discovery rates because testers start with schemas and tokens rather than expending engagement hours guessing routes. If you can share source code, a source code review provides a comprehensive white box assessment of your underlying business logic.
How often should Indian fintechs test their APIs?
At minimum, test before a major launch and after big changes. Regulated businesses have their own rules too. RBI's 2026 Cybersecurity Directions ask Middle Layer and larger NBFCs to run VA every six months and PT every twelve months on critical and customer-facing systems, which includes customer-facing APIs. RBI's Payment Aggregator Directions ask aggregators to submit bi-annual VAPT reports to their IT Committee.
The bigger risk is speed: every new endpoint is a new BOLA test waiting to happen. Continuous pentesting tests new releases as they ship, keeping pace with agile delivery rather than waiting for an annual audit.
A quick self-check before your next release
Answer yes or no for your most critical production API:
Does every endpoint that takes an ID check who owns that object?
Maps to: API1 BOLADo OTP, login and password reset endpoints all have attempt limits?
Maps to: API2 & API4Does each response return only the fields the screen needs?
Maps to: API3 Data ExposureAre old API versions switched off?
Maps to: API9 InventoryDo you validate data coming back from partner APIs?
Maps to: API10 Unsafe ConsumptionAny "no" is a clear signal of an authorization or control gap and a good place to start testing.
Frequently Asked Questions
What is BOLA and why does it matter for fintech?
BOLA (Broken Object Level Authorization) is the #1 risk in the OWASP API Security Top 10 (2023). It occurs when an API endpoint accepts an object identifier (like a loan ID or account number) and returns data without validating whether the requesting user actually owns that object. In fintech, BOLA can instantly expose confidential KYC documents, bank balances, and loan details to unauthorized users.
Is the OWASP API Top 10 the same as the OWASP Top 10?
No. The general OWASP Top 10 covers web application vulnerabilities broadly (such as XSS and injection). The OWASP API Security Top 10 (2023) focuses specifically on modern stateless and RESTful API architectures, addressing API-specific flaws such as BOLA, mass assignment, automated business flow abuse, and third-party API trust boundaries.
Should we test GraphQL APIs differently from REST?
The same core ten risks apply to both architectures. However, GraphQL introduces unique attack surfaces that require specialized testing, including query depth and circular complexity attacks (Unrestricted Resource Consumption), introspection abuse, and granular field-level authorization checks.
Can we test APIs in staging instead of production?
Testing in staging is common and recommended before feature releases, provided the staging environment mirrors production schemas, gateways, and authentication rules. However, regulated Indian NBFCs should note that RBI's 2026 Cybersecurity Directions require testing on production systems, with any test-environment exception documented and formally approved by the Information Security Committee.
Want your APIs tested against all ten OWASP risks, with a retest after fixes?
Book a free scoping call with SecurityLit or get an instant estimate for API security testing.
API penetration testing is a hands-on test where a security expert attacks your APIs the way a real attacker would, to find flaws in login, permissions, data exposure and business logic. The most widely used checklist is the OWASP API Security Top 10 (2023), which lists the ten most serious API risks.
For Indian fintech and SaaS companies, APIs carry your most sensitive data: KYC details, bank statements, loan records and payment instructions.
Below is a checklist for all ten risks: an example, what a tester does, and what to fix.
Why scanners miss most API flaws
A scanner can tell you a header is missing or a library is old. It cannot tell you that user A should never see user B's loan file. That needs someone who understands your business rules.
This is why SecurityLit's VAPT services include manual testing for business logic flaws and custom exploits, with API security testing integrated into web application assessments. Most of the checks below require a human tester with contextual understanding.
The OWASP API Top 10 (2023) checklist
Here is the breakdown of all ten API security risks, detailing how each flaw manifests, how testers validate it, and how engineering teams should remediate it.
Broken Object Level Authorization (BOLA)
GET /loans/10452 returns your loan. Change it to /loans/10453 and you see a stranger's loan, PAN and address.
Log in as two different users and swap every object ID between them, in URLs, request bodies, query strings and headers.
Check ownership on the server for every single request that uses an ID. Hard-to-guess IDs (like UUIDs) help mitigate enumeration, but they are not an authorization fix on their own.
Broken Authentication
An OTP login endpoint with no limit on attempts, or a session JWT token that continues to function long after logout.
Brute-force OTP and password endpoints, replay expired tokens, tamper with JWT claims and signature algorithms, and exploit password reset race conditions.
Strictly rate-limit attempts, expire tokens properly, validate token signatures securely on the server, and protect every authentication-related endpoint, not only the primary login gate.
Broken Object Property Level Authorization
The profile API returns the full user record, including internal credit score fields the app never renders. Or a user sends "kyc_status": "verified" in an update JSON request and the API accepts it.
Compare what the API response payload contains against what the frontend actually needs, and attempt adding unexpected or privileged properties to write/update requests.
Return only the specific data fields each role needs, and enforce server-side allow-lists declaring exactly which attributes a user is permitted to update.
Unrestricted Resource Consumption
The "send OTP" endpoint has no velocity limit. An attacker triggers tens of thousands of SMS messages in minutes, leaving you with an astronomical carrier bill.
Send heavy request volumes, extreme pagination page sizes (?limit=100000), nested queries, and oversized file uploads while monitoring system resource thresholds.
Enforce granular rate limits per user and per IP, enforce strict maximum pagination limits, set upload quotas, and configure spending caps on third-party integrated services.
Broken Function Level Authorization
A standard retail customer calls POST /admin/disburse because the endpoint only validates that a user is logged in, rather than checking if they possess administrative role permissions.
Map every administrative and privileged API endpoint, then invoke administrative functions using a standard consumer or low-privilege user session token.
Deny by default and enforce robust role-based access control (RBAC) checks on the server for every endpoint and action.
Unrestricted Access to Sensitive Business Flows
A promotional referral cashback flow that a bot can automate thousands of times using simulated disposable accounts. Nothing is technically crashing, but the business loses capital.
Identify core business flows that generate money or sensitive value, then attempt automated high-speed execution through scripted requests.
Incorporate targeted friction such as biometric device binding, client integrity verification, velocity limiting, and heuristic fraud signals on high-value business actions.
Server Side Request Forgery (SSRF)
An API that ingests a document or webhook from a user-supplied URL. An adversary points the URL to internal private network addresses or the cloud instance metadata service (169.254.169.254).
Submit internal IP addresses, loopback (localhost), and cloud metadata endpoints to every parameter that accepts a remote URL.
Validate and allow-list allowable target domains, parse hostnames strictly, and block traffic to private and link-local IP ranges at the network level.
Security Misconfiguration
Verbose error messages leaking raw database queries or stack traces, wildcard CORS origins (Access-Control-Allow-Origin: *), or Swagger debug interfaces left exposed in production.
Audit security headers, error response structures, TLS cipher suites, open API documentation endpoints, and gateway routing configurations.
Harden default configurations, suppress technical stack traces in production responses, and conduct regular cloud gateway reviews.
Improper Inventory Management
The mobile app upgraded to /v2, but /v1 is still live on production, lacks current rate limits, and continues returning full unmasked card or account details.
Reconnaissance across historical DNS subdomains, path fuzzing for legacy version strings (/v1, /beta, /test), and traffic interception to discover undocumented endpoints.
Maintain an accurate, continuously updated inventory of all API deployments, versions, and integrations, and actively decommission retired routes.
Unsafe Consumption of APIs
Your application blindly trusts incoming JSON data from a partner KYC, credit bureau, or payment provider without schema validation, allowing compromised third-party responses to poison downstream logic.
Intercept and alter partner API payloads, inject unexpected types or payloads into webhooks, and assess behavior when partner services timeout or send malformed data.
Treat all incoming partner data with the same zero-trust model as raw user input. Enforce strict schema validation, mutual TLS or webhook signatures, and defensive timeouts.
Before you book a test: what to give the testers
The quality of an API pentest depends heavily on what you share at the start:
- API documentation: An OpenAPI or Swagger specification file, or a comprehensive Postman collection.
- Test credentials: At least two test accounts for every user role, enabling testers to systematically swap IDs and evaluate BOLA across boundaries.
- Integration list: A detailed list of third-party integrations, such as KYC verification, payment gateways, and SMS aggregators.
- Target environment: Details on which environment to test (staging vs production) and how closely staging mirrors production infrastructure.
- Business constraints: Known rate limits, transaction velocity rules, loan caps, or cashback thresholds.
SecurityLit's pricing calculator lists API Security as its own dedicated assessment category, with grey box and black box testing options. For APIs, grey box assessments typically yield significantly higher vulnerability discovery rates because testers start with schemas and tokens rather than expending engagement hours guessing routes. If you can share source code, a source code review provides a comprehensive white box assessment of your underlying business logic.
How often should Indian fintechs test their APIs?
At minimum, test before a major launch and after big changes. Regulated businesses have their own rules too. RBI's 2026 Cybersecurity Directions ask Middle Layer and larger NBFCs to run VA every six months and PT every twelve months on critical and customer-facing systems, which includes customer-facing APIs. RBI's Payment Aggregator Directions ask aggregators to submit bi-annual VAPT reports to their IT Committee.
The bigger risk is speed: every new endpoint is a new BOLA test waiting to happen. Continuous pentesting tests new releases as they ship, keeping pace with agile delivery rather than waiting for an annual audit.
A quick self-check before your next release
Answer yes or no for your most critical production API:
Does every endpoint that takes an ID check who owns that object?
Maps to: API1 BOLADo OTP, login and password reset endpoints all have attempt limits?
Maps to: API2 & API4Does each response return only the fields the screen needs?
Maps to: API3 Data ExposureAre old API versions switched off?
Maps to: API9 InventoryDo you validate data coming back from partner APIs?
Maps to: API10 Unsafe ConsumptionAny "no" is a clear signal of an authorization or control gap and a good place to start testing.
Frequently Asked Questions
What is BOLA and why does it matter for fintech?
BOLA (Broken Object Level Authorization) is the #1 risk in the OWASP API Security Top 10 (2023). It occurs when an API endpoint accepts an object identifier (like a loan ID or account number) and returns data without validating whether the requesting user actually owns that object. In fintech, BOLA can instantly expose confidential KYC documents, bank balances, and loan details to unauthorized users.
Is the OWASP API Top 10 the same as the OWASP Top 10?
No. The general OWASP Top 10 covers web application vulnerabilities broadly (such as XSS and injection). The OWASP API Security Top 10 (2023) focuses specifically on modern stateless and RESTful API architectures, addressing API-specific flaws such as BOLA, mass assignment, automated business flow abuse, and third-party API trust boundaries.
Should we test GraphQL APIs differently from REST?
The same core ten risks apply to both architectures. However, GraphQL introduces unique attack surfaces that require specialized testing, including query depth and circular complexity attacks (Unrestricted Resource Consumption), introspection abuse, and granular field-level authorization checks.
Can we test APIs in staging instead of production?
Testing in staging is common and recommended before feature releases, provided the staging environment mirrors production schemas, gateways, and authentication rules. However, regulated Indian NBFCs should note that RBI's 2026 Cybersecurity Directions require testing on production systems, with any test-environment exception documented and formally approved by the Information Security Committee.
Want your APIs tested against all ten OWASP risks, with a retest after fixes?
Book a free scoping call with SecurityLit or get an instant estimate for API security testing.