



India’s enterprise digital transformation has accelerated faster than most organisations anticipated. Banking, manufacturing, logistics, healthcare — every sector is now API-first. Payment gateways connect via APIs. Supply chains share inventory data via APIs. Mobile banking apps, insurance portals, and government compliance platforms all run on a web of REST and GraphQL endpoints. And that surface area is exactly where adversaries are now concentrating their efforts.
In 2024 and into 2025, API-targeted attacks have become one of the fastest-growing categories of enterprise breach. Unlike traditional perimeter attacks that your firewall or IPS was designed to stop, API abuse often looks like legitimate traffic — authenticated, well-formed requests that simply do the wrong thing at scale. Bots enumerate user accounts through login endpoints. Broken object-level authorisation (BOLA) lets one customer read another’s records. Shadow APIs — forgotten endpoints that never made it into documentation — quietly accept requests no one intended to expose.
For Indian enterprises, the stakes are compounded by regulatory obligations. CERT-In’s 2022 directions mandate incident reporting within six hours of detection. The Digital Personal Data Protection (DPDP) Act 2023 places accountability on data fiduciaries for every breach of personal data — and most personal data today flows through APIs. A breach discovered Monday morning that you can’t trace to a specific API endpoint by Monday afternoon is an organisation that will miss its reporting window and face regulatory exposure on top of business damage.
This guide covers what API security actually requires in a modern Indian enterprise context, the attack patterns your team needs to understand, and the operational and technological controls that close those gaps.
The OWASP API Security Top 10 was first published in 2019 and has been updated since — not because the list got shorter, but because API vulnerabilities have become more sophisticated and more exploited. Let’s look at the patterns most relevant to Indian enterprises right now.
The most common API vulnerability, BOLA occurs when an API accepts a resource identifier (a user ID, an account number, an invoice ID) from the request and returns the corresponding object without verifying the requesting user is authorised to see it. An attacker with a valid session token simply iterates through IDs. In a fintech or BFSI context, this can expose account balances, transaction history, or KYC documents belonging to other customers. The fix requires server-side authorisation checks on every object retrieval — not just authentication at the API gateway.
Many enterprise applications use JSON Web Tokens (JWTs) for stateless authentication. JWT misconfigurations — accepting the “none” algorithm, using weak signing secrets, failing to validate token expiry — are surprisingly common, particularly in applications developed under rapid release pressure. Attackers who can forge or manipulate JWTs gain full session control without ever compromising credentials.
APIs built to serve mobile front-ends often return entire data objects and rely on the client to filter what is displayed. This means the raw API response contains far more personal or financial data than the user ever sees on screen — but an attacker intercepting or probing the API receives everything. For DPDP Act compliance, this is particularly problematic: serving data you didn’t need to serve is both a design failure and a potential compliance violation.
Enterprises accumulate APIs the way they accumulate technical debt — quietly. A microservice deployed for a specific project. A v1 endpoint that was supposed to be retired when v2 launched. An internal API that got accidentally exposed through a misconfigured reverse proxy. These shadow and zombie APIs are invisible to your API gateway policies and your WAF rules. Attackers find them through active scanning and historical DNS records.
Credential stuffing, OTP brute-forcing, and account enumeration attacks all exploit the same weakness: the API doesn’t enforce meaningful rate limits, or enforces them in ways that are trivially bypassed with distributed requests. Business logic abuse — using APIs exactly as designed but in sequences or volumes that violate intended use — is harder to detect with signature-based controls and requires behavioural analysis.
India’s data protection landscape has changed materially. The DPDP Act 2023 establishes obligations that directly intersect with API security:
CERT-In’s 2022 directions add a logging requirement that is directly relevant to API security: logs must be maintained for 180 days, stored within India, and must be of sufficient quality to reconstruct events. API access logs — request timestamps, source IPs, authenticated identities, endpoint paths, response codes and payload sizes — are exactly the artefacts that CERT-In investigators will request after an incident. Organisations that lack centralised API log ingestion and retention will find themselves unable to satisfy both the reporting window and the forensic requirements.
You cannot secure what you don’t know exists. API discovery should include both active scanning (crawling your own infrastructure to find exposed endpoints) and passive discovery (analysing traffic through your security monitoring stack to identify APIs in use). Every API should have a documented owner, a classification (internal, partner, public), the sensitivity of data it handles, and a review date. This inventory feeds your risk prioritisation and your incident response scope.
Your API gateway is the first enforcement point. At minimum, it should handle authentication (validating tokens before requests reach backends), TLS termination, rate limiting per consumer and per endpoint, request size limits, and payload schema validation. FortiGate NGFWs with application control policies can enforce API schema validation and detect anomalous API call patterns as traffic traverses the perimeter. For organisations already running FortiGate as their perimeter firewall, integrating API security policies at the FortiGate layer extends existing investment.
Traditional WAFs inspect HTTP traffic but were not designed for the nuances of API payloads. Modern WAAP solutions extend WAF capabilities with API-aware inspection: understanding JSON and XML structure, detecting BOLA patterns, enforcing positive security models based on OpenAPI specifications. Deploying WAAP in front of externally facing APIs provides a detection layer for known attack patterns while generating the logs needed for compliance.
Signature-based controls catch known attacks. Business logic abuse and sophisticated BOLA exploitation require behavioural baselines. Establishing what “normal” looks like for each API endpoint — typical request rates, typical parameter ranges, typical sequences of calls — allows detection of deviations that don’t match any known signature. This is where SIEM correlation and anomaly detection become essential.
API keys, service account credentials, and JWT signing secrets must be managed with the same rigour as user passwords — arguably more rigour, since they are often long-lived and widely embedded. Hardcoded API keys in mobile application binaries, in public GitHub repositories, and in environment variables without rotation are common findings in security assessments. A secrets management platform with automatic rotation and audit logging closes a significant class of API credential risk.
Annual or bi-annual penetration tests that include dedicated API testing — not just a web application scan — are the ground truth for your API security posture. Testers should exercise the full OWASP API Security Top 10 against your production or staging environment. Findings should feed directly into your remediation backlog and be tracked to closure.
Detecting and responding to API-targeted threats requires operational infrastructure that most enterprises find difficult to build in-house. The detection signals are spread across multiple sources — API gateway logs, firewall logs, application logs, identity provider events — and correlating them manually at the scale and speed required is not realistic. This is the operational gap that a unified SecOps platform addresses.
PrahiX Ora is a unified SecOps platform built by PrahiX Tech Pvt Ltd. PJ Networks is its primary field deployment and operations partner — we deploy and operate the platform for clients across banking, manufacturing, healthcare, and enterprise sectors.
SIEM: Ora’s SIEM ingests logs from API gateways, FortiGate firewalls, web servers, identity providers, and cloud workloads into a unified correlation engine. Detection rules mapped to MITRE ATT&CK framework techniques allow SOC analysts to identify API attack patterns — such as BOLA enumeration and credential stuffing against authentication endpoints — as structured attack storylines rather than isolated log events. For Indian enterprises, Ora supports CERT-In’s direction for 180-day in-country log retention through a tiered architecture (hot, cold, and archive) that balances query performance against storage cost.
NMS: API security incidents rarely happen in isolation from network events. Ora’s Network Management System pillar provides unified observability across firewalls, switches, wireless access points, and WAN or SD-WAN links. LLDP and CDP topology discovery maps the network path between API consumers and API backends, and ML-based anomaly detection flags unusual traffic volumes or path deviations that may indicate active exploitation. For enterprises running multi-vendor estates where NOC visibility is fragmented across separate tools, Ora’s NMS consolidates that picture into a single operations view.
Video Surveillance (VMS): For manufacturing, retail, and multi-site estates, physical and cyber security are increasingly converged concerns. Ora’s video surveillance (VMS) pillar — supporting ONVIF, Hikvision, and Dahua cameras with built-in video analytics — brings physical security events into the same operations view as network and security events. An alert from a server room access control system can be correlated with an anomalous API call pattern from the same site, giving security operations a complete picture rather than two separate siloes.
SOAR: CERT-In’s six-hour incident reporting window is the operational pressure point that makes automation essential. When an API-targeted attack is detected — a credential stuffing campaign against your authentication endpoint, for example — Ora’s SOAR pillar can automatically push blocklists to FortiGate via pre-built connectors, suspend compromised API keys, trigger isolation workflows, and begin assembling the incident timeline that your compliance team needs for the CERT-In notification. Without automation, the human steps required to contain an incident and prepare a notification within six hours are difficult to execute under pressure. With SOAR playbooks pre-configured for your environment, they become realistic.
If your organisation is evaluating SOC capabilities or looking to close gaps in API threat detection, contact us to discuss how Ora has been deployed in comparable environments.
When an API breach does occur — and for enterprises with significant API exposure, the question is when, not if — the quality of your incident response determines both the business impact and your regulatory standing.
A pre-built API incident response playbook should address:
Organisations without a documented playbook that has been tested in a tabletop exercise tend to improvise under pressure — and improvisation at 2am when CERT-In’s reporting clock is running leads to poor decisions, missed notification windows, and incomplete forensics.
API security is not a product you purchase and deploy once. It requires sustained programme attention. A reasonable starting sequence:
PJ Networks provides managed security services — FortiGate management, 24/7 NOC/SOC operations, ZTNA deployment, and full MSSP capability — to Indian enterprises across manufacturing, BFSI, healthcare, and logistics. If you’re looking to close gaps in API security monitoring, incident response readiness, or CERT-In compliance posture, reach out to our team to discuss where your organisation stands and what a realistic improvement roadmap looks like.