API Security for Indian Enterprises: Protecting the Attack Surface You Can’t See

• 17 August, 2026
• No Comments

Modern Indian enterprises are running hundreds of APIs — internal microservices, partner integrations, mobile backends, payment gateways, cloud SaaS connectors. Every one of those endpoints is a potential entry point. Yet most organisations still treat API security as an afterthought: a checkbox in the application review cycle, or a WAF rule added after the first incident.

That gap is costing enterprises dearly. According to Gartner, APIs have overtaken web applications as the most frequent attack vector for enterprise breaches — and in the Indian context, with DPDP Act enforcement and CERT-In’s 6-hour reporting mandate now live, an API breach doesn’t just mean data loss. It means regulatory exposure, board-level scrutiny, and a tight deadline to disclose.

This guide walks through the most common API attack patterns, the controls that actually stop them, and how a managed security partner with 24/7 coverage closes the gap between detection and response.

Why API Security Deserves Its Own Threat Model

APIs are not just “another web application.” They have fundamentally different attack surfaces:

• Authentication sprawl: REST APIs often rely on JWT tokens, OAuth 2.0 flows, or API keys — each with their own misconfiguration risks.
• Verbose error messages: Poorly configured APIs leak schema details, internal service names, and stack traces that map the backend for an attacker.
• Excessive data exposure: Many APIs return full objects and let the client filter — attackers bypass client-side filtering trivially.
• Broken object-level authorisation (BOLA/IDOR): Consistently the #1 issue in the OWASP API Security Top 10, where one user ID can be swapped for another to access someone else’s data.
• Mass assignment: Accepting all JSON fields without allowlisting lets attackers escalate privileges or modify fields they should never touch.
• Shadow APIs: APIs deployed by a development team, never catalogued in the API gateway, invisible to security scanning — and often publicly reachable.

For Indian enterprises operating under the Digital Personal Data Protection (DPDP) Act, 2023, many of these API flaws directly translate to a personal-data breach — invoking the obligation to report to the Data Protection Board and, under CERT-In directions, to notify CERT-In within six hours of becoming aware.

The OWASP API Security Top 10 in the Indian Enterprise Context

The OWASP API Security Top 10 (2023 edition) is the most widely referenced framework for API threat modelling. Here is how each category manifests in the Indian enterprise environment:

BOLA — Broken Object Level Authorisation

An attacker increments a customer ID in the URL: /api/v1/accounts/10043 becomes /api/v1/accounts/10044. Without per-object authorisation checks at the API layer, they retrieve another customer’s account data. In a banking or insurance API, this is a DPDP breach on the first successful request.

Broken Authentication

Expired JWT tokens still accepted; API keys embedded in mobile apps; OAuth refresh tokens that never expire. Indian fintech and e-commerce environments have all three in production right now. Threat actors scrape APK files for hardcoded keys within hours of a new app release.

Broken Object Property Level Authorisation (BOPLA)

A user update endpoint accepts {"role": "admin"} because the backend blindly maps the request body to the user model. This is mass-assignment — and it is trivially easy to test for with a single extra field.

Unrestricted Resource Consumption

No rate limits on authentication endpoints means credential stuffing at scale. No payload size limits on file upload APIs means storage exhaustion. In a multi-tenant SaaS environment, one abusive tenant can degrade service for all others — a subtle but real denial-of-service vector.

Broken Function Level Authorisation

Administrative functions reachable at /api/v1/admin/users/delete without additional role validation at the route handler. Attackers enumerate common admin path patterns; automated scanners find these within minutes on an internet-facing API.

Server-Side Request Forgery (SSRF) via API

An API that fetches a URL on behalf of the client — for image rendering, webhook delivery, or URL preview — can be coerced into reaching internal services: the cloud metadata endpoint at 169.254.169.254, internal Kubernetes dashboards, or Redis without authentication. SSRF was the attack vector in several high-profile cloud breaches.

Detection: What You Cannot See Without the Right Tooling

Traditional perimeter security — firewall ACLs, IPS signatures — was designed for protocol-level threats. API attacks live in the application layer: a valid HTTPS request with a legitimate JWT, perfectly formatted JSON, and a one-character change in the object ID.

Effective API security detection requires:

• API inventory and schema enforcement: You cannot protect an API you do not know exists. An API gateway or WAF that auto-discovers endpoints and compares traffic against the OpenAPI/Swagger schema flags requests that violate expected structure.
• Behavioural baselining: A user who normally calls /api/v1/orders fifty times a day, then suddenly calls it 50,000 times overnight, is either running an automated script or has had their token stolen. ML-based anomaly detection catches this; threshold-based rules miss the slow-burn enumeration.
• Lateral movement correlation: API abuse rarely ends at the API. Attackers pivot: stolen API credentials become AWS console access; a compromised service account reaches an internal database. Log correlation across the API gateway, cloud trail, and SIEM is what connects the dots.
• Bot traffic fingerprinting: Credential stuffing and BOLA enumeration are driven by bots. Distinguishing bot traffic from human traffic at the API layer — without a browser to challenge — requires TLS fingerprinting, request timing analysis, and header consistency checks.

