- Join Our Company
- Email: sanjay@pjnetworks.com
- Phone: +91-9818361787
Over the past 18 months, a pattern has emerged in incident response engagements across Indian enterprise environments: attackers are no longer primarily targeting firewalls. They are targeting APIs. Specifically, they are exploiting undocumented, unmonitored, and inadequately authenticated APIs that connect business-critical applications — ERP systems, payment gateways, logistics platforms, and partner portals.
For Indian IT and security leaders, this is a shift that deserves board-level attention. The DPDP Act 2023 and CERT-In’s 2022 directions have raised the compliance stakes significantly. An API breach that exposes personal data now carries regulatory consequences that were simply not on the table three years ago.
The shift to APIs as a primary attack vector is not accidental — it is a direct consequence of digital transformation. Indian enterprises have aggressively adopted mobile-first architectures, cloud-native platforms, and B2B integration layers. Every integration creates an API endpoint. Every endpoint is a potential entry point.
What makes APIs particularly dangerous from a security standpoint is the trust model embedded in their design. APIs are built to respond to requests. They are not inherently suspicious of well-formed, authenticated requests — even if those requests are coming from an attacker who has compromised a partner’s credentials, stolen a JWT token, or discovered an unauthenticated endpoint through passive reconnaissance.
The OWASP API Security Top 10 has documented the most common failure modes for years: broken object-level authorization, broken authentication, excessive data exposure, lack of rate limiting. Yet in practice, many enterprise environments — particularly those running legacy ERP integrations alongside modern cloud platforms — still exhibit multiple vulnerabilities from this list simultaneously.
One of the most persistent challenges is what security teams call the shadow API problem. In large organisations, APIs proliferate faster than inventory systems can track them. A developer builds an internal microservice with an exposed REST endpoint for testing purposes. A third-party vendor ships an integration module that creates its own API layer. An application migration leaves behind deprecated endpoints that still respond to requests.
In Indian enterprise contexts, this problem is compounded by several factors specific to the market:
The result is an attack surface that is substantially larger than most security teams realise. A threat actor conducting passive reconnaissance — crawling mobile application APKs, reviewing JavaScript bundles served by web applications, or using specialised API discovery tools — can often identify dozens of endpoints that the internal security team has not catalogued.
Across the Indian enterprise security landscape, several attack patterns have become recurring themes:
Attackers armed with credential databases from previous breaches are targeting authentication APIs with automated stuffing attacks. Unlike web login forms, API endpoints often lack the same bot protection measures — CAPTCHAs, browser fingerprinting, login attempt throttling — that would slow down or detect these attacks on user-facing interfaces.
Mobile application backends frequently return far more data than the front-end application displays. An API that powers a customer dashboard may return a full customer record including PAN numbers, Aadhaar-linked identifiers, or financial data, with the mobile app simply choosing not to display sensitive fields. An attacker querying the same API directly receives the full payload.
Perhaps the most commonly exploited API vulnerability in practice, BOLA allows an authenticated user to access resources belonging to other users by manipulating object identifiers in API requests. In enterprise contexts, this often means an authenticated partner portal user can access data belonging to other partners by incrementing or guessing resource IDs.
Weakly implemented JWT authentication — including the use of the “none” algorithm, weak signing secrets, or insufficient token validation — allows attackers to forge authentication tokens. In environments where internal microservices trust tokens issued by a compromised application, this can enable lateral movement across the internal API landscape.
The Digital Personal Data Protection Act 2023 fundamentally changes the risk calculus for API security in India. APIs that handle personal data — which in practice means most customer-facing and HR-related APIs — now carry obligations around purpose limitation, data minimisation, and breach notification.
When an API vulnerability leads to unauthorised access to personal data, the resulting breach triggers CERT-In’s 6-hour reporting requirement. This is not a 6-hour window for investigation — it is a 6-hour window for initial notification. The practical implication is that organisations must have detection and triage capabilities that can identify a potential data breach through an API and escalate it for notification within hours, not days.
The combination of DPDP Act obligations and CERT-In’s 6-hour reporting window means that API security is no longer purely a technical matter — it is a legal and compliance obligation that requires board-level visibility.
For organisations subject to RBI, SEBI, or IRDAI oversight, there are additional sector-specific requirements around API security in digital financial services contexts. The RBI’s IT Framework for NBFC and the SEBI Cybersecurity and Cyber Resilience Framework both contain provisions that implicitly require API security controls as part of broader application security programmes.
Addressing API security requires a programme approach rather than a point-in-time assessment. The following steps represent a practical roadmap for Indian enterprise environments:
You cannot protect what you cannot see. The first step is comprehensive API discovery across all environments — production, staging, and development. This includes both actively documented APIs and shadow APIs discovered through passive and active scanning. The output should be a maintained API inventory that maps each endpoint to its owning team, data classification, authentication mechanism, and last security review date.
For each catalogued API, audit the authentication mechanism. Are tokens properly validated? Are signing secrets strong and rotated? Is BOLA mitigation implemented at the data layer rather than relying solely on front-end filtering? Are there any unauthenticated endpoints that should be protected?
Review API response payloads against the data actually required by consuming applications. Remove fields containing sensitive personal data from responses unless there is a specific, documented need. This is both a security control and a DPDP Act data minimisation obligation.
Static analysis and periodic audits are necessary but not sufficient. Runtime monitoring of API traffic — watching for unusual request volumes, unexpected geographic origins, abnormal data access patterns, and authentication anomalies — is essential for detecting exploitation attempts before they result in confirmed breaches.
API security incidents must be integrated into the broader incident response programme. Detection of a potential BOLA exploitation or credential stuffing attack must trigger investigation workflows that can determine within hours whether personal data was accessed — enabling the organisation to meet CERT-In’s 6-hour reporting requirement when applicable.
Managing API security risk at scale requires a platform that can ingest and correlate security signals from across a complex, multi-vendor environment. The platform we deploy and operate for clients in this space is PrahiX Ora, a unified SecOps platform built by PrahiX Tech Pvt Ltd — specifically designed to address the visibility and response challenges that make API security programmes difficult to sustain in practice.
Indian enterprises managing API security face a concrete logging challenge: CERT-In’s direction on 6-hour incident reporting — and the broader 180-day in-country log retention guidance — requires that API access logs, authentication events, and anomaly signals be retained in a form that supports both rapid triage and retrospective investigation. PrahiX Ora’s SIEM pillar addresses this through multi-source log and event ingestion, correlation rules mapped to MITRE ATT&CK, and graph-based attack storyline reconstruction that lets analysts trace the path of a compromise across API calls, authentication events, and downstream data access. Tiered retention — hot, cold, and archive — ensures that logs are available for the mandated retention period without compromising query performance during active investigations.
For organisations running multi-vendor estates where NOC visibility is fragmented — SAP alongside cloud-native microservices, legacy middleware alongside modern API gateways — the NMS pillar provides unified observability across firewalls, switches, access points, and WAN/SD-WAN links. LLDP/CDP topology discovery and network path tracing make it possible to understand how API traffic flows through the network, while ML-based anomaly detection and auto-healing policies give NOC teams early warning when traffic patterns deviate from baseline.
For manufacturing, retail, and multi-site enterprises where physical security and network security need to be managed under a single operations view, the video surveillance (VMS) pillar integrates ONVIF, Hikvision, and Dahua camera management with video analytics — eliminating the operational silos that can leave physical access incidents disconnected from their network security context.
Most critically for organisations subject to CERT-In’s 6-hour incident reporting window, the SOAR pillar provides the automation layer that makes that timeline realistic. Pre-built connectors and automated response actions — including pushing blocklists directly to FortiGate — mean that when an API security alert fires, the investigation and initial containment steps happen automatically, with analysts focused on triage and notification rather than manual response procedures. Automation is not a convenience here — it is what makes CERT-In’s 6-hour window achievable in practice.
For most Indian enterprises, building and sustaining an API security programme in-house faces a fundamental constraint: the specialist skills required — API security architects, runtime monitoring analysts, threat intelligence practitioners — are in extremely short supply in the Indian market. Demand substantially outpaces supply, and organisations that have identified the problem often find themselves unable to recruit the expertise needed to address it at the speed the threat environment requires.
This is where managed security service providers with deep technical expertise in both application security and network security can provide meaningful leverage. An MSSP with 24/7 NOC/SOC capabilities, experienced FortiGate and Fortinet deployment teams, and established API monitoring tooling can operationalise an API security programme in weeks rather than the months or years it would take to build the same capability organically.
The combination of platform capability and operational expertise matters here. The platform — PrahiX Ora, FortiGate’s application control and web application firewall capabilities, FortiMail for securing API-adjacent email communication channels — provides the technical foundation. The 24/7 operational coverage ensures that alerts are acted on at 3am on a Sunday as effectively as they are at 2pm on a Tuesday.
The appropriate starting point for most Indian enterprises is a structured API security assessment that covers discovery, authentication review, data exposure analysis, and runtime monitoring readiness. This assessment provides a baseline — the current state of the API attack surface — against which a remediation roadmap can be built.
The assessment should be conducted with the involvement of both security and development teams. API security is ultimately a software engineering problem as much as it is a security operations problem, and sustainable improvement requires developers to build secure APIs by default, not just for security teams to monitor and respond to insecure ones.
Key questions to answer in an initial assessment include: How many APIs does the organisation have, including shadow APIs? Which APIs handle personal data as defined by the DPDP Act? Which APIs are externally accessible versus internal-only? What authentication mechanisms are in place, and have they been reviewed recently? Is there runtime monitoring of API traffic, and does it feed into the SOC?
Answering these questions honestly — and acting on the findings — is the foundation of an effective API security programme for the Indian enterprise environment.
API security is the defining application security challenge for Indian enterprises in the current period. The attack surface is large, partially hidden, and growing faster than most security teams can track. The regulatory stakes — DPDP Act obligations, CERT-In reporting requirements, sector-specific frameworks — have raised the consequences of a breach significantly. And the skills required to manage this risk effectively are in short supply.
The organisations that get ahead of this challenge will be those that invest in comprehensive visibility, runtime monitoring, and automated response capability — and that partner with managed security providers who can bring both the platform and the operational expertise to bear at the scale the problem demands.
If your organisation is reviewing its API security posture or seeking to understand the current state of your API attack surface, PJ Networks’ security assessment and managed security services are designed for exactly this challenge. Our team of FortiGate-certified engineers and 24/7 SOC analysts can help you move from visibility to control — and from reactive response to proactive defence. Contact us to discuss an API security assessment for your organisation.