API Security Is the New Perimeter

Salt Security's API Security Report measured a 681 percent increase in API attacks in a single year. The average enterprise now manages more than 900 active APIs, and most security teams cannot say how many of those APIs exist, what data each one exposes, or which ones are talking to systems that should not be reachable.

681% in one year.

For most of the last decade, the enterprise perimeter conversation was about firewalls, then about SD-WAN, then about SASE. Each conversation moved the perimeter outward to the network edge, then to the identity edge, then to the cloud edge. Each conversation skipped the layer that now carries most of the actual business logic: the API.

The API is the new perimeter. It has been for two years. Most enterprise security stacks have not caught up.

For the Indian BFSI buyer specifically, the catch-up just got more urgent. The Reserve Bank of India's April 2026 Authentication Mechanisms for Digital Payment Transactions Directions, 2025 mandates two-factor authentication on every digital transaction with at least one dynamic factor, ruling out static SMS-only OTP as the sole authentication layer. The mandate covers UPI, cards, and wallets. The compliance scope sits at the API gateway, not the user interface.

But first, some catch-up on infra this week.

The 2023 OWASP API Security Top 10 ranking, which remains operationally relevant in 2026, puts authorization failures at the top.

Valid credentials, valid traffic.

BOLA (Broken Object Level Authorization) and BFLA (Broken Function Level Authorization) are the two attack patterns that exploit a single design flaw most enterprise APIs share. The API correctly authenticates the user. The API correctly identifies which endpoint the user is calling. The API does not correctly verify that the authenticated user is authorized to access the specific object or function being requested. The attacker authenticates as a legitimate user with their own account and then calls an endpoint with a different user's object ID, retrieving data they should not be allowed to see.

For an Indian BFSI buyer, BOLA is the attack pattern that exposes one customer's account balance to another customer's authenticated session. BFLA is the variant that exposes an administrative function (rate-change, fee-waive, transfer-cancel) to a non-administrative user. Neither attack involves invalid credentials. Neither attack produces traffic that a traditional WAF flags as anomalous. Both attacks are designed to look exactly like legitimate traffic to every signature-based detection layer the security team has deployed.

Business logic abuse is the newer variant. The attacker uses valid credentials, valid API calls, and valid workflows in combinations that the application was not designed to handle. The lending API designed to evaluate one loan per session is called 10,000 times to scrape competitor pricing. The transfer API designed for end-of-day batch settlements is called every minute to mask large transactions inside a stream of small ones. The customer-profile API designed for one lookup per service-request is called sequentially across the entire user base to enumerate the customer list. Each call is technically allowed. The pattern is the abuse.

Traditional WAFs do not catch business logic abuse, because the WAF sees each call as valid. Signature-based API security tools do not catch it either, for the same reason. The detection layer has to live at the behavioural pattern, not at the request inspection.

For the Indian BFSI buyer working backward from a 2026 audit:

✔ Inventory every public-facing and partner-facing API. The shadow APIs the security team does not know about are the highest-risk subset.

✔ Map every API to the data classes it can return. The procurement-side risk question is "if this API is called incorrectly, what is the worst-case data exposure."

✔ Enable behavioural detection on every authorization-sensitive endpoint. The pattern is the alert, not the request.

✔ Test the OWASP API Top 10 attack patterns against the production API surface, not just the staging environment.

The API-security vendor landscape consolidated significantly in 2024-2025. Three vendors carry most of the 2026 procurement conversation, with the caveat that the category is still settling.

Runtime detection beats discovery alone.

Akamai API Security (built on Noname Security, acquired June 2024 for $450 million) is the current market leader by mindshare. Akamai's platform discovers APIs enterprise-wide, tests them in CI/CD pipelines, and detects runtime attacks using machine learning. The Akamai distribution advantage matters for the Indian BFSI buyer: Akamai's existing CDN and security relationship with most large Indian banks means the API-security product can be added under an existing master agreement rather than requiring a fresh vendor onboarding cycle. 14.7 percent OT-Security-equivalent mindshare; 5.5 average peer rating.

