API Security: Why Your WAF Is No Longer Enough

Why API Security Is Different from Web Security

APIs now carry most dynamic traffic on the internet: Cloudflare’s 2024 API security report found that API calls make up 57% of the dynamic traffic it handles. Yet many companies still protect them with a web application firewall (WAF) built for web pages. API security needs different controls, because the threats, the attack methods and the tools are all different.

A WAF looks for patterns such as SQL injection and cross-site scripting, which are classic web page attacks. APIs face other risks as well: broken authorization, leaked data fields and abuse of business logic. A WAF can’t catch these, because it doesn’t know how your API is supposed to work. So API security depends on tools built for APIs.

This guide covers the five attacks your WAF is likely to miss, explains the OWASP API Security Top 10 in plain words and gives you a checklist to close each gap.

How APIs Differ from Web Pages

A web page sends HTML to a browser, and a person clicks buttons, so the WAF watches that traffic. An API, by contrast, sends raw data between systems, with no browser and no clicks; it is code talking to code. That is why WAF rules written for web pages don’t fit API calls.

APIs also expose more data than web pages. A web page might show one customer’s name, while an API call can return 10,000 records if its access check is weak. So API security needs its own controls.

What Your WAF Misses: 5 API Security Attacks a WAF Cannot Stop

Your WAF is good at what it was built for, but API security wasn’t part of that. Here are five common API attacks it will usually miss.

1. BOLA: Broken Object Access

An attacker changes an ID in the API call to see another user’s data. For example, they change /user/123 to /user/456. The WAF, however, sees a valid request. But the API gave away data it shouldn’t have.

2. Broken Login Checks

Weak login flows let attackers guess tokens or steal sessions. The WAF can’t tell a real token from a stolen one. So the attacker gets in with valid-looking access.

3. Too Much Data in the Response

The API sends back more fields than the app needs. For example, it returns full card numbers when the app only shows the last 4 digits. But the WAF doesn’t check what the API sends back.

4. No Rate Limits

Without rate limits, an attacker can call your API millions of times to scrape your data or overload your servers. A WAF may offer basic rate limiting, but usually not limits tuned to each API route.

5. Server-Side Request Forgery (SSRF)

An attacker tricks your API into calling an internal system on their behalf, which lets them reach systems that should be private. However, a WAF sits at the edge and can’t see those internal calls.

Why WAF Cannot Protect APIs

A WAF looks at traffic patterns, while API attacks abuse business logic with requests that look valid but return data they shouldn’t. So the WAF reports nothing unusual while data leaves through the API.

WAF vs API Security: A Side-by-Side Look

Here is a clear view of what a WAF covers and what it misses for API security.

Threat	WAF	API Security Tools
SQL Injection	✓ Blocks it	✓ Blocks it
Cross-Site Scripting	✓ Blocks it	✓ Blocks it
BOLA (data access abuse)	✕ Misses it	✓ Catches it
Broken login and tokens	✕ Misses it	✓ Catches it
Too much data in response	✕ Misses it	✓ Catches it
No rate limits per route	◐ Basic only	✓ Per-endpoint control
SSRF (inner calls)	✕ Misses it	✓ Catches it
Shadow API search	✕ No visibility	✓ Full API map
Bot and scraping abuse	◐ Basic rules	✓ ML-based detection

The OWASP API Security Top 10 in Plain English

OWASP (the Open Worldwide Application Security Project) publishes a list of the top 10 API security risks, last updated in 2023. Most explanations are very technical, so here is each one in simple terms.

Broken Object Access (BOLA): Users can see other users’ data by changing an ID in the API call.
Weak Login Flows: Poor auth lets attackers steal or guess access tokens.
Object Property Abuse: The API lets users change fields they shouldn’t: like their own role or price.
No Resource Limits: No cap on API calls. So attackers can flood or scrape at will.
Missing Function Checks: Normal users can call admin-only API routes.
Server-Side Request Forgery: The API is tricked into calling private internal services.
Bad Security Setup: Missing headers, open CORS, debug mode left on in live systems.
Unrestricted Access to Business Flows: Attackers automate a legitimate flow, such as buying stock or creating accounts, at a scale that harms the business.
Poor Inventory Management: Old or test APIs left running in production that nobody tracks.
Unsafe API Use: Your API trusts data from other APIs without checking it.

Most Breaches Use the Top 3

BOLA, broken authentication and excessive data exposure sit at the top of the list and show up in many API incidents. So if you can fix only three things, start with these.

Talk to an ExpertAPIs guarded only by a WAF? Find and test every API with us.

