API Security in Indian Enterprises: Why Your Perimeter Firewall Is Not Enough

  • Home
  • API Security in Indian Enterprises: Why Your Perimeter Firewall Is Not Enough
API Security in Indian Enterprises: Why Your Perimeter Firewall Is Not Enough
API Security in Indian Enterprises: Why Your Perimeter Firewall Is Not Enough
API Security in Indian Enterprises: Why Your Perimeter Firewall Is Not Enough
API Security in Indian Enterprises: Why Your Perimeter Firewall Is Not Enough
API Security in Indian Enterprises: Why Your Perimeter Firewall Is Not Enough

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.

The API Attack Surface: What Indian IT Leaders Need to Understand

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:

  • Undocumented or “shadow” APIs — spun up by development teams and never formally inventoried by the security team.
  • Excessively permissive — returning far more data than the calling application actually needs, a pattern known as Excessive Data Exposure (OWASP API Top 10, A3).
  • Weakly authenticated — relying on API keys embedded in mobile apps or environment variables, where rotation policies are informal or nonexistent.
  • Invisible to the firewall — because the traffic is valid HTTPS on port 443, a next-generation firewall passes it without inspection unless purpose-built API policies are applied.

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.

Real-World Attack Patterns Targeting Indian Enterprises

The threat is not hypothetical. Security researchers and incident responders in India have documented several recurring API attack patterns in recent years:

Broken Object Level Authorisation (BOLA)

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.

Credential Stuffing via Login APIs

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.

Mass Assignment Attacks

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.

Third-Party and Partner API Risk

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.

Why Traditional Perimeter Security Falls Short

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:

  • Traffic is encrypted (TLS/HTTPS), so deep-packet inspection cannot see payload content without SSL inspection—which introduces its own complexity and latency.
  • API calls look like legitimate web traffic. A firewall rule that allows port 443 to your public API endpoint cannot distinguish a valid developer query from a BOLA attack that leaks customer PII.
  • APIs are stateless by design. Each request carries its own auth token. There is no concept of “session” for the firewall to track.
  • Business-logic flaws are invisible to signature-based security. No CVE exists for “your API returns more records than the user is entitled to.”

What enterprises need is a layered approach that pairs the perimeter firewall with purpose-built API visibility, anomaly detection, and response automation.

A Practical API Security Framework for Indian Enterprises

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:

1. Discover and Inventory All APIs

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).

2. Enforce Authentication and Authorisation Rigorously

  • Adopt OAuth 2.0 with short-lived access tokens (15–30 minutes) and rotation policies for refresh tokens.
  • Implement object-level authorisation checks server-side—never trust client-supplied IDs without backend validation against the authenticated user’s entitlements.
  • Eliminate embedded API keys in mobile apps; use certificate-pinning and runtime secret injection instead.

3. Rate Limit and Throttle at the API Gateway

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).

4. Instrument API Traffic for Anomaly Detection

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.

5. Test APIs in the SDLC, Not Just at Go-Live

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.

6. Establish Incident Response Runbooks for API Breaches

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.

DPDP Act Implications for API-Exposed Personal Data

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:

  • Data Minimisation: APIs must return only the data necessary for the stated purpose. An API that returns a full user record when only a name and account number are needed violates the minimisation principle and creates unnecessary exposure.
  • Purpose Limitation: If an internal analytics API uses production customer data without explicit consent provisions, this raises DPDP compliance questions.
  • Data Fiduciary Accountability: If a third-party API integration leaks personal data, the data fiduciary (your organisation) remains accountable. Contractual obligations with API partners must reflect this.
  • Breach Notification: An API breach that exposes personal data of Indian residents triggers DPDP Act notification obligations—timelines and format are still being finalised by the Data Protection Board, but aligning with CERT-In’s 6-hour window is the safest posture.

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.

How PrahiX Ora Supports API Security Operations

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.

Building Internal Capability: What Your Team Should Do This Quarter

Executive awareness alone does not reduce API risk. Here is a concrete 90-day action plan for enterprise IT and security teams:

  • Week 1–2: Commission an API discovery exercise. Output: a spreadsheet of every known API endpoint, authentication method, and data classification.
  • Week 3–4: Review top-10 highest-traffic APIs against OWASP API Top 10. Prioritise: are object-level authorisation checks server-side? Is there rate limiting on login endpoints?
  • Month 2: Integrate API gateway logs into your SIEM. Build three detection rules: sequential ID enumeration, spike in 4xx errors, and off-hours API calls from new geolocations.
  • Month 3: Run a tabletop exercise simulating an API breach with a 6-hour CERT-In reporting obligation. Identify gaps in your runbook and assign owners.
  • Ongoing: Add OWASP API Security Top 10 testing to your CI/CD pipeline and schedule quarterly API penetration tests aligned with your audit calendar.

Conclusion: APIs Demand Deliberate Security Investment

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.

Leave a Reply

Your email address will not be published. Required fields are marked *