Akamai's 2026 SOTI Report: APIs Emerge as

The Akamai 2026 State of the Internet (SOTI) Report definitively establishes APIs as the predominant and most critical attack surface, shifting the cybersecurity focus from traditional web applications to the intricate network of programmatic interfaces driving modern digital ecosystems. The report details a significant escalation in API-specific attacks, driven by the pervasive adoption of microservices architectures, cloud-native deployments, and the increasing reliance on third-party integrations. Attackers are now routinely targeting API endpoints for data exfiltration, service disruption, and unauthorized access, exploiting logical flaws and misconfigurations that traditional security measures often overlook.

The Proliferation of APIs and the Expanding Attack Surface

The digital transformation journey for most enterprises has culminated in a complex mesh of APIs. These interfaces are the backbone of mobile applications, single-page applications, IoT devices, and business-to-business integrations. While offering unparalleled agility and innovation, this proliferation has inherently expanded the attack surface. Organizations frequently struggle with comprehensive API inventory, often unaware of shadow APIs, zombie APIs (deprecated versions), or misconfigured internal APIs exposed to the internet. An effective External Attack Surface Management (EASM) solution, such as Secably, becomes indispensable for discovering and cataloging these endpoints. The 2026 SOTI Report underscores that attackers are leveraging sophisticated reconnaissance techniques, including internet-wide scanning tools like Zondex, to identify exposed API gateways, misconfigured GraphQL endpoints, and undocumented RESTful services. The sheer volume and diversity of API endpoints make manual security assessments impractical, leading to significant blind spots.

OWASP API Security Top 10 (2023) – A Persistent Threat Landscape

Despite continuous efforts by the security community, the fundamental vulnerabilities outlined in the OWASP API Security Top 10 (2023) remain highly prevalent and continue to be primary vectors for API exploitation. The Akamai report highlights several of these as consistently exploited in 2025 and early 2026.

API1:2023 – Broken Object Level Authorization (BOLA)

BOLA, also known as Insecure Direct Object Reference (IDOR), is consistently ranked as the number one API security threat due to its ease of exploitation and catastrophic impact. This vulnerability arises when an API endpoint accepts an object identifier (e.g., a user ID, order ID, or document ID) from the client without sufficiently verifying that the authenticated user is authorized to access that specific object. Consider an API endpoint for retrieving user profiles:

GET /api/v1/users/{user_id}/profile

An attacker, authenticated as `User A` with `user_id=123`, might simply change the `user_id` parameter to `456` in the request:

GET /api/v1/users/456/profile

If the backend logic fails to verify that `User A` is indeed authorized to access `User B`'s profile (with `user_id=456`), the attacker gains unauthorized access to sensitive data. Real-world incidents, such as the Uber data breach, have demonstrated how manipulating user IDs in API requests can lead to widespread data exposure. CVE-2024-1313, a BOLA vulnerability in Grafana, further illustrates this persistent threat. Organizations must enforce robust, object-level authorization checks for every API request that handles object identifiers.

API2:2023 – Broken Authentication

Improperly implemented authentication mechanisms allow attackers to compromise authentication tokens or exploit flaws to impersonate users. This includes weak credential management, lack of multi-factor authentication (MFA), session fixation, or vulnerabilities in token validation. The 2026 SOTI Report notes an increase in attacks targeting JWT (JSON Web Token) implementations. A recent example is CVE-2026-29000, affecting `pac4j-jwt`, which allows a remote attacker to bypass authentication and impersonate arbitrary users, including administrators, by crafting a JWE-wrapped PlainJWT with arbitrary claims, effectively bypassing signature verification. This highlights the danger of confusing confidentiality with authenticity in token validation. Another instance, CVE-2025-13915 in IBM API Connect, demonstrates how authentication bypasses can grant unauthorized access to management interfaces, emphasizing the need for rigorous authentication enforcement in API gateways. The Duolingo API breach in 2023, where user information was accessible simply by an email or username without further verification, exemplifies a mix of Broken Authentication and Broken Object Property Level Authorization.

API3:2023 – Broken Object Property Level Authorization