Salt Security is the only remaining pure-play independent vendor. 10.1 percent mindshare; 100 percent of users would recommend the platform. Salt's behavioural-detection depth is consistently rated above the discovery-and-runtime-protection competition. For an Indian BFSI buyer whose threat model leads with business-logic abuse and whose security team wants the depth a pure-play vendor commits to, Salt is the strongest standalone option. The procurement caveat: pure-play vendors can be acquired. The buyer signing a 3-year contract should understand the acquisition risk and the renewal-cycle protection clauses.

Traceable merged with Harness in March 2025, becoming part of a broader DevOps-and-security platform. For the Indian buyer already running Harness for CI/CD and application-performance work, the integrated story is operationally cleaner. For a buyer evaluating API security on its own merits, Traceable's depth is still real but the product roadmap now follows Harness's broader platform priorities.

The market is consolidating in three directions at once: into CDN+security platforms (Akamai), into application-development platforms (Harness+Traceable), and into pure-play independent depth (Salt). The Indian BFSI buyer's procurement question turns on which of those three architectural commitments aligns with the existing stack.

Indian domestic alternatives sit alongside the three globals. TCS, Wipro, Infosys, and HCL run API-security capability as part of broader managed-services engagements, typically with one of the three globals as the underlying technology. AppSecure, Indusface, and Akto are domestic-Indian or India-founded API-security vendors with growing reference customers in the BFSI segment. For an Indian buyer wanting India-resident contract counterparty and DPDP-aligned data-residency, the domestic option has matured significantly in the last 18 months.

The April 2026 RBI mandate restructured the digital-payment authentication expectation for every entity in the Indian BFSI value chain.

From April 1 2026, the RBI's Authentication Mechanisms for Digital Payment Transactions Directions, 2025 requires:

✔ Mandatory two-factor authentication on every digital transaction across UPI, cards, and wallets

✔ At least one dynamic factor of authentication. Static SMS-only OTP is no longer sufficient as the sole factor

✔ The dynamic factor must be unique per transaction. Credentials cannot be reused across transactions

✔ Acceptable dynamic factors include rotating OTP, biometric verification, and hardware token output

For the Indian BFSI buyer, the operational implication is clear. The compliance enforcement happens at the API layer, not at the user-interface layer. The mobile-banking app may collect the authentication data; the API gateway is what verifies the second factor is dynamic, unique, and not replayed. The compliance burden sits on the API security and identity stack, not on the front-end product team.

For fintech buyers building on top of banking APIs (lending, payments, KYC), the implication is sharper. The compliance posture has to be verified at every API boundary, with the documentation that proves the verification happened. The supervisory scrutiny RBI has been applying to API authentication, rate limiting, and fraud detection is now the daily operational reality.

For the BFSI CISO drafting the API-security RFP, three questions worth getting right with the vendor:

👉 What does the platform's verification artefact look like for a transaction that exercised the RBI-mandated dynamic-factor authentication, and can it be exported in a form that satisfies the RBI sector-regulator audit?

👉 What is the platform's behaviour if an authenticated user exhibits business-logic-abuse patterns (rapid sequential calls, unusual workflows, anomalous parameter combinations)? The mandate covers authentication; the behavioural layer covers what happens after authentication succeeds.

👉 What is the platform's rate-limiting and adaptive-throttling posture for the public-facing fintech-aggregator APIs that the bank exposes? UPI volume scale changes the threshold conversation.

The RBI mandate is the procurement frame. The API-security platform is the implementation. Both have to align before the next audit cycle.

The RBI advisory on customer data protection issued in April 2026, aligning with DPDPA, tightened the data-sharing expectation for regulated BFSI entities and their fintech partners.

The substance: regulated entities can share user data with third parties only for necessary and defined purposes. Existing data-sharing arrangements must be reviewed. Anonymisation and pseudonymisation must be applied as appropriate safeguards.

For the API-security buyer, the advisory has three operational implications.

First, every API that returns customer data to a third party must have an explicit purpose statement, documented and approved, with an audit trail tying the purpose to the actual data classes the API returns. The "we share whatever the partner asks for under a master MSA" model is finishing.

Second, the existing partner-and-vendor data-sharing inventory needs to be reviewed against the advisory before the next renewal cycle. Most BFSI buyers have hundreds of these arrangements, most of them documented with varying levels of specificity, many of them signed before the DPDPA framework existed.

Third, anonymisation and pseudonymisation are not theoretical. The API has to apply the transformation at the response layer, with the verification that the transformation actually worked. The audit committee will read the verification artefact, not the policy document.

