- Join Our Company
- Email: sanjay@pjnetworks.com
- Phone: +91-9818361787
India’s digital economy has exploded. UPI crossed 18 billion transactions in a single month in 2024. Open banking mandates are expanding under RBI guidelines, and enterprise back-ends are wiring up to payment gateways, GST portals, ONDC, and third-party SaaS platforms through a web of APIs. The attack surface has kept pace. API-related security incidents are now the fastest-growing category in application security, and Indian enterprises — from fintech to manufacturing to healthcare — are increasingly in the crosshairs.
This post looks at why API security has become a board-level conversation in India, what the most common attack patterns look like in practice, and what a structured defence programme should contain.
Ten years ago, a firm’s security perimeter was relatively well-defined: a firewall at the edge, a DMZ for public-facing servers, and an internal network that was broadly trusted. That model has collapsed. Modern enterprise architecture exposes dozens — sometimes hundreds — of API endpoints to partners, mobile apps, customers, and cloud services. Each endpoint is a potential entry point.
The problem is compounded by how APIs are built and deployed today:
These are not hypothetical. Indian financial institutions have experienced real incidents where attackers iterated through account numbers in REST calls to harvest balances and PII. CERT-In advisories have documented API abuse patterns across banking and e-commerce sectors in recent years.
India’s regulatory environment is tightening around data and incident disclosure in ways that directly affect API security posture.
The Digital Personal Data Protection Act requires data fiduciaries to implement “reasonable security safeguards” and report personal data breaches to the Data Protection Board within prescribed timelines. APIs that expose personal data — names, phone numbers, financial details, health records — must be included in the scope of any Data Protection Impact Assessment. A breach that originates through an API endpoint carrying personal data is a notifiable event under DPDP. Organisations that cannot quickly trace the data lineage of an incident will struggle to comply with mandatory notification timelines. Importantly, having robust API security controls in place supports compliance with DPDP requirements — it does not guarantee it, but it provides strong evidence that reasonable safeguards were in place.
CERT-In’s 2022 directions mandate reporting of cyber incidents within six hours of detection. API breaches — particularly those affecting authentication infrastructure, data pipelines, or financial services — fall squarely within the reportable incident categories. The six-hour window is tight. Without automated detection and a pre-built response playbook, most security teams will miss it. Organisations that have tested this scenario in a tabletop exercise are far better positioned than those relying on manual triage.
RBI’s Master Direction on IT governance for regulated entities explicitly calls out the need to secure interfaces between systems. Open banking participants — banks, payment aggregators, fintechs — are expected to implement API gateway controls, OAuth 2.0-based authorisation, and continuous monitoring as part of their baseline security posture.
The OWASP API Security Top 10 (2023 edition) provides the clearest framework for understanding API risk. These are the entries most relevant to Indian enterprises right now:
An authenticated user can access another user’s data by changing an object identifier in the API call. In a lending or UPI-adjacent context, this could mean account takeover or large-scale PII exposure. The fix is to enforce object ownership checks server-side on every request, not only at the session authentication layer.
Weak token management, missing expiry on JWT tokens, and refresh token reuse vulnerabilities are common in India’s mobile-first applications, which frequently implement custom authentication flows rather than vetted OAuth 2.0 / OIDC libraries. Short-lived access tokens with refresh token rotation are the minimum viable control.
Administrative or privileged API functions accessible to low-privilege users due to missing role checks. Attackers enumerate endpoint patterns and attempt access to admin functions. Every endpoint must have a role-enforcement assertion before any business logic executes.
APIs without rate limiting or query complexity limits are vulnerable to resource exhaustion and credential-stuffing at scale. A single attacker running automated scripts can hammer a login API thousands of times per minute. Per-user and per-IP rate limits at the API gateway — combined with step-up authentication on repeated failure — are the practical controls here.
Binding client-supplied JSON properties directly to internal model objects allows attackers to set fields they should not control — for instance, elevating their own privilege level in a user update call. Explicit allowlists of settable properties for every endpoint prevent this class of attack.
Organisations that want to move from reactive incident response to proactive API security need a programme, not a point tool. Here is a practical framework adapted for the Indian enterprise context:
You cannot protect what you do not know exists. Crawl your API gateways, service meshes, and load-balancer configurations. Classify each endpoint by data sensitivity — does it process financial data, personal data, authentication credentials? Review the inventory every quarter and after every significant deployment. Shadow APIs discovered during a breach audit are always embarrassing; discovering them proactively is not.
Every internal and external API should have a machine-readable specification in OpenAPI/Swagger format. These specs enable automated schema validation, documentation generation, and security testing. Make it a gate in your CI/CD pipeline: a merge request that changes API behaviour without updating the spec does not ship.
A centralised API gateway is the enforcement point for authentication, rate limiting, IP allowlisting, and TLS termination. It also provides centralised logging — critical for CERT-In compliance. Backend services should not be directly internet-reachable; all external API traffic should route through the gateway. FortiGate’s application control and FortiWeb provide this layer for organisations already in the Fortinet ecosystem.
Internal microservice communication often relies only on bearer tokens that can be stolen and replayed. Mutual TLS — where both client and server present certificates — is the appropriate control for high-sensitivity internal APIs, particularly those handling payment processing or identity data.
DAST tools capable of consuming OpenAPI specs to generate and fire security tests should run in your CI/CD pipeline against a staging environment. Test for BOLA, mass assignment, and authentication bypass as part of every release cycle. Annual penetration testing alone is not sufficient given the pace of API deployment in modern development teams.
Production API monitoring goes beyond infrastructure uptime. Look for sudden spikes in 4xx errors (enumeration attacks), unusual geographic distribution in API calls, abnormal response payload sizes (data harvesting), and credential reuse across accounts (stuffing campaigns). Correlating API gateway logs with your SIEM to catch multi-stage attacks that look normal at the API layer but reveal a pattern across time is where real detection capability lives.
Run a tabletop scenario: an attacker has been iterating through customer IDs for 48 hours before detection. What data was accessed? Who must be notified? What is the CERT-In reporting timeline? How do you revoke compromised tokens without a broader service outage? Running this before the incident occurs is what makes the six-hour CERT-In window achievable in practice.
Many Indian enterprises consume third-party APIs — payment gateways, logistics platforms, GST filing services. Each is an implicit extension of your attack surface. Maintain a registry of third-party APIs, review their security attestations annually, and ensure that any outbound API call carrying personal data is covered by a data processing agreement aligned with DPDP requirements.
Detecting and responding to API security incidents at the speed CERT-In demands requires tooling that connects events across your environment into coherent attack stories. PrahiX Ora is a unified SecOps platform built by PrahiX Tech Pvt Ltd; PJ Networks is its primary field deployment and operations partner, operating the platform for enterprise clients across sectors in India.
SIEM — correlating API events at scale: API gateways, WAFs, identity providers, and application logs all generate events in isolation. Ora’s SIEM ingests these from multiple sources simultaneously, applying correlation rules mapped to MITRE ATT&CK — including techniques directly relevant to API abuse such as Credential Access via Brute Force and large-scale data collection. When an enumeration attack crosses a detection threshold, Ora’s graph-based attack storyline reconstruction connects authentication events, resource-access patterns, and lateral movement into a single visual timeline, compressing the analyst’s triage time significantly. For Indian enterprises, CERT-In’s direction on 180-day in-country log retention is addressed through tiered hot/cold/archive storage — recent events remain instantly queryable while older data is retained cost-efficiently on-shore.
NMS — full-stack observability under one pane: In environments where API traffic traverses multiple network layers — load balancers, API gateways, container clusters, and SD-WAN links — fragmented NOC tools produce fragmented visibility. Ora’s NMS provides unified observability across firewalls, switches, access points, and WAN/SD-WAN links, with LLDP/CDP topology discovery and network path tracing. ML-based anomaly detection flags unusual traffic patterns at the network layer that could signal an API abuse campaign before application-layer alerts fire — a particular advantage in multi-vendor estates where no single vendor’s native tool sees the full picture.
Video Surveillance (VMS) — physical and digital security converged: For manufacturing, retail, and multi-site enterprises, physical and network security incidents frequently co-occur. Ora’s video surveillance (VMS) pillar manages ONVIF/Hikvision/Dahua cameras with video analytics, giving operations teams a single platform for physical access events and network security events. A server-room intrusion that precedes a credential theft attempt appears in the same operational view as the network anomaly — context that standalone tools would never surface together.
SOAR — making CERT-In’s six-hour window realistic: The six-hour incident reporting window CERT-In mandates is not achievable through manual workflows when a complex API breach has occurred across multiple systems. Ora’s SOAR pillar provides playbook automation with pre-built connectors and automated response actions — including pushing updated blocklists directly to FortiGate firewalls. When an API enumeration attack is confirmed, a SOAR playbook can automatically block offending IP ranges at the FortiGate level, collect and package evidence artefacts, and draft the incident notification — completing the mechanical work within minutes so analysts focus on review and judgment rather than assembly. That is what makes six hours realistic.
If your security operations team is currently working across disconnected tools — a siloed SIEM, manual NOC dashboards, no SOAR automation — Ora’s convergence across these four pillars is worth exploring as a consolidated foundation. Talk to PJ Networks about an Ora deployment assessment for your environment.
API security sits at the intersection of application development, network security, and compliance — and most enterprise security teams are stretched across all three simultaneously. PJ Networks’ managed security practice brings FortiGate and Fortinet expertise, 24/7 NOC/SOC operations, and ZTNA architecture experience to bear on this problem space directly.
Our engagements typically combine API gateway hardening through FortiGate policy configuration, continuous SIEM-based monitoring through the PrahiX Ora platform, and a CERT-In-aligned incident response capability that means a 3 a.m. API breach does not depend on a single on-call analyst. We work with Indian enterprises across BFSI, manufacturing, healthcare, and logistics to build security programmes that keep pace with the digital expansion India’s economy demands.
If your organisation is expanding its API surface — through open banking, ONDC integration, or SaaS adoption — and you want an independent assessment of your current API security posture, get in touch with PJ Networks.
PJ Networks Managed Security Services: FortiGate NGFW management, 24/7 NOC/SOC, ZTNA deployment, FortiMail, SD-WAN, MSSP — India-focused, enterprise-grade. pjnetworks.com