API Security Testing: A Practical Guide for Modern Apps

The last three breaches I was called in to investigate had nothing to do with a clever exploit. No zero-day. No malware. Just an API endpoint that trusted the number in the URL. Change the account ID from 4471 to 4472, and you were reading someone else's KYC documents. The application had a firewall, a WAF, and a shiny SOC 2 badge on its website. None of it mattered, because the vulnerability lived in the business logic, and none of those controls read business logic.

Here is the shift most security programmes have not caught up with. Your attack surface is no longer a login page. It is a few hundred JSON endpoints your mobile app and your partner integrations quietly talk to, most of which were never in scope for a single penetration test. If you are testing the web front-end and calling it application security, you are guarding the front door of a house with the back wall missing.

Ten years ago the browser was the client, and the server rendered pages. Security testing followed that shape. Today the browser is just one client among many. Your React app, your Android build, your iOS build, your partner banks, your aggregators, and increasingly a handful of AI agents all hit the same backend through APIs. The rendering moved to the client, and so did the trust boundary problems.

An API (Application Programming Interface, the machine-to-machine contract your frontend uses to talk to your backend) exposes raw objects and operations. There is no UI to hide behind. If your web page never showed a delete button to a normal user, an attacker never saw it either. But the DELETE endpoint still exists, and a script does not care what buttons your designer drew. This is the core reason APIs fail differently: the client is untrusted, fully visible, and endlessly scriptable.

For Indian regulated entities this is not abstract. Under the RBI Master Direction on Digital Payment Security Controls, and the account aggregator ecosystem governed by the RBI NBFC-AA framework, sensitive financial data flows almost entirely over APIs. The DPDP Act 2023 treats a leaked KYC record as a reportable personal data breach regardless of whether the leak came through a web form or a REST endpoint. The regulator does not distinguish between attack surfaces. Neither should your test scope.

OWASP publishes a dedicated API Security Top 10, separate from the web application list, precisely because the failure modes differ. I will not just recite the list. I will tell you which ones we find on almost every engagement, and which are theoretical noise. In a typical Indian fintech or SaaS assessment, the first three below account for the overwhelming majority of the serious findings.

Broken Object Level Authorization, shortened to BOLA, is the account-ID-in-the-URL problem from my opening. It is the single most impactful API vulnerability, and it is almost invisible to automated scanners. A scanner does not know that order 4472 belongs to a different tenant than order 4471. It sees two 200 OK responses and moves on. Only a human who understands your data model catches it. This is why an API pen test that is really just a scanner with a licence is worthless for the risk that matters most.

The variants are endless. Numeric IDs are the obvious case. But we have broken BOLA on UUIDs leaked in earlier responses, on predictable invoice numbers, on base64-encoded email addresses used as identifiers, and on GraphQL node IDs that were just the primary key wrapped in a prefix. If any identifier reaches the client, assume the attacker can supply their own value for it.

API3 is the quiet one. Your update-profile endpoint accepts a JSON body. The frontend sends name and phone. But the backend deserialises the whole object into your user model, and nothing stops a caller from adding a field the UI never showed. We routinely add is_admin true, kyc_verified true, or wallet_balance 100000 to a request body and watch the server accept it. On one lending platform, a borrower could set their own credit_limit by adding a field the mobile app never sent.

A serious API assessment is not a button you press. It is a methodology, and roughly seventy per cent of the value comes from the first two phases below, which are almost entirely manual. Here is how a real engagement runs, phase by phase.

You cannot test what you do not know exists. The first job is enumerating every endpoint, not just the documented ones. We pull the Swagger or OpenAPI spec if it exists, but we never trust it as complete. We proxy the mobile app through Burp Suite or mitmproxy and watch what it actually calls. We decompile the Android APK and grep the strings for hardcoded URLs. We check for v1 endpoints that were meant to be retired when v2 launched but never got switched off. This is API9, improper inventory management, and the staging endpoint someone forgot about is where the crown jewels usually leak.

We create at least two accounts at each privilege level. A low-privilege user, a second low-privilege user in a different tenant, and an admin. This matrix is the whole game for BOLA and function-level auth testing. With two peer accounts you prove horizontal privilege escalation. With a low and a high account you prove vertical escalation. Without this account matrix, an API test is guessing.

Now the manual work. Every object ID gets swapped between the two accounts. Every request body gets extra fields injected. Every admin endpoint gets called with a normal token. We test whether the JWT (JSON Web Token, the signed credential most APIs use) actually verifies its signature, or whether changing the algorithm to none is accepted. We test rate limiting on OTP and login. We test whether the business flow, say applying a discount coupon or completing KYC, can be replayed or reordered.

A finding without a reproducible request and a business-impact statement is noise. Every finding in a CyberSigma report carries the exact HTTP request to reproduce it, the affected records or accounts, a CVSS score, and a remediation that a developer can act on without a follow-up call.

A mid-sized NBFC, roughly two lakh active borrowers, asked us to test their new customer app before a festive-season launch. The web app had been tested twice before and was clean. Their assumption was that the mobile backend was the same code, so it inherited the same assurance.

Within the first afternoon, phase-one enumeration turned up an endpoint the Swagger file did not mention: /api/v1/loan/statement. The v2 app used a token-scoped version. But v1 was still live, still accepted valid tokens, and took the loan account number as a query parameter with no ownership check. Two accounts, two account numbers, one swap, and we were reading a stranger's complete repayment history, PAN, and disbursed amount. Classic BOLA on a forgotten inventory item.

The business impact was not one record. Loan account numbers were sequential. A short script could have walked the entire book in a few hours. Under the DPDP Act this is a personal data breach of financial information on the entire customer base, with the seventy-two-hour reporting obligation to the Data Protection Board and near-certain reputational damage during the biggest sales window of the year. The fix took the developer forty minutes: an ownership check and switching off the v1 route. The gap between a forty-minute fix and a two-lakh-record breach was one manual request that no scanner would have flagged.

Most weak API tests are weak because the scoping was weak. Effort in an API test scales with the number of endpoints and the number of distinct roles, not with the number of servers. Give your tester these six things before day one and you will get a real assessment rather than a scan.

On environment: I always push clients towards a production-parity staging environment with synthetic data. Testing BOLA properly means deliberately accessing other users' records, which you cannot ethically do against live customer data. A staging environment with realistic seeded data lets us be aggressive without touching a real borrower's PAN.

Indian pricing for API penetration testing varies wildly, and the low end is usually a rebadged automated scan. Here is a realistic range for genuine, manual-led testing by an experienced team. The single biggest cost driver is the number of endpoints combined with the number of roles, because that is what determines how many authorisation permutations must be tested by hand.

Two line items people forget to budget. First, the retest. A pen test without a fix-verification retest gives you findings but no assurance the fixes work; always contract for one. Second, if you need a CERT-In empanelled auditor's certificate, for RBI, SEBI, or an insurance-linked audit, make sure the vendor is actually on the current CERT-In empanelment list, because a report from a non-empanelled firm will not satisfy the regulator no matter how good the testing was.

If you do nothing else after reading this, run your APIs against this list. It maps directly to the findings we raise most often, and most items are a developer-day of work each.

The breach in my opening was not sophisticated. It was an endpoint that trusted a number. That is the shape of nearly every serious API failure: not a genius exploit, but a missing check on a surface nobody thought to test. Your firewall cannot see it. Your WAF cannot see it. Your scanner cannot see it. Only someone who reads your business logic and swaps IDs between two accounts can. That is the whole job, and it is why API security is a human discipline before it is a tooling one.

If you are shipping APIs into a regulated space and are not sure your last pen test actually opened the request bodies and swapped the IDs, that is worth a conversation. At CyberSigma we are CERT-In empanelled auditors who do this by hand, endpoint by endpoint, and hand you findings with the exact request to reproduce each one, not a scanner PDF.