- Join Our Company
- Email: sanjay@pjnetworks.com
- Phone: +91-9818361787
India’s enterprise technology landscape has undergone a seismic shift. What once ran as monolithic applications on on-premises servers now operates as dozens — sometimes hundreds — of loosely coupled microservices, each exposing APIs to communicate with its peers, with mobile apps, and with third-party platforms. From a fintech startup in Bengaluru integrating with the UPI stack, to a logistics conglomerate in Chennai orchestrating warehousing, fleet tracking, and billing across cloud providers, the API fabric has become the connective tissue of modern Indian enterprise IT.
This architectural shift has delivered genuine business value: faster deployments, independent scaling, technology flexibility. But it has also created a new and poorly understood attack surface. In 2025, API-targeted attacks accounted for a growing proportion of successful breaches globally — and Indian organisations, accelerating their digital transformation without always keeping pace on security posture, are acutely exposed.
Traditional network security thinking centred on the perimeter: keep the bad actors outside the firewall, and the assets inside are safe. APIs shatter this model. An API endpoint is, by design, externally reachable. It is intended to exchange data with authenticated callers — but “authenticated” is where things go wrong.
The Open Web Application Security Project publishes a dedicated API Security Top 10. In our assessment work across Indian enterprises, the most frequently exploited categories include:
/api/v2/orders/12345 — but the API does not verify that order 12345 belongs to that user. Attackers simply enumerate IDs to harvest other customers’ data. This single flaw was behind several large-scale data exposures in Indian e-commerce and fintech in the past two years.algorithm=none — allow session hijacking without credential theft.user to admin.In a monolith, there is one application to secure. In a microservices architecture, an enterprise might have 50 to 200 services, each with its own API, its own authentication logic (or lack thereof), and its own deployment lifecycle. The security team rarely has visibility into all of them simultaneously.
East-west traffic — service-to-service communication inside the cluster — is particularly dangerous. Internal APIs are often assumed to be trusted and left unauthenticated. An attacker who compromises one microservice can then pivot laterally across the entire estate using those unauthenticated internal calls. This is precisely the pattern seen in several high-profile supply-chain attacks: an attacker gains a foothold in a lower-trust peripheral service, then traverses internal APIs to reach core systems containing financial records or customer PII.
Shadow APIs — endpoints that exist in production but are not documented in any API inventory — are endemic in organisations that have grown through acquisitions, rapid development cycles, or team turnover. A legacy microservice deployed three years ago, forgotten but still running, still exposed, still holding data. Security teams cannot protect what they cannot see.
The RBI’s digital payment security controls and the CERT-In guidelines both implicitly require organisations to maintain an accurate inventory of their data-handling systems. Shadow APIs are a direct compliance gap as much as a security one.
India’s Digital Personal Data Protection Act (DPDP Act) places obligations on data fiduciaries to implement “reasonable security safeguards” for personal data. For organisations whose APIs handle personal data — which, in practice, means almost every B2C API and many B2B ones — this translates to a concrete requirement to secure those endpoints against unauthorised access and data leakage.
CERT-In’s 2022 directions impose a six-hour breach reporting obligation. The challenge: API breaches are frequently quiet. There is no ransomware note, no encrypted filesystem, no obvious operational disruption. Data may be exfiltrated over days or weeks through slow-and-low API enumeration. Without active API traffic monitoring and anomaly detection, organisations simply do not know they have been breached — and cannot report within six hours what they do not know has happened.
The gap between a silent API breach occurring and an organisation detecting it is measured in weeks in the absence of dedicated API security monitoring. By the time the breach surfaces — often through a threat intelligence tip or a researcher’s disclosure — the CERT-In six-hour window is long closed.
All external API traffic should traverse a dedicated API gateway — not just as a routing layer, but as the primary enforcement point for authentication, authorisation, rate limiting, and payload inspection. FortiGate’s application control and deep packet inspection capabilities can be positioned upstream of the API gateway to add network-level threat filtering for known malicious signatures and anomalous traffic patterns.
Every API call — including internal east-west service calls — should be authenticated. For external APIs, OAuth 2.0 with PKCE and short-lived access tokens (15-minute expiry) dramatically reduces the blast radius of a stolen credential. For service-to-service calls, mutual TLS (mTLS) with certificate rotation provides cryptographic verification that both parties are who they claim to be. This is not optional in a Zero Trust architecture — it is the baseline.
You cannot secure what you cannot see. Organisations should maintain a live, continuously updated API inventory generated from actual traffic analysis — not just from developer-submitted documentation. Discrepancies between the declared inventory and observed traffic reveal shadow APIs immediately.
Static security testing (DAST, SAST) finds known vulnerability patterns at build time. Runtime detection catches the novel attacks and the abuse of legitimate functionality — the legitimate user account scraping 50,000 records at 3 AM, the authenticated session performing actions inconsistent with its historical profile. ML-based anomaly detection on API traffic patterns is now essential, not aspirational.
API keys, database credentials, and service tokens embedded in container images, environment variables, or source code repositories are a persistent and easily exploited vulnerability. Centralised secrets management — with rotation policies and audit trails — eliminates this class of exposure.
API security does not exist in isolation from the broader security operations posture. Detecting an API abuse campaign, correlating it with network-level indicators, and responding within the CERT-In six-hour window requires that all these data streams converge in one operational view — and that the response can be automated. This is the operational problem that PrahiX Ora, a unified SecOps platform built by PrahiX Tech Pvt Ltd, is designed to solve. PJ Networks is the primary field deployment and operations partner for Ora, and we deploy and operate it for clients across their security operations environments.
SIEM — Log Ingestion and Attack Storyline Reconstruction: Ora’s SIEM ingests log and event data from API gateways, microservice infrastructure, FortiGate firewalls, cloud WAFs, and identity providers simultaneously. Correlation rules mapped to the MITRE ATT&CK framework flag API-specific techniques — credential stuffing attempts map to T1110, excessive data exposure to T1530, and lateral movement through internal APIs to T0886. The graph-based attack storyline engine reconstructs the full sequence of attacker actions across multiple services into a single, navigable investigation view rather than a flood of individual alerts. For CERT-In compliance, Ora’s tiered log retention — hot, cold, and archive tiers — supports the 180-day in-country log retention direction, keeping logs accessible for forensic investigation without prohibitive storage costs.
NMS — Network Observability for API-Bearing Infrastructure: Microservices run on complex infrastructure: Kubernetes clusters, SD-WAN links, multi-vendor switches and load balancers. Ora’s NMS provides unified observability across all of it — LLDP/CDP topology discovery maps the physical and logical path every API call traverses, while network path tracing identifies where latency or packet loss is occurring. ML-based anomaly detection identifies traffic pattern shifts that may indicate API abuse at the network layer — before the application-layer alert fires. For NOC teams managing multi-vendor estates where visibility has historically been fragmented across vendor-specific tools, this convergence is operationally transformative.
Video Surveillance (VMS) — Physical and Network Security Under One Roof: For manufacturing clients, retail chains, and multi-site enterprises, physical security incidents often correlate with cyber incidents — after-hours physical access to server rooms, for instance. Ora’s video surveillance (VMS) module manages ONVIF/Hikvision/Dahua cameras with video analytics, bringing physical and network security event timelines into the same operational dashboard. This unified view enables security operations to correlate a physical access event with an unusual after-hours API authentication attempt — connections that siloed tools would never surface.
SOAR — Automating the CERT-In Six-Hour Response: When the SIEM detects an API breach pattern, Ora’s SOAR module fires the appropriate playbook automatically. Pre-built connectors for FortiGate push updated blocklists within seconds of detection — the malicious IP is blocked at the network perimeter before a human analyst has reviewed the alert. Evidence collection for the CERT-In incident report begins automatically. CERT-In’s six-hour reporting window is realistic only when the evidence gathering and initial containment steps are automated; manual processes consistently fail this timeline in the real-world incidents we have responded to. Ora’s SOAR automation is what bridges the gap between detection and compliant reporting.
If your organisation is navigating API security in a complex microservices environment and needs to understand how Ora can support your detection and response posture, speak with our team at PJ Networks.
Use this as a starting framework for assessing your current posture:
API security is not a one-time project. It is a continuous discipline that must be embedded into development, operations, and security workflows simultaneously. For Indian enterprises accelerating their microservices adoption, the window to establish that discipline before a significant incident is narrowing.
PJ Networks works with enterprise IT and security leadership teams to assess API security posture, design gateway and monitoring architecture, and operate the round-the-clock detection and response capability that keeps pace with both the threat environment and India’s evolving regulatory requirements. Our FortiGate-anchored network security, 24/7 NOC/SOC operations, and Zero Trust Network Access (ZTNA) deployments are designed to work together with your API security controls — not as isolated point solutions.
If you are ready to understand where your API estate stands against the current threat landscape, our team is available to begin with a structured assessment. Reach out to PJ Networks to schedule a conversation.