This category, new in the 2023 OWASP API Top 10, merges "Excessive Data Exposure" and "Mass Assignment" from the 2019 list. It addresses failures in defining and enforcing access control at a granular property level within objects.

Excessive Data Exposure

APIs often expose more data than necessary, relying on the client-side to filter what is displayed. This "over-fetching" of data can inadvertently expose sensitive information. For instance, an endpoint retrieving a user's basic profile might also return internal IDs, payment details, or activity logs that are not intended for the requesting user. CVE-2022-34775 (Tabit) highlights excessive data exposure where a reservation cancellation endpoint, given a MongoDB ID, returned extensive sensitive reservation data, including names, emails, phone numbers, and spending habits. Example of an API response with excessive data:

{
  "userId": "user123",
  "username": "johndoe",
  "email": "[email protected]",
  "role": "customer",
  "internal_id": "GUID-5678-ABCD",
  "creditCardLastFour": "1234",
  "fullCreditCardNumber": "4111222233334444", // Excessive exposure
  "ssn": "XXX-XX-1234", // Excessive exposure
  "lastLoginIp": "192.168.1.100"
}

The report stresses that developers must implement server-side data filtering to ensure only necessary information is returned, aligning with the principle of least privilege.

Mass Assignment

This vulnerability occurs when an API automatically binds client-supplied data to internal object properties without proper filtering. Attackers can exploit this to create or modify properties that they should not have control over, such as `isAdmin` flags or `accountBalance` fields. Securing against this requires explicit whitelisting of allowed properties for updates.

API7:2023 – Server-Side Request Forgery (SSRF)

SSRF attacks enable an attacker to force the server to make requests to an arbitrary domain of their choosing, bypassing network access controls and accessing internal resources. The 2026 SOTI Report indicates a significant surge in SSRF attacks, with AI-powered automation tools contributing to a 452% increase in 2024. These attacks often target cloud metadata services (e.g., AWS's `169.254.169.254`) to steal credentials and compromise infrastructure. CVE-2024-46990 in `@directus/api` demonstrates an SSRF vulnerability where an attacker could bypass a loopback IP filter to access `localhost` using alternative loopback addresses. Another critical SSRF vulnerability, CVE-2025-61882 in Oracle E-Business Suite, allowed pre-authenticated attackers to chain SSRF with CRLF injection and authentication bypass to achieve remote code execution. To exploit a hypothetical SSRF vulnerability in an API that processes image URLs for a thumbnail service, an attacker might send:

POST /api/v1/thumbnail HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "imageUrl": "http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-role"
}

If unmitigated, the server would fetch the AWS EC2 instance metadata, potentially exposing temporary credentials. Mitigating SSRF requires strict input validation, allow-listing of domains/IPs, and isolating resource-fetching functionality.

Advanced API Attack Techniques

The Akamai report also highlights the increasing sophistication of attacks beyond the OWASP Top 10, leveraging complex vulnerability chaining and novel exploitation methods.

Insecure Deserialization

This vulnerability arises when an API deserializes data from an untrusted source without proper validation. Maliciously crafted serialized objects can lead to remote code execution (RCE) during the deserialization process. While not explicitly a standalone OWASP API Top 10 item for 2023, it relates to `API8:2023 Security Misconfiguration` and `API10:2023 Unsafe Consumption of APIs`. Prominent examples include CVE-2023-34362 in MOVEit Transfer, where a SQL injection led to an API token compromise, which was then used to trigger a .NET `BinaryFormatter.Deserialize()` call, resulting in arbitrary code execution. CVE-2017-9805 (Apache Struts REST Plugin) is another classic example, where unrestricted XML deserialization led to RCE. More recently, CVE-2025-5662, a critical deserialization vulnerability in the H2O-3 REST API, allowed unauthenticated remote code execution via unsafe JDBC parameter handling. Also, CVE-2025-53770, known as "ToolShell," a critical zero-day RCE in Microsoft SharePoint Server, leverages insecure deserialization of untrusted data through API endpoints. Attackers use "gadget chains" – sequences of existing classes – to execute arbitrary code during deserialization.

