API Security Testing in Mumbai · Fintech & BFSI APIs

Mumbai's money moves over APIs now, not screens. The net-banking front-end is a thin client over a REST/GraphQL back-end; UPI, IMPS and NEFT are NPCI API rails; lending runs on partner and co-lending APIs; and the Account Aggregator ecosystem has turned consent and financial-information flows into a fabric of FIU/FIP/AA endpoints. Macksofy's API security practice tests that fabric the way an attacker with a valid token and a Burp licence actually attacks it — from our BKC office, with senior consultants who have shipped API assessments into RBI- and SEBI-regulated environments and do not subcontract.

The dominant failure class in BFSI APIs is authorization, not authentication. We anchor every Mumbai engagement on the OWASP API Security Top 10 (2023), and the findings that move audit committees are almost always BOLA (API1 — object-level authorization, where customer A reads customer B's statement by incrementing an account reference) and BFLA (API5 — function-level authorization, where a retail token reaches an admin or maker-checker endpoint). We test these manually with two authenticated personas per role, because scanners cannot reason about which object belongs to whom. Broken object-property-level authorization (API3) — mass assignment of a 'kyc_verified' or 'limit' field, or excessive data exposure leaking PAN and Aadhaar fragments — is the next richest seam.

For payment aggregators and PA-PG licensees the scope follows the cardholder-data and settlement flow: payout, refund, settlement-reconciliation and merchant-onboarding APIs, with explicit tests for unrestricted access to sensitive business flows (API6 — refund-abuse, settlement-race and cashback-farming logic) and unrestricted resource consumption (API4 — the rate-limit and velocity-control bypass that turns an OTP or balance-enquiry endpoint into a money or enumeration oracle). For brokers and AMCs we test the algo and market-data APIs, the OMS-to-exchange gateway, and the order-throttle bypass that SEBI's technical-glitch framework cares about.

Account Aggregator is now a first-class Mumbai scope. We test the FIU consent-artifact handling, the FIP data-delivery endpoints and the AA routing layer for consent-scope violation, replay of signed consent artifacts, and over-fetch beyond the consented FI types and date range — the exact abuse paths that turn a compliant AA integration into a data-leak. SSRF (API7) gets focused attention wherever an API fetches a remote resource — webhook registration, document-pull from a partner URL, or an image-proxy — because in a cloud-hosted bank that is the path from API to metadata service to credentials.

The deliverable is regulator-grade, not a scanner export. Every High and Critical carries a manually-validated proof-of-exploit, a CVSS v3.1 score, a Macksofy business-impact score tied to transaction value-at-risk, and a remediation that an engineering lead can action without translation — the specific authorization check, the schema allow-list, the rate-limit policy. The executive summary maps findings to the RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices and, for brokers, SEBI CSCRF — so the same binder closes the API slice of the annual VAPT obligation. Improper inventory management (API9 — the forgotten /v1 endpoint still live after /v2 shipped) is reported as a programme finding, because shadow and zombie APIs are where Mumbai breaches actually start.

Re-testing is in the SoW, not a change-order: every Critical and High is re-validated post-fix inside a 60-day window at no extra cost, and for tier-1 clients we pair each exploitable finding with a detection rule the SOC can deploy the same week. Procurement closes through the CTO and CRO with the audit-committee secretary copied; we attach the Macksofy ISMS pack and the empanelled-auditor letter to every Mumbai proposal so infosec and legal don't hold the PO. Onsite kickoff and exit are same-day across BKC and Lower Parel and inside four hours across the wider MMR.