Control Framework: Eight Controls That Actually Matter

For Indian enterprise CISOs building or auditing an API security programme, these eight controls address the majority of real-world API attack scenarios:

1. Centralise API traffic through a gateway: Every API — internal and external — should route through a gateway that enforces authentication, rate limiting, and schema validation. Shadow APIs bypass all controls; discovery and centralisation must come first.
2. Implement per-object authorisation at the service layer: Do not rely on the API gateway for BOLA protection. The authorisation check must happen inside the service, against the requesting user’s permissions, before the data is retrieved.
3. Enforce token lifetimes aggressively: Access tokens: 15 minutes. Refresh tokens: 24 hours maximum, rotated on use. API keys: rotate every 90 days, alert on first use from a new IP or ASN.
4. Allowlist request properties: Explicitly define which fields are accepted in each request. Reject and log any request containing unexpected fields — this catches mass-assignment attacks before they reach the ORM.
5. Rate limit by identity, not just IP: IP-based rate limiting is defeated by residential proxy networks. Rate limit by authenticated user identity or API key, with graduated responses: slow-down headers before outright blocking.
6. Block SSRF at the egress layer: Maintain a deny-list of private IP ranges (RFC 1918), link-local addresses (169.254.0.0/16), and cloud metadata endpoints. All outbound HTTP from API services should route through a forward proxy that enforces this list.
7. Log everything, retain for 180 days in-country: CERT-In’s direction requires logs to be retained for 180 days and stored within India. API gateway access logs, authentication events, and error responses should all flow into the SIEM under this retention policy.
8. Run continuous API security scanning: Static DAST scanning catches known vulnerability patterns. Complement it with continuous, traffic-replay-based testing that uses real production request patterns — this finds business-logic flaws that generic scanners miss.

The CERT-In 6-Hour Clock: Why Automation Is Not Optional

When CERT-In’s April 2022 directions came into effect, the requirement that caught most organisations off-guard was not the 180-day log retention — it was the 6-hour incident reporting window.

Six hours from detection to formal report is operationally brutal without automation. Consider the realistic timeline in a manual process:

• Alert fires in SIEM: T+0
• On-call analyst acknowledges and triages: T+20 min
• Escalation to senior analyst for API breach classification: T+45 min
• Investigation to confirm scope (which APIs, which users, what data): T+2.5 hours
• Drafting the CERT-In report with all required fields: T+4 hours
• Legal and management review: T+5.5 hours
• Submission: T+5:55 hours — made the deadline by five minutes

That assumes everything goes right: the right person answers the pager, the logs are complete, the scope is bounded. If any of those fail, you miss the window — and that is a compliance violation on top of the breach itself.

Playbook automation changes this. A confirmed API breach alert can automatically: pull the full log window, run the scope assessment query, populate the CERT-In report template with all known fields, and notify the designated point of contact for review. The human adds context and approves; the automation handles the mechanical work. The 6-hour deadline becomes achievable.

PrahiX Ora: Unified SecOps for the API Security Lifecycle

Managing API security across a large enterprise estate — dozens of gateways, hundreds of microservices, multiple cloud environments — requires a platform that unifies visibility, detection, and response. The platform we deploy and operate for clients is PrahiX Ora, built by PrahiX Tech Pvt Ltd, a unified SecOps platform covering four interlocking capabilities.

SIEM — Context-Aware Log Correlation: Ora’s SIEM ingests API gateway logs, cloud trail events, authentication records, and application error streams through multi-source connectors. Correlation rules mapped to MITRE ATT&CK tactics flag the patterns that indicate API abuse — BOLA enumeration shows up as a T1087 (Account Discovery) chain; credential stuffing maps to T1110 (Brute Force). Graph-based attack storyline reconstruction connects the API authentication event to the downstream lateral movement attempt, giving analysts a complete picture rather than isolated alerts. Tiered log retention (hot/cold/archive) directly supports CERT-In’s 180-day in-country log retention direction — logs stay in India, accessible for investigations without retrieval delays.

NMS — Observability Across the API Infrastructure: APIs run on infrastructure — firewalls, load balancers, application servers, SD-WAN links. Ora’s NMS provides unified observability across this full stack, with LLDP/CDP topology discovery that maps how traffic actually flows from the internet to the API service. ML-based anomaly detection on network metrics catches the traffic volume spikes that accompany API enumeration attacks — often before the SIEM alert fires. For enterprises running multi-vendor estates (FortiGate at the edge, Cisco internally, a cloud-native load balancer in front of the API layer), this unified view replaces fragmented NOC consoles with a single operational picture.