Shadow APIs: The Biggest API Security Risk You Can’t See

Shadow APIs are APIs running in production that the security team doesn’t know about. In its 2024 API security report, Cloudflare found nearly 31% more API endpoints through machine learning discovery than its customers had reported. They tend to be old test APIs, forgotten beta routes or APIs built by a team that has since left.

Why Shadow APIs Are So Dangerous

You can’t protect what you don’t know about. Shadow APIs often have no WAF rules, no rate limits, weak authentication and no monitoring, so they are easy targets, and attackers find them quickly with simple scanning tools.

How to Find Shadow APIs

First, run API discovery across all your traffic. Then compare what you find with your API documentation; the gap between the two is your shadow API risk. Also check old staging and test sites, which often still host live APIs.

57%

Of dynamic traffic is API calls (Cloudflare 2024)

31%

More API endpoints found than customers reported (Cloudflare 2024)

OWASP API Security Top 10 risks (2023 edition)

An API Security Checklist for Business Teams

Below is a simple API security checklist for finding and fixing the most common gaps.

Map all your APIs. Find every API in production: known and unknown. You can’t guard what you can’t see.
Add auth to every endpoint. No API should be open without a login check. For example, use OAuth 2.0 or API keys at minimum.
Check access on every call. Don’t just check “is this user logged in.” Also check “can this user see this data.” This stops BOLA.
Set rate limits per endpoint. Cap how many calls one user or IP can make per minute. This stops scraping and floods.
Cut extra fields from replies. Only return the data the app needs. Don’t send full records when the app shows a summary.
Test APIs before go-live. Run OWASP API Top 10 tests in your CI/CD build process. Catch flaws before they reach production.
Monitor API traffic in production. Use runtime API security tools that watch live traffic for abuse patterns, not only known attack signatures.

API security checklist: 57% of dynamic traffic is API calls, 31% more endpoints than known, and five controls from mapping APIs to runtime monitoring — Five controls that close the gaps a WAF leaves in API security.

Key Takeaway API security is a separate layer, not a WAF upgrade. A WAF stops web page attacks, while API security stops business logic abuse, data leaks and authorization flaws that a WAF can’t see. You need both.

How Signisys Delivers API Security for Enterprise

Signisys helps companies find, test and protect every API they run. Here is how the service works.

API Discovery and Risk Mapping

First, we scan all your traffic to find every API: known and shadow. Then we map each one to the OWASP API Top 10 risks. So you get a clear picture of where your gaps are and which ones to fix first.

API Security Testing

Next, we run tests against every API for BOLA, broken auth, data leaks, and rate limit flaws. Also, we test both live APIs and CI/CD pipeline builds. So flaws are caught before they reach production.

Managed WAAP with API Protection

Signisys deploys cloud-based WAAP that covers both web pages and APIs. This includes runtime API watch tools, bot defense, rate limits per endpoint, and format checks. Also, all controls map to RBI API guidelines and DPDP Act needs. So audit-ready proof comes built in.

Our ServiceCybersecurity Services

Common Questions About API Security

Frequently Asked Questions

Why can’t a WAF protect APIs?

A WAF checks for web page attack patterns such as SQL injection. API attacks, however, abuse business logic with valid-looking calls that return data they shouldn’t, so the WAF sees nothing wrong while data leaks out.

What is the OWASP API Security Top 10?

It is OWASP’s list of the 10 most important API security risks, last updated in 2023. Broken object level authorization (BOLA) is number one and broken authentication number two. Many teams use it as a testing standard.

What are shadow APIs?

Shadow APIs are APIs in production that the security team doesn’t know about. Cloudflare’s 2024 report found nearly 31% more API endpoints than customers had reported. Because nobody watches them, they often lack access checks and rate limits.

How do you secure APIs in production?

First, map all APIs. Then add auth and access checks to each one. Next, set rate limits per endpoint. Also, cut extra data from responses. Finally, use runtime API monitoring to catch abuse in real time.

Is API security required for RBI compliance in India?

Yes. RBI requires security controls for payment APIs and internet banking systems. Also, the DPDP Act holds firms liable for personal data exposed through APIs. So API security is both a best practice and a compliance need.

References

57% of Dynamic Traffic, 31% More Endpoints Discovered: Cloudflare — 2024 API Security and Management Report
OWASP API Security Top 10 (2023): OWASP — API Security Top 10 2023

Newsletter

Security Insights, Delivered.

Practical, vendor-neutral analysis of threats, tools, and architecture decisions.