API Security in 2025: Protecting the Attack Surface Indian Enterprises Overlook

• 14 September, 2026
• No Comments

When security teams map their attack surface, they almost always start with endpoints, servers, and perimeter firewalls. What they routinely underestimate — or miss entirely — is the API layer. In 2025, APIs are the connective tissue of every digital enterprise: between microservices, between SaaS platforms, between mobile apps and backends, between partners and supply chains. And they are being exploited at scale.

India’s rapid shift to digital-first operations — accelerated by UPI, ONDC, DigiLocker integrations, and cloud-native ERP rollouts — means Indian enterprises are now among the world’s most API-dependent. The attack surface has grown faster than most security programmes have adapted.

This post breaks down the real API threat landscape facing Indian organisations in 2025, maps it to the obligations introduced by the Digital Personal Data Protection (DPDP) Act and CERT-In directives, and explains how PJ Networks structures API security programmes to close the gap.

Why APIs Are the Attacker’s Preferred Door

APIs present a fundamentally different challenge compared to traditional web application threats. They expose structured, machine-readable interfaces designed for high-volume automated interaction — which is precisely what attackers exploit. The OWASP API Security Top 10 (updated 2023) catalogues the most prevalent risks:

• Broken Object Level Authorisation (BOLA): An attacker substitutes their own user ID with another user’s ID in an API call. The server returns that user’s data. No exploit code required — just a changed parameter. This class of vulnerability has been the root cause of several high-profile Indian fintech and healthcare data exposures.
• Broken Authentication: Weak token management, JWT algorithm confusion attacks, and missing session expiry policies allow attackers to impersonate legitimate users or escalate privileges.
• Excessive Data Exposure: APIs frequently return full data objects and rely on the client to filter what is displayed. Intercepting the response reveals fields the UI never shows — including Aadhaar-linked data, PAN numbers, and financial records in regulated sectors.
• Unrestricted Resource Consumption: Without rate limiting, attackers enumerate user accounts, scrape product catalogues, or conduct credential stuffing campaigns at no cost.
• Security Misconfiguration: Default API gateway settings, debug endpoints left enabled in production, and overly permissive CORS policies are common across enterprises that have grown their API estate organically.
• Mass Assignment: APIs that accept and bind arbitrary request fields can be manipulated to elevate user roles or modify protected object attributes.

Beyond the OWASP list, threat intelligence teams are tracking a surge in shadow API exploitation — undocumented endpoints that developers created for internal tools or third-party integrations but that were never formally inventoried, secured, or retired. According to public research, a typical mid-sized enterprise has 40-60% more API endpoints in production than its security team is aware of. Each undocumented endpoint is a potential entry point with no monitoring and no controls.

The Indian Regulatory Context: DPDP Act and CERT-In

India’s regulatory landscape now adds compliance pressure on top of technical risk.

DPDP Act, 2023 — API Implications

The Digital Personal Data Protection Act creates explicit obligations around how personal data is collected, stored, processed, and shared. APIs sit at the intersection of every one of these obligations:

• Purpose limitation: APIs that return personal data must serve a specific, documented purpose. APIs returning more data than the use case requires are directly non-compliant.
• Data minimisation: Response payloads should return only the minimum personal data necessary. Excessive data exposure vulnerabilities are now a regulatory issue, not just a technical one.
• Third-party sharing: Partner APIs and vendor integrations are a high-risk surface. Every external API consumer is effectively a data processor. The DPDP Act requires data fiduciaries to ensure their processors maintain equivalent protections — contractually and technically.
• Data breach notification: Any breach affecting personal data processed through APIs must be reported to the Data Protection Board. Inadequate API logging makes breach scoping extremely difficult and response timelines impossible to meet.

CERT-In Directions — API Logging and Incident Response

CERT-In’s April 2022 directions (updated subsequently) mandate that organisations maintain logs of all ICT systems for a rolling 180-day period, with logs retained in-country. For API-heavy architectures, this means:

• Every API call — including failed authentication attempts, parameter manipulation, and unusual access patterns — must be logged with sufficient fidelity to reconstruct an incident.
• The 6-hour incident reporting window means your security operations team needs to identify, scope, and report an API breach in under six hours from detection. Without automated correlation, that timeline is not achievable.
• Logs must be stored within Indian jurisdiction — a constraint that directly affects cloud-hosted API gateway log forwarding to foreign SIEMs.