Video Surveillance (VMS) — Physical and Digital Under One View: For manufacturing, retail, and multi-site enterprises, Ora’s video surveillance (VMS) module — managing ONVIF, Hikvision, and Dahua camera infrastructure with video analytics — brings physical security into the same operational dashboard as network and security telemetry. An API breach that involves an insider threat has a physical dimension: badge access logs, camera footage, and network events can now be correlated in a single investigation workflow rather than across separate siloed systems.

SOAR — Automated Response That Makes 6-Hour Reporting Realistic: Ora’s SOAR engine provides the playbook automation that turns the CERT-In 6-hour window from a theoretical target into an operational reality. Pre-built connectors include direct integration with FortiGate, allowing an automated response action to push a blocklist entry to the firewall within seconds of a confirmed threat indicator — no manual CLI access required. For API security incidents specifically, automated playbooks can isolate a compromised API key, revoke associated tokens, pull the full API access log for the affected endpoints, and pre-populate the CERT-In incident report template — all within the first 30 minutes of a confirmed alert.

If you are building or expanding your API security programme and want to understand how PrahiX Ora fits your environment, we are happy to walk through a capability assessment.

Incident Response: The First 60 Minutes After an API Breach

No control framework eliminates all risk. When an API breach occurs, the first 60 minutes determine the blast radius. Here is a practical runbook:

Minutes 0-10: Confirm and Contain

• Confirm the alert is not a false positive: review the raw API logs for the suspicious pattern.
• Revoke or rotate the compromised credential immediately (API key, OAuth token, service account).
• If BOLA is confirmed, restrict access to the affected endpoint at the API gateway — return 503 rather than data while investigation proceeds.

Minutes 10-30: Scope Assessment

• Query the SIEM for all requests using the compromised credential over the past 30 days.
• Identify which data objects were accessed: user IDs, account numbers, transaction records.
• Determine if the attacker pivoted: look for authentication events from the same source IP against other services.

Minutes 30-60: Notification Preparation

• If personal data is involved: activate the DPDP Act breach notification workflow.
• Begin populating the CERT-In incident report template (mandatory fields: incident type, affected systems, data categories, estimated scope).
• Notify legal, DPO, and management — they need time to review before the 6-hour deadline.

Building an API Security Roadmap for 2025-26

Indian enterprises typically have three to five years of API development behind them before they implement a formal API security programme. The backlog of undocumented, unscanned, ungoverned APIs is real. A pragmatic roadmap:

Quarter 1: Discover and Inventory

Deploy an API discovery tool — either through the API gateway or via network traffic analysis. The goal is a complete, maintained API inventory: endpoint, owner, data classification, authentication method, last security review date. Prioritise internet-facing APIs handling personal data for immediate remediation.

Quarter 2: Baseline and Monitor

Connect API gateway logs to the SIEM. Implement behavioural baselining. Deploy rate limiting and token lifetime enforcement on all production APIs. Run an automated DAST scan against the full API inventory — triage and remediate critical findings.

Quarter 3: Automate Response

Build and test SOAR playbooks for the top three API attack scenarios in your environment (typically: credential stuffing, BOLA enumeration, and abnormal data export). Verify the CERT-In 6-hour reporting workflow end-to-end with a tabletop exercise.

Quarter 4: Continuous Improvement

Review API security metrics quarterly: mean time to detect, mean time to contain, number of shadow APIs discovered, percentage of APIs with current security assessments. Feed findings back into the development pipeline — shift-left training for API developers, API security requirements in the SDLC checklist.

How PJ Networks Can Help

PJ Networks delivers 24/7 managed security operations for Indian enterprises — FortiGate NGFW management, NOC/SOC services, ZTNA deployment, and MSSP engagements. Our API security practice covers:

• API security posture assessment: Discovery, inventory, and gap analysis against the OWASP API Security Top 10.
• FortiGate API protection: Configuring FortiGate’s WAF and application control policies to protect API endpoints at the perimeter.
• 24/7 SOC monitoring: API gateway log ingestion, behavioural baselining, and alert triage by analysts who understand the API attack surface.
• CERT-In response support: Playbook-driven incident response that makes the 6-hour reporting window achievable.
• DPDP Act compliance support: Helping evidence that your API security controls support compliance with India’s data protection framework.

If your organisation is concerned about API security exposure — especially with internet-facing APIs handling customer data — reach out to PJ Networks for a no-obligation discussion. We work with Indian enterprises across BFSI, manufacturing, healthcare, and technology sectors.