---
title: "APIs Are Now the #1 Exploited Attack Surface"
description: "Wallarm's 2026 API ThreatStats Report reveals APIs account for 43% of CISA's exploited vulnerabilities. Here's what the data means and how to protect your APIs."
canonicalUrl: "https://zuplo.com/blog/2026/03/19/wallarm-2026-api-threatstats-api-security"
pageType: "blog"
date: "2026-03-19"
authors: "nate"
tags: "API Security, Model Context Protocol"
image: "https://zuplo.com/og?text=APIs%20Are%20Now%20the%20%231%20Exploited%20Attack%20Surface"
---
Wallarm just published its
[2026 API ThreatStats Report](https://www.wallarm.com/reports/2026-wallarm-api-threatstats-report),
and the findings should have every API team paying attention. After analyzing
67,058 published vulnerabilities from 2025, the numbers paint a stark picture:
**APIs are now the single most exploited attack surface**.

Not web apps. Not cloud misconfigurations. APIs.

The headline stat: 43% of all additions to CISA's Known Exploited
Vulnerabilities (KEV) catalog in 2025 were API-related — 106 out of 245 entries.
That means when attackers are actively targeting something in the wild, nearly
half the time it is an API. On top of that, 11,053 of the 67,058 published
vulnerabilities (17%) were API-specific, and the characteristics of those
vulnerabilities are alarming: 97% can be exploited with a single request, 98%
are classified as easy or trivial to exploit, and 99% are remotely accessible.

If you build, manage, or secure APIs, this report is required reading.

## The Authentication Gap Is the Root Cause

The most damning finding in the report is simple: **59% of API vulnerabilities
require no authentication to exploit.**

Let that sink in. More than half of API security flaws can be triggered by
anyone on the internet without credentials. No stolen tokens, no session
hijacking, no brute-force attacks — just a raw HTTP request to an unprotected
endpoint.

The breach data backs this up. Wallarm tracked 60 API-related breaches disclosed
in 2025, and 52% were caused by broken authentication. Another 27% resulted from
unsafe API consumption. Together, authentication and access control failures
account for nearly 80% of real-world API breaches.

This is not a sophisticated threat landscape. It is a basic one. The report
found that 56% of API vulnerabilities are exploitable by low-skill actors and
30% have public exploit code readily available. Attackers do not need zero-days
or advanced tooling — they need a missing authentication check on an endpoint
you forgot to lock down.

The fix is straightforward in principle: every API endpoint needs authentication
enforced consistently, without exception. In practice, this is where teams
struggle. Manual configuration across dozens or hundreds of endpoints leads to
gaps. A single overlooked route becomes the entry point.

This is exactly why
[managed API key authentication](/docs/policies/api-key-inbound) and
[OAuth policies](/docs/articles/oauth-authentication) at the gateway level
matter. When authentication is a policy applied at the infrastructure layer
rather than custom code in each service, coverage becomes consistent and gaps
become visible. If you are building authentication from scratch, our guide on
[how to implement API key authentication](/learning-center/how-to-implement-api-key-authentication)
covers the patterns that address these exact vulnerabilities.

## MCP Is the New Attack Frontier

The AI angle in this year's report is impossible to ignore. Wallarm identified
2,185 AI-related vulnerabilities in 2025 — a nearly 400% increase year over
year. Of those, 315 were tied specifically to the
[Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction),
representing 14% of all AI vulnerabilities.

What makes MCP vulnerabilities particularly concerning is the growth trajectory.
Wallarm found that MCP-related security issues surged 270% from Q2 to Q3 2025
alone. And this makes sense: MCP adoption has exploded over the past year. Over
16,000 MCP servers now exist in the wild, with adoption from OpenAI, Google
DeepMind, and hundreds of companies integrating the protocol into their
platforms. As we covered in [One Year of MCP](/blog/one-year-of-mcp), MCP went
from "interesting protocol" to "rapidly adopted standard" in under twelve
months.

Rapid adoption without corresponding security rigor is how attack surfaces
expand. MCP servers are API endpoints, and they inherit all the same
vulnerability patterns that the ThreatStats report documents. If 59% of
traditional API vulnerabilities require no authentication, what does that mean
for the thousands of MCP servers being deployed without auth controls?

The report specifically flagged one Top 10 API breach that involved thousands of
exposed MCP servers — reinforcing that this is not a theoretical risk.

If you are exposing APIs as MCP tools, you need the same authentication, rate
limiting, and input validation protections you would apply to any production
API. Zuplo's [MCP Server Handler](/docs/handlers/mcp-server) was built with this
in mind: it supports OAuth authentication through Zuplo's built-in OAuth
policies and runs your MCP tools through the same policy pipeline as your API
routes. No separate security configuration, no bolted-on auth — the same
protections applied to your APIs automatically extend to your MCP endpoints. Our
guide on
[mapping REST APIs to MCP tools](/learning-center/mapping-rest-apis-to-mcp-tools)
covers the practical patterns for doing this securely.

## Rate Limiting and Resource Abuse Are Climbing

Another notable shift in Wallarm's 2025 data: "Insecure Resource Consumption"
climbed to the number four position in their top attack categories, with
cross-site issues taking the top spot for the first time, followed by injection
attacks and broken access control.

The resource consumption trend is significant because it reflects how attackers
are exploiting APIs at scale. When 97% of API vulnerabilities can be triggered
with a single request and 40% are tied to organized cybercrime, the economics
favor automation. Bots and scripts hammering unprotected endpoints to scrape
data, exhaust resources, or stage denial-of-service attacks against downstream
services.

[Rate limiting](/docs/policies/rate-limit-inbound) is your first line of defense
here. Effective rate limiting is not just a "nice to have" traffic management
feature — it is a security control that bounds the damage any single actor can
inflict. Combined with authentication, rate limiting transforms your API from an
open target into a controlled surface where abuse is detectable and containable.

At the gateway level, rate limiting should be granular (per user, per IP, per
API key) and enforced before requests reach your backend. This is what
edge-native enforcement provides: malicious traffic is rejected at the edge,
across 300+ data centers, before it consumes your compute resources.

## What You Should Do Now

The Wallarm report makes the threat landscape clear, but the practical response
does not have to be complicated. Here is what matters most, in order of impact:

### Lock down authentication everywhere

Audit every API endpoint. If it is reachable from the internet, it needs
authentication. No exceptions, no "we'll add auth later" endpoints in
production. Use a gateway-level authentication policy so that new routes inherit
protection by default rather than relying on developers to remember to add it.

### Add rate limiting to every authenticated endpoint

Authentication tells you who is making a request. Rate limiting controls how
much they can do. Together, they address both the "no auth required" and
"insecure resource consumption" categories that dominate the report. Apply
[rate limits](/docs/policies/rate-limit-inbound) based on API key or user
identity to enforce fair usage and contain compromised credentials.

### Validate every request against your API schema

With 67% of API vulnerabilities rated High or Critical impact, input validation
is a critical second layer.
[Request validation](/docs/policies/request-validation-inbound) against your
OpenAPI schema rejects malformed payloads before they reach your business logic
— addressing injection attacks and broken access control patterns.

### Secure your MCP endpoints like any other API

If you are running MCP servers, they need the same security posture as your REST
APIs. That means authentication, rate limiting, and input validation. The
Wallarm data shows MCP vulnerabilities are growing faster than any other
category — do not treat MCP differently from your API security strategy.

### Monitor and observe

You cannot protect what you cannot see. API observability — logging every
request, tracking authentication failures, flagging anomalous patterns — is what
turns security policies from static rules into an active defense. Look for
patterns: spikes in unauthenticated requests, unusual geographic distribution,
repeated failed auth attempts.

## The Bigger Picture

As Wallarm Founder and CEO Ivan Novikov put it: "API security is at the heart of
any AI transformation. Every AI application or agent interaction is mediated
through an API."

This is where the security story and the AI story converge. APIs are not just
the most exploited attack surface — they are also the connective tissue for
every AI agent, MCP tool, and model interaction. Securing your APIs is not a
standalone security initiative. It is a prerequisite for everything else you are
building.

The data in the 2026 ThreatStats report is sobering, but it is not surprising if
you have been watching the API security landscape. What has changed is the
urgency. With 43% of actively exploited vulnerabilities targeting APIs and
MCP-related flaws that surged 270% in a single quarter, the window for treating
API security as optional has closed.

The good news is that the fixes are well understood: authentication, rate
limiting, input validation, and observability — applied consistently at the
gateway layer. These are not exotic capabilities. They are table stakes. The
question is whether your current infrastructure makes them easy to implement by
default or hard to maintain by hand.

If you want to see how Zuplo handles API and MCP security at the gateway level —
including [API key authentication](/docs/policies/api-key-inbound),
[rate limiting](/docs/policies/rate-limit-inbound),
[request validation](/docs/policies/request-validation-inbound), and
[MCP with OAuth support](/docs/handlers/mcp-server) — check out our
[API gateway security guide](/learning-center/api-gateway-security-compliance)
or take the [MCP Gateway](/mcp-gateway) for a spin.