Organisations that treat API security as a developer concern rather than a security operations concern will find themselves unable to meet these obligations under real incident conditions.

Common Gaps in Indian Enterprise API Security Programmes

Across engagements, PJ Networks’ security assessment teams consistently find the same categories of gap:

1. No API Inventory

Security cannot protect what it does not know exists. Most enterprises have a documented set of externally facing APIs but no complete inventory of internal, partner-facing, or legacy APIs. Shadow APIs — typically REST endpoints created by development teams for internal integrations and never formally registered — accumulate silently.

2. API Gateways Without Security Policies

Organisations invest in API gateway products (Kong, Apigee, AWS API Gateway, Azure APIM) but deploy them primarily for routing and rate limiting, not security enforcement. Authentication policy enforcement, input validation, and payload inspection rules are often absent or inconsistently applied across services.

3. No Runtime Visibility

Static scanning of API specifications (OpenAPI/Swagger) identifies known vulnerabilities in documentation — but not runtime behaviour. Attackers exploit the delta between what the spec says and what the API actually accepts. Without runtime traffic analysis, you cannot detect BOLA, business logic abuse, or scraping patterns.

4. Inadequate Log Fidelity

Access logs capture status codes and URLs but frequently omit request parameters, response sizes, user context, and error details — exactly the fields needed to reconstruct an attack chain or scope a breach for CERT-In reporting.

5. No API-Specific Incident Response Playbooks

General IR playbooks are not calibrated for API incidents. Isolating a compromised API endpoint, revoking affected tokens at scale, notifying impacted users (as DPDP requires), and re-testing the fixed endpoint before restoration each require specific procedures that most IR plans lack.

Building an API Security Programme: Practical Steps

Securing the API surface is a programme, not a point-in-time activity. The following steps reflect a phased approach PJ Networks recommends for Indian enterprise clients:

Phase 1 — Discover and Classify

• Deploy API traffic mirroring or a dedicated API discovery tool to identify all endpoints in production, including undocumented ones.
• Classify each API by data sensitivity (does it touch personal data as defined under DPDP?), authentication method, and external exposure.
• Retire deprecated endpoints. Every inactive endpoint still reachable in production is unnecessary risk.

Phase 2 — Enforce at the Gateway Layer

• Standardise authentication: OAuth 2.0 with short-lived access tokens, mTLS for machine-to-machine APIs, and API keys with IP allowlisting for partner integrations.
• Implement per-endpoint rate limiting calibrated to expected legitimate traffic patterns — not just global limits that fail to catch targeted enumeration.
• Enable schema validation: reject requests that do not conform to the published API schema before they reach application code.
• Apply response filtering at the gateway where possible to prevent excessive data exposure.

Phase 3 — Instrument and Monitor

• Ensure API access logs capture full request context: authenticated user/service identity, request parameters, response payload size, latency, and error codes.
• Forward API logs to your SIEM with sufficient retention to meet CERT-In’s 180-day requirement.
• Create baseline traffic profiles per endpoint. Deviations — sudden spikes in 4xx errors, parameter scanning patterns, off-hours access from unusual geographies — should generate alerts.

Phase 4 — Test Continuously

• Include API security testing in your CI/CD pipeline: automated DAST scanning of API endpoints before deployment.
• Conduct scheduled penetration tests focused specifically on the API layer, including BOLA/BFLA scenarios and business logic testing that automated tools miss.
• Red team exercises that simulate supply chain compromise via partner API credentials.

PrahiX Ora: Unified SecOps Coverage Across Your API Estate

One of the operational challenges Indian enterprises face is fragmented visibility: API gateway logs in one tool, endpoint logs in another, network telemetry in a third, with no unified correlation layer. This fragmentation is exactly what attackers exploit — a BOLA attack chain may touch application logs, network flows, and authentication systems simultaneously, but be invisible to any single monitoring tool in isolation.

The platform we deploy and operate for clients is PrahiX Ora, a unified SecOps platform built by PrahiX Tech Pvt Ltd. It addresses the API security visibility problem through four integrated capabilities:

SIEM: Ora’s SIEM ingests logs from API gateways, application servers, identity providers, and network devices in a single pipeline. Correlation rules mapped to MITRE ATT&CK — including techniques like T1190 (Exploit Public-Facing Application) and T1078 (Valid Accounts, covering credential-stuffed API keys) — connect events across sources into graph-based attack storylines. For CERT-In compliance, Ora’s tiered retention architecture (hot, cold, archive) keeps 180 days of API logs in-country, structured for rapid incident scoping. When a BOLA pattern is detected, analysts can trace the full request chain across sources within minutes rather than hours — making the 6-hour reporting window achievable.

