API Security Testing: The Complete Checklist for Fintech Developers

In fintech, the API is the product. A checklist built on the OWASP API Security Top 10.

Indian fintech products are, underneath, collections of APIs: onboarding, KYC, UPI collect requests, lending decisions, statements. Attackers know this, and they rarely bother with the mobile app’s interface when they can call the API directly. This checklist follows the OWASP API Security Top 10 (2023) and adds the fintech-specific checks we find most useful.

Authorisation (where most serious findings live)

• Object level: change every ID in every request (account, loan, transaction, document) and confirm you cannot read or modify another customer’s record. This is API1, Broken Object Level Authorization, and it is the most common critical finding in financial APIs.
• Property level: check that responses do not over-share (full PAN, Aadhaar, internal risk scores) and that users cannot set fields they should not, such as credit limit or KYC status (API3).
• Function level: confirm that customer tokens cannot call admin or partner endpoints (API5).

Authentication

• Test OTP flows for brute force, reuse and missing expiry.
• Check token lifetime, revocation on logout and password change, and signature validation for JWTs (API2).
• Make sure partner and server-to-server credentials are not embedded in the mobile app.

Business flows

• Can a reward, cashback or referral be claimed repeatedly by replaying a request? (API6)
• Are transaction amounts, currency and beneficiary validated on the server, not only in the app?
• Are idempotency keys enforced so a retried payment cannot be processed twice?

Resource consumption and abuse

• Rate limits on OTP, login, search and statement generation (API4).
• Limits on page size, file upload size and expensive report generation.

Infrastructure and inventory

• An up-to-date inventory of every API version, including old versions still reachable in production (API9).
• No verbose errors, stack traces or debug endpoints (API8).
• Outbound calls that take user-supplied URLs are restricted to prevent server-side request forgery (API7).
• Responses from third-party APIs such as credit bureaus or payment gateways are validated before use (API10).

Regulatory context

The RBI’s directions on digital payment security controls expect regulated entities to secure the applications and interfaces behind their payment products, and many of the incident types CERT-In requires to be reported within six hours start at an API. Testing before release, and again after significant changes, is simply part of operating a financial product in India.

This article is general information, not legal advice. Compliance services do not guarantee certification; certification bodies issue certificates.