



Application Programming Interfaces (APIs) are the invisible connective tissue of modern Indian enterprise IT. They power mobile banking apps, GST filing portals, ERP integrations, IoT sensor feeds, and the hundreds of SaaS tools that Indian CISOs now have to govern. Yet in boardroom conversations about cybersecurity budgets, API security still sits far below firewalls, endpoint detection, and SIEM in the priority queue.
That needs to change—and fast. According to Gartner, APIs have overtaken web applications as the most-targeted attack surface for data breaches. In the Indian context, where digital transformation has accelerated at a pace that frequently outstrips security architecture, this is not a theoretical risk; it is an active, daily threat that every enterprise with a digital presence needs to address.
Every enterprise today operates hundreds—sometimes thousands—of APIs. Some are customer-facing (mobile apps, partner portals). Others are internal: microservices talking to each other, legacy systems wrapped with REST interfaces for modernisation, HR platforms pulling data from identity directories. The problem is that many of these APIs are:
This last point is critical: your FortiGate NGFW blocks known-bad signatures and enforces zone policies, but it was not designed to understand the business logic of your internal payments API. An attacker who obtains a valid OAuth token can walk straight through your perimeter firewall and query sensitive endpoints indefinitely—unless you have compensating controls.
The threat is not hypothetical. Security researchers and incident responders in India have documented several recurring API attack patterns in recent years:
An attacker with a legitimate account changes an ID in the API request path—say, replacing /api/v1/accounts/12345 with /api/v1/accounts/12346—and the API returns another user’s data because the backend trusts the client to request only what it is entitled to. This is the number-one API vulnerability globally and is trivially exploitable in enterprise applications developed under time pressure.
Indian users frequently reuse passwords across platforms. Attackers purchase credential dumps from earlier breaches and hammer enterprise login APIs at scale. Unlike browser-based login forms, API endpoints often lack CAPTCHA, rate limiting, or lockout policies. Threat actors can test tens of thousands of credentials per hour against a mobile banking or HR self-service API before detection.
Modern APIs built with frameworks like Spring Boot or Express.js can automatically bind request body parameters to backend objects. If developers do not explicitly whitelist allowed fields, an attacker can POST a field like "is_admin": true and the framework will silently update the database record. This has led to privilege-escalation incidents in Indian fintech applications.
Supply-chain compromise via APIs is an underappreciated vector in India. Large enterprises rely on dozens of third-party APIs—logistics partners, payment gateways, government portals. A compromise of any one of them can expose your data even if your own environment is perfectly hardened. The CERT-In advisory ecosystem documents several incidents where the breach vector was a third-party integration, not the enterprise itself.
The standard enterprise defence stack—NGFW at the perimeter, IPS, URL filtering, email security—was designed for an era when applications sat inside the data centre and users sat inside the office. API-centric architectures break every assumption that stack was built on:
What enterprises need is a layered approach that pairs the perimeter firewall with purpose-built API visibility, anomaly detection, and response automation.
Building a mature API security posture does not require ripping out existing infrastructure. It requires layering capabilities onto what you already have. Here is a practical framework CISOs can present to their boards:
You cannot protect what you cannot see. Start with a full API discovery exercise: crawl web application traffic, parse API gateway logs, interrogate your CI/CD pipeline for OpenAPI/Swagger specs. The goal is a living inventory that includes endpoint URLs, authentication methods, data classification of payloads, and ownership (which team deployed it).
Every public-facing API endpoint should have rate limits keyed to the authenticated identity (not just IP address, which attackers rotate). Configure progressive throttling: warn at 80% of the limit, hard-block at 100%, and alert at 120% (which signals the limit is misconfigured or under attack).
API gateway logs should feed directly into your SIEM. Build detection rules for: unusual spike in 4xx errors (scanning), sequential ID enumeration, high-volume identical requests from a single token, and API calls outside business hours from unusual geolocations. These behavioural baselines cannot be set once and forgotten; they require continuous tuning as your API estate grows.
Shift API security left. Integrate OWASP API Security Top 10 checks into your CI/CD pipeline so that BOLA, Excessive Data Exposure, and Mass Assignment issues are caught before production. Many Indian enterprises still treat penetration testing as a checkbox done six months before an audit—that cadence is inadequate for a rapidly evolving API estate.
CERT-In’s 6-hour reporting window (applicable to all entities under the 2022 direction) applies to API-borne breaches as readily as to ransomware. Your incident response plan must include: automated token revocation procedures, evidence preservation of API gateway logs, rapid scope assessment (how many records were exposed), and a pre-drafted notification template. Without runbooks, the 6-hour window is nearly impossible to meet.
India’s Digital Personal Data Protection Act, 2023 introduces significant obligations for enterprises that process personal data—and APIs are frequently the channel through which that data flows. Under the DPDP Act:
CISOs should work with legal and compliance teams to map every API that touches personal data and ensure controls are proportionate to the sensitivity of that data.
Knowing where your APIs are exposed and what attacks look like is step one. Detecting and responding to those attacks in real time—especially within CERT-In’s 6-hour reporting window—requires operational tooling that most enterprises do not have standing up on their own. This is where the platform we deploy and operate for clients, PrahiX Ora (built by PrahiX Tech Pvt Ltd), becomes operationally relevant.
SIEM – Correlation Across API and Network Events: Ora’s SIEM ingests logs from API gateways (including FortiGate application control logs, WAF events, and cloud-native API management platforms), correlates them against MITRE ATT&CK techniques, and reconstructs attack storylines using graph-based analysis. When an attacker conducts a slow BOLA enumeration—sending one rogue request every few minutes to avoid rate-limit triggers—the graph engine connects the dots across hours of logs into a single campaign view. CERT-In’s direction on 180-day in-country log retention is addressed through Ora’s tiered hot/cold/archive retention architecture, keeping all evidence accessible within Indian jurisdiction.
NMS – Network Path Visibility: For enterprises with fragmented visibility across firewalls, switches, access points, and SD-WAN links, Ora’s Network Management System uses LLDP/CDP topology discovery and ML-based anomaly detection to surface unusual lateral movement that often precedes or follows an API compromise. When an attacker pivots from an exposed API to internal systems, the NMS component flags the anomalous traffic before it reaches critical assets.
Video Surveillance (VMS) – Unified Physical and Cyber View: For manufacturing, retail, and multi-site enterprises, Ora’s video surveillance (VMS) module brings ONVIF/Hikvision/Dahua camera management and video analytics into the same operations console as network and security events. This matters when an incident touches both physical access (a contractor badge-swipe at an unusual time) and a simultaneous API anomaly—operators see the full picture without switching consoles.
SOAR – Automated Response Within the 6-Hour Window: CERT-In’s 6-hour incident reporting obligation is achievable only with automation. Ora’s SOAR module includes pre-built playbooks for API-related incidents: automatically revoking compromised OAuth tokens, pushing dynamic blocklists to FortiGate (cutting off attacker IPs at the perimeter), isolating affected microservices, preserving API gateway log evidence for regulatory submission, and triggering the CERT-In notification workflow. What might take a team three to four hours of manual effort compresses into minutes, leaving room for human review and accurate reporting before the deadline.
If your organisation is evaluating whether a managed SecOps platform makes sense for your API security posture, reach out to PJ Networks for an initial assessment.
Executive awareness alone does not reduce API risk. Here is a concrete 90-day action plan for enterprise IT and security teams:
Indian enterprises have invested heavily in perimeter firewalls, endpoint detection, and email security over the last decade. These investments remain necessary. But the attack surface has shifted: APIs are now the primary interface between your business logic and the outside world, and they require deliberate, purpose-built security controls.
The good news is that API security is a solvable problem. Mature API gateway policies, rigorous authorisation enforcement, behavioural anomaly detection, and automated incident response can reduce API risk to manageable levels—without slowing down the digital transformation initiatives your business depends on.
PJ Networks works with Indian enterprise IT and security teams to design and operate layered security architectures that include API visibility, FortiGate-enforced perimeter controls, 24/7 NOC/SOC monitoring, and managed SecOps through the PrahiX Ora platform. If your organisation is ready to take API security seriously, contact our team for a no-obligation assessment.