NMS: Unified network observability across firewalls, switches, access points, and WAN/SD-WAN links provides the network context that pure API monitoring misses. In multi-vendor estates — a common reality in Indian enterprises that have layered infrastructure across Cisco, Juniper, Fortinet, and cloud-native networking — NOC visibility is typically fragmented. Ora’s NMS brings LLDP/CDP topology discovery and network path tracing into a single view, with ML-based anomaly detection that can surface unusual API traffic flows at the network layer before application-level detection fires.

Video Surveillance (VMS): For manufacturing, retail, and multi-site estate clients, Ora integrates video surveillance (VMS) alongside network and security monitoring through ONVIF/Hikvision/Dahua camera management and video analytics. Physical access incidents — after-hours server room access, for instance — that correlate with unusual API activity at the same time and location can now be surfaced in the same operations view. This unified physical-and-network security posture is particularly relevant for clients managing distributed branch environments.

SOAR: Ora’s playbook automation addresses the operational bottleneck in API incident response. Pre-built connectors and automated response actions — including pushing dynamic blocklists directly to FortiGate to block compromised API clients at the network edge — compress response times from hours to minutes. For CERT-In’s 6-hour incident reporting requirement, it is automation that makes the timeline realistic: a confirmed API breach can trigger automatic token revocation, scope assessment queries, and report generation simultaneously, while the analyst focuses on investigation rather than manual coordination.

If API visibility and incident response capability are gaps in your current security programme, we can discuss how Ora is deployed and operated for clients in your sector. Reach out to our team for an initial assessment.

FortiGate and Fortinet Integration in API Security Architecture

For PJ Networks clients running FortiGate next-generation firewalls, there is a native integration point for API security enforcement. FortiGate’s application control and SSL/TLS inspection capabilities can terminate API traffic at the perimeter, providing deep packet inspection of API payloads before they reach internal services.

FortiWeb (Fortinet’s dedicated web application and API firewall) adds API-specific capabilities: automatic API schema learning, positive security model enforcement, bot management, and OWASP API Top 10 protection at the request handling layer. For organisations that need WAF and API protection without deploying a separate API gateway, FortiWeb provides a consolidated control point.

FortiMail’s integration matters for API-adjacent risks: phishing campaigns targeting developer credentials and OAuth token theft are common precursors to API compromise. Protecting the email surface that attackers use to harvest API credentials is part of a complete API security architecture.

Key Checklist: API Security Readiness for Indian Enterprises

• ☐ Complete API inventory exists, including shadow and internal APIs
• ☐ All APIs require authentication — no unauthenticated endpoints in production
• ☐ Token expiry and revocation policies are enforced
• ☐ Rate limiting is applied per endpoint, not just globally
• ☐ API response payloads are reviewed for excessive data exposure
• ☐ API gateway logs include full request context and are retained for 180 days in-country
• ☐ SIEM correlation rules cover OWASP API Top 10 attack patterns
• ☐ API-specific IR playbook exists with CERT-In reporting workflow
• ☐ Partner API integrations are contractually bound to equivalent security requirements (DPDP)
• ☐ API penetration testing is conducted at least annually and after major changes

Conclusion

API security is not a niche concern — it is the central security challenge for any Indian enterprise operating digital services in 2025. The combination of rapid API adoption, DPDP Act compliance obligations, and CERT-In’s incident reporting requirements creates a situation where API security gaps are simultaneously a technical risk, a regulatory risk, and an operational risk.

The good news is that the building blocks for a mature API security programme are well understood. Discovery, gateway-layer enforcement, runtime monitoring with a capable SIEM, and automated incident response through a SOAR platform are the pillars. What most organisations lack is the operational capacity and integrated tooling to run these programmes consistently.

PJ Networks provides managed security services built around Fortinet’s security fabric and the PrahiX Ora SecOps platform — giving Indian enterprise IT and security leaders the coverage they need without the overhead of building and maintaining specialised teams in-house. If API security is on your roadmap for 2025, we can help you structure an approach that fits your architecture and your regulatory obligations.

Contact PJ Networks to discuss an API security assessment or a managed API monitoring engagement: pjnetworks.com/contact