The compliance posture is layered:

✔ DPDPA at the architecture layer

✔ RBI data-sharing advisory at the contract layer

✔ April 2026 authentication mandate at the API gateway layer

✔ OWASP API Top 10 defensive baseline at the platform layer

The four layers have to coexist in the same operational stack. The procurement RFP has to evaluate the API-security platform against all four.

For the Indian fintech buyer specifically, the compound implication is sharper. Fintechs sit on top of bank APIs, expose their own APIs to merchant partners, and route customer data through the OAuth-and-aggregator framework that RBI has been progressively tightening. A single fintech may have 50 inbound API integrations and 200 outbound API exposures, each of which has to satisfy the four-layer posture. The procurement memo that treats API security as a feature of the WAF, rather than as a first-class platform decision, will fail the next RBI supervisory review. The buyer that frames the procurement against the four layers from the start finds the conversation easier with the audit committee and easier with the regulator.

OWASP API Security Top 10 (2023, operationally current in 2026)
OWASP.
The primary source for the API-attack-surface taxonomy. Read before any vendor pitch lands.

Akamai API Security vs Salt Security comparison
PeerSpot.
The cleanest side-by-side vendor read across the consolidated 2026 landscape. Useful for the procurement memo's vendor-shortlist work.

RBI's New Authentication Mandate: Strengthening Digital Payments
AuthBridge.
The primary-source explainer on the April 2026 mandate. Pair with the Medianama RBI advisory coverage for the compliance-side completeness.

OWASP API Security Top 10 in 2026
Akto.
Indian API-security vendor's explainer with the 681%-attack-growth figure. Useful for the BFSI-buyer threat-model framing.

API Security Tools and Platforms 2026 Guide
Zuplo.
Broader-than-three-vendor read of the API-security marketplace. Useful when the buyer wants a longer shortlist before locking the three.

The API has been the perimeter for three years.

The defensive stack most Indian BFSI buyers run has not been adjusted for that fact.

The firewall is still configured to inspect Layer 4 traffic on standard ports. The WAF is still tuned for HTTP injection patterns. The IDS still reads NetFlow signatures designed for east-west lateral movement, not for north-south authenticated API abuse. The SOC playbook still triggers on volumetric anomalies, not on business-logic patterns.

APIs are your business logic.

That sentence is the centre of the procurement conversation for 2026-2027.

The application's business logic does not live in the codebase any more. It lives in the API contract. The API contract defines what the user can do, what objects the user can access, what functions the user can call, what data classes the response can include. The application is increasingly a thin shell around the API. The mobile app is just a renderer. The web portal is just another renderer. The fintech-partner integration is just another caller. All of them pass through the same API layer.

The attacker who targets the API is not bypassing the application. The attacker is targeting the application at the only layer where the actual business logic lives.

The defensive response has to live in the same place. Not at the firewall. Not at the WAF. Not at the user-interface layer. At the API gateway, with behavioural detection that understands the patterns the OWASP Top 10 names, the rate-limiting that catches the volumetric abuse the WAF misses, the verification artefacts that satisfy the RBI mandate and the DPDPA advisory, and the documentation discipline that survives the audit committee read.

For the Indian BFSI CISO drafting the 2026 API-security RFP, the procurement question is not "should we add an API-security platform to the stack."

The procurement question is "which API-security platform's architectural commitment aligns with the perimeter the application actually has, and what is the verification cadence that proves the alignment is working twelve months after the contract was signed."

Once that question has an answer, the vendor decision follows. The implementation timeline follows. The audit-committee narrative follows.

VEMIO™ exists because the operational reality of running an API-security posture across a multi-product Indian BFSI estate needs an observability layer the API-security platform alone does not provide. The platform reports that the attack was blocked. The CISO needs to see across the API discovery, the runtime detection, the behavioural alerts, the RBI authentication-mandate verification, the DPDPA data-sharing audit, and the OWASP-Top-10 baseline coverage. All in one operator view.

The perimeter moved. The defensive stack should have moved with it.

Reply to this email with the one API endpoint you cannot currently document who is allowed to call, and we will feature the most operationally interesting reply (anonymised, with consent) next issue.

Until next time,

Ajay Salvi & the Vinay Enterprises team.