The Surge in API Attacks
In the first half of 2025, small and medium-sized businesses (SMBs) faced over 1.45 billion attacks, with API-targeted exploits increasing 74 times compared to previous periods. This was not an isolated incident but a systematic shift in attacker strategy. Organizations with customer portals, mobile app backends, and third-party integrations were overwhelmed by automated attacks probing for authentication bypasses, injection vulnerabilities, and exposed endpoints.
Attackers consistently scanned for shadow APIs, tested deprecated endpoints that teams forgot to decommission, and exploited the gap between API deployment speed and security controls. Many affected organizations had traditional web application firewalls (WAFs), but these tools weren't designed to handle the logic flaws and business logic abuse common in modern API attacks.
Attack Timeline
The attack timeline for affected SMBs typically followed this pattern:
Weeks 1-4: Attackers conducted reconnaissance, enumerating API endpoints through automated scanning and identifying undocumented APIs, versioning inconsistencies, and authentication mechanisms.
Weeks 5-8: Exploitation attempts intensified. Automated tools tested for OWASP API Security Top 10 vulnerabilities—broken object level authorization (BOLA), broken authentication, and excessive data exposure.
Weeks 9+: Successful compromises occurred when teams lacked continuous monitoring. Data exfiltration, account takeovers, and service disruptions followed. Detection often came from customer complaints or unusual traffic patterns rather than security tools.
Control Gaps Exposed
The surge exposed four critical control gaps:
API inventory and discovery: Organizations couldn't protect what they didn't know existed. Shadow APIs created unmonitored attack surfaces. Teams with microservices architectures were particularly vulnerable, with APIs proliferating across containers and cloud functions.
Runtime threat detection: Traditional signature-based WAFs failed against API-specific attacks. Logic abuse doesn't trigger SQL injection rules. A legitimate GET request that iterates through sequential IDs to scrape customer data looks like normal traffic to pattern-matching tools.
Positive security model enforcement: Most organizations operated with negative security (blocking known-bad patterns) rather than positive security (allowing only known-good behavior). This left them vulnerable to zero-day API exploits and business logic abuse that didn't match existing attack signatures.
Vulnerability validation and patching cadence: Teams identified vulnerabilities through scanning but lacked processes to validate which issues were exploitable in their specific deployment context. This created alert fatigue and delayed remediation of critical exposures.
Compliance Standards and Requirements
OWASP API Security Top 10 (2023) addresses these gaps directly. API1:2023 (Broken Object Level Authorization) requires authorization checks for every function that accesses data using user input. API9:2023 (Improper Inventory Management) mandates documented API inventories, including deprecated versions.
PCI DSS v4.0.1 requires maintaining an inventory of bespoke and custom software, including APIs, and documenting their security requirements. If you process payment data through APIs, you cannot claim compliance without knowing which endpoints exist and how they're secured.
ISO/IEC 27001:2022 (Secure development lifecycle) requires security integration throughout development, including API design and deployment. Your ISMS must document how you discover, inventory, and secure APIs before they reach production.
NIST Cybersecurity Framework maps these requirements across the Identify, Protect, and Detect functions. ID.AM-2 requires maintaining software platform and application inventories—including APIs. DE.CM-4 requires detecting malicious code and unauthorized network connections, which includes API abuse.
For SOC 2 Type II audits, the CC6.1 (Logical and Physical Access Controls) criterion requires restricting logical access to APIs based on defined criteria. Your auditor will ask how you discover APIs, enforce authentication, and monitor for unauthorized access patterns.
Action Items for Your Team
Implement continuous API discovery. Deploy runtime discovery tools that observe actual traffic and identify all active endpoints. Schedule this as a weekly automated scan. Map discovered APIs against your architecture diagrams and flag discrepancies.
Adopt a positive security model for API protection. Define allowed methods, parameters, and data schemas for each endpoint. Block everything that doesn't match the specification. Document API contracts to scale against novel attack patterns.
Establish runtime monitoring with behavioral baselines. Track normal API usage patterns—request rates per user, typical parameter values, geographic distribution. Alert on deviations: a user account suddenly iterating through thousands of object IDs, or a mobile app endpoint receiving web browser traffic.
Build a vulnerability validation workflow. When your scanner reports an API vulnerability, attempt to exploit it in a staging environment before prioritizing remediation. This prevents wasted effort on theoretical issues while ensuring you address real exposures quickly. For vulnerabilities you can't patch immediately, implement virtual patches—runtime rules that block the specific exploit pattern while you work on the code fix.
Create an API decommissioning checklist. Before deprecating an API version, verify that no clients still use it. Set a sunset date, notify consumers, and monitor for traffic. When you shut it down, remove it from your infrastructure completely.
The 1.45 billion attacks represent a permanent shift, not a temporary spike. Your API security posture must match the threat level. Start with discovery, establish your baseline, and build detection before the next wave hits.
