By Xhield Team · June 2, 2026 · 9 min read
Tags: API Security VAPT CERT-In OWASP India Cybersecurity CISO Attack Surface Management Enterprise Security Penetration Testing
There's a pattern I see play out repeatedly in enterprise security conversations.
A security team completes their annual VAPT. The pentest firm tests the web application, the network perimeter, maybe a few critical internal systems. The report comes back. Findings are remediated. The CERT-In compliance box is ticked.
Six months later, there's an incident. An attacker exfiltrated customer data through an internal API that was never tested — an endpoint exposed to the internet for a third-party integration, running without authentication on a non-standard port, sitting quietly outside the scope of everything the pentest covered.
It's not a hypothetical. Versions of this story are increasingly common. And they point to a structural gap in how most Indian enterprises think about VAPT scope: APIs are being systematically undertested, even as they've become the most consequential part of the attack surface.
The API Explosion Nobody Scoped For
Ten years ago, a web application was largely self-contained. It had a frontend, a backend, a database. Penetration testing scope was relatively straightforward.
Today, that same application probably calls dozens of internal microservices, integrates with five or six SaaS platforms via REST APIs, exposes webhook endpoints for third-party notifications, authenticates through an OAuth provider, and sends data to an analytics pipeline that calls its own set of downstream APIs.
Every one of those connections is a potential attack surface. Most of them are not in your VAPT scope.
The numbers reflect how fast this has moved. The average enterprise now runs hundreds of APIs, with a significant portion — often called "shadow APIs" or "zombie APIs" — that engineering teams no longer actively maintain but that remain exposed and callable. Research consistently shows that most organisations don't have a complete, accurate inventory of their own API surface. If your organisation doesn't know what APIs it has, your VAPT firm certainly doesn't.
Why APIs Are Different From Web Applications
The reason APIs are underrepresented in VAPT scope isn't negligence — it's that traditional penetration testing methodology was designed for a different era. Web application testing has decades of tooling, methodology, and tester expertise behind it. API security testing is newer, less standardised, and requires a different mindset.
A few things make APIs specifically harder to test:
They're not always visible. A web application has a UI — you can see it, click through it, map it. An API endpoint sitting on port 8443 with no documentation doesn't announce itself. Finding it requires active reconnaissance: port scanning, traffic analysis, JavaScript source review, and sometimes just asking the development team — who may not have a complete list themselves.
They often lack the security controls web apps have. WAFs, rate limiting, and authentication enforcement that apply to customer-facing web applications frequently don't apply to internal APIs. The assumption — usually unstated — is that internal APIs are only reachable internally. That assumption is often wrong, and attackers know it.
Business logic vulnerabilities are endemic. The most dangerous API vulnerabilities aren't the ones automated scanners find — they're logic flaws. Broken Object Level Authorisation (BOLA), where an API returns data it shouldn't based on the requesting user's permissions, is consistently the top finding in API-specific assessments. Automated tools miss it almost entirely. It requires a tester who understands the application's data model and tests authorization logic explicitly.
The OWASP API Security Top 10 is not the same list as the web app Top 10. Many VAPT firms apply their web application methodology to APIs, treating them as a subset of web app testing. They're not. BOLA, Broken Function Level Authorisation, Excessive Data Exposure, Mass Assignment — these are API-specific vulnerability classes that require specific testing approaches.
What CERT-In Actually Requires (And What It Implies)
CERT-In's directions don't use the word "API" — the regulations were written at a level of abstraction that applies across ICT systems broadly. But the implications for API security are direct and unavoidable.
The 6-hour reporting window applies to API breaches. If an attacker exfiltrates customer data through an unauthenticated API endpoint, that is a reportable CERT-In incident. The fact that the endpoint wasn't in your VAPT scope doesn't exempt it. The clock starts from when you become aware — and you may not become aware quickly if the API isn't being monitored.
The 180-day log retention requirement applies to APIs too. Are your API gateway logs being retained for 180 days, within Indian jurisdiction? Many organisations log their application tier but don't have equivalent logging coverage on internal APIs, especially those exposed through third-party integrations or microservices architectures. A breach through an unlogged API means you can't characterise the scope of what was accessed — which is both a compliance failure and a practical incident response problem.
The annual VAPT mandate for critical sectors is only useful if APIs are in scope. A VAPT report that covers your web application but not the APIs it depends on is not a complete assessment of your technical risk. Critical sector organisations submitting VAPT reports to CERT-In that systematically exclude APIs are submitting an incomplete picture of their security posture — one that a sophisticated auditor or a determined attacker will both identify as incomplete.
What a Real API Attack Surface Looks Like
To understand why APIs fall through the cracks, it helps to be specific about what "API attack surface" actually means in a mid-sized Indian enterprise:
Customer-facing APIs. REST or GraphQL endpoints that mobile apps, web frontends, and partner integrations call directly. These are usually in VAPT scope — but even here, GraphQL introspection vulnerabilities, excessive data exposure in response payloads, and mobile-specific authentication weaknesses are frequently missed by traditional web app testers.
Internal microservices. Backend services that communicate with each other. Typically assumed to be unreachable from the internet. Often reachable due to misconfigured security groups, accidentally public cloud deployments, or network segmentation failures.
Third-party integration endpoints. Webhooks and callbacks that your application exposes for external services to call. Payment gateways, CRM integrations, communication platforms. These often receive unvalidated external input and are rarely tested.
Shadow APIs and zombie APIs. Endpoints created for testing, deprecated versions of APIs that were never decommissioned, or integrations set up by development teams without going through security review. These are the API equivalent of Shadow IT — and they carry the same risks.
API keys and credentials in transit. How your APIs authenticate — hardcoded keys in mobile apps, insufficiently protected OAuth tokens, API credentials committed to source code repositories — is as important as the APIs themselves.
The Pre-VAPT Discovery Problem
Here's the root cause of all of this: you can't test what you don't know exists.
VAPT scope is defined by what you give your pentest firm. Most organisations give their pentest firm an asset register. That asset register was compiled by IT. IT knows about the applications it manages — not the microservices a product team spun up last quarter, not the API endpoint a developer exposed for a third-party integration they set up six months ago, not the zombie API that never got decommissioned when the service it supported was deprecated.
The solution isn't to criticise IT or development teams. It's to change how pre-VAPT discovery works.
Effective API discovery requires combining multiple signals: active port scanning across your IP ranges, JavaScript source analysis of your web applications (which often reveals API endpoints in client-side code), traffic analysis if you have network visibility, review of API gateway configurations, and direct engagement with engineering teams using structured questionnaires about integration architecture.
None of this is particularly exotic. It's just time-consuming — which is why it gets compressed or skipped when organisations are in a hurry to get to the pentest itself. And when it gets skipped, APIs don't make it into scope.
What Good API Security Testing Actually Covers
For organisations that want to close this gap, here's what a rigorous API security assessment looks like beyond the basics:
Complete API inventory as a precondition. Before testing begins, build the most complete possible list of APIs — internal, external, third-party, deprecated. This should be an active discovery exercise, not just a review of existing documentation.
Authentication and authorisation testing for every endpoint. Not just "does authentication exist" but "can I access objects belonging to other users," "can I call administrative functions from a non-admin account," "does token expiry and revocation work correctly." BOLA and Broken Function Level Authorisation testing is manual work — it requires understanding the application's data model and testing permission logic explicitly.
Input validation and injection testing. APIs that accept user-supplied input need to be tested for injection vulnerabilities — SQL injection, NoSQL injection, command injection — but in API-specific ways, including JSON/XML payloads, header injection, and parameter manipulation.
Rate limiting and resource exhaustion. APIs without rate limiting can be used for credential stuffing, data harvesting, and denial of service. This is often untested.
Third-party integration review. How data flows between your APIs and external services, what validation exists on inbound webhook calls, and whether integration credentials are properly managed.
Closing the Gap Before Your Next VAPT
If your next VAPT engagement is coming up, a few concrete things worth doing before the pentest firm arrives:
Ask your development and DevOps teams directly: what APIs do we have that aren't in the standard asset register? You'll almost certainly get answers that surprise you.
Run external reconnaissance against your domains and IP ranges looking specifically for API-like responses — endpoints returning JSON, services on common API ports (8080, 8443, 3000), and routes containing /api/, /v1/, /graphql. This is a quick way to surface shadow APIs that aren't in anyone's documentation.
Review your API gateway or load balancer logs for traffic patterns. Endpoints receiving external calls that you didn't know were externally accessible are immediate candidates for testing.
When briefing your VAPT firm, provide explicit API scope — not just "test our web application" but a list of API endpoints, authentication mechanisms, and third-party integrations, with instructions to treat API-specific vulnerability classes per OWASP API Security Top 10.
The annual VAPT you're required to do is only as useful as the scope it covers. APIs are where your customers' data lives, where your integrations run, and where attackers are increasingly focusing. Make sure they're in scope.
At xhield.tech, we're building AI-powered attack surface intelligence that surfaces your complete API exposure — including the endpoints that aren't in your asset register — so your VAPT scope reflects your real risk. If you want to make sure your next assessment covers your full API surface, let's talk.