// Malicious Java serialized object (example, actual payload is binary)
// Attacker crafts a serialized object that, when deserialized,
// triggers a system command, e.g., Runtime.exec("rm -rf /")
byte[] maliciousPayload = ...; // crafted to execute code
ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(maliciousPayload));
ois.readObject(); // This call triggers the RCE

Defense against insecure deserialization involves avoiding deserialization of untrusted data, implementing strict type checking, and using serialization formats that do not allow arbitrary object instantiation.

Zero-Day Exploits Targeting APIs

The rapid evolution of API technologies means new vulnerabilities are constantly emerging. The Akamai report notes that zero-day exploits against API endpoints are becoming more frequent, with attackers exploiting newly discovered flaws in as little as five days. The complexity of modern API stacks, coupled with the speed of development cycles (often fueled by AI-powered code generation), creates a fertile ground for these novel vulnerabilities. Continuous monitoring and a proactive security posture are vital to detect and respond to these threats.

Mitigation Strategies and Defensive Architectures

Protecting APIs effectively requires a multi-layered approach, combining robust design principles, rigorous testing, and continuous monitoring.

API Discovery and Inventory

A fundamental step, emphasized by the Akamai SOTI Report, is to gain complete visibility into the API attack surface. Many organizations are unaware of all their exposed APIs, including deprecated versions or internal services unintentionally accessible from the internet. Tools like Secably provide External Attack Surface Management (EASM) capabilities, offering continuous discovery and inventory of API endpoints. This includes identifying shadow APIs and zombie APIs that pose significant risks. For organizations looking to manage their API inventory programmatically, Secably offers a dedicated EASM API for integration into existing security workflows. A good starting point for any organization is to start a free EASM scan to understand their current exposure.

Strong Authentication and Authorization

Implementing robust authentication and authorization mechanisms is paramount. This includes:

• **OAuth 2.0 and OpenID Connect**: For secure delegation of access and identity verification.
• **API Keys with Scope Enforcement**: API keys should have granular permissions, and their usage should be monitored. CVE-2023-38510 in Tolgee, for instance, highlights how backend failure to verify API key permission scopes can bypass checks entirely.
• **Attribute-Based Access Control (ABAC)**: For fine-grained authorization policies based on attributes of the user, resource, and environment.
• **Per-request Authorization Checks**: Every request to a sensitive resource must undergo explicit authorization checks, particularly for object-level access.

This directly addresses `API1:2023 Broken Object Level Authorization` and `API2:2023 Broken Authentication`.

Input Validation and Output Filtering

Strict input validation is crucial to prevent injection attacks (SQLi, NoSQLi, Command Injection) and parameter tampering. APIs should rigorously validate all data received from clients, including headers, query parameters, and body content, against expected types, formats, and allowed values. For output, sensitive data should be filtered server-side to prevent `API3:2023 Excessive Data Exposure`.

Rate Limiting and Throttling

To counter `API4:2023 Unrestricted Resource Consumption`, APIs must implement effective rate limiting and throttling mechanisms. This prevents brute-force attacks, credential stuffing, and denial-of-service attempts by restricting the number of requests a client can make within a specified timeframe.

API Gateways and Web Application API Protection (WAAP)

API gateways act as a single entry point for all API traffic, enforcing security policies, authentication, authorization, rate limiting, and traffic management. Next-generation Web Application and API Protection (WAAP) solutions integrate WAF, bot mitigation, DDoS protection, and API security capabilities to provide comprehensive runtime protection against various API-specific threats.

Security Testing and Auditing

Regular and comprehensive security testing is non-negotiable.

• **Static Application Security Testing (SAST)**: Analyze source code for vulnerabilities.
• **Dynamic Application Security Testing (DAST)**: Test running applications for vulnerabilities by simulating attacks.
• **Interactive Application Security Testing (IAST)**: Combines SAST and DAST, monitoring application behavior from within.
• **Penetration Testing**: Manual testing by security experts to uncover complex logical flaws.
• **API-Specific Fuzzing**: Generate malformed or unexpected input to test API robustness.

Security researchers can leverage tools like GProxy for anonymous research and traffic routing when conducting API security assessments, ensuring their testing activities are controlled and deniable. Developers building APIs with frameworks like Django should refer to comprehensive resources such as the Django security guide to implement secure coding practices from the outset.