Do You Need a WAF If You Already Use AWS or Cloudflare?

GUIDES
WAF request path diagram showing four layers and the attacks that reach the application

You already have one. The real question is whether it knows anything about your application, and whether it is still switched on.

  • WAF
  • Application security
  • API protection

The short answer

Cloudflare and AWS give you edge protection that handles volumetric attacks and known signatures well. Neither knows your endpoints, your parameters or what a normal request looks like for your application. Attacks that are well-formed and application-specific pass straight through, and a large share of deployed WAFs sit in monitoring mode after the first false positive.

On this page

  1. What you already have
  2. What gets through anyway
  3. The monitoring mode problem
  4. Negative and positive security models
  5. Shadow APIs
  6. How to decide

What you already have

If you are behind Cloudflare or using AWS WAF with managed rules, you have real protection. Volumetric denial of service is absorbed. Known bad IP ranges are filtered. Generic injection patterns matching published signatures get caught. For a lot of automated background noise, this is sufficient.

One request, four places it could be stopped Internet the request arrives CDN / edge volumetric floods, known bad IPs Managed rules known signatures, generic patterns Your app business logic, auth, data access What reaches your application untouched Requests to API endpoints nobody documented Valid-looking calls carrying manipulated parameters Credential stuffing paced to resemble real logins Logic abuse where every single request is well-formed Every layer above is useful. None of them knows what your application expects.

What gets through anyway

Managed rulesets are built to be safe across every customer using them, which means they are necessarily generic. They cannot be tuned to an application they know nothing about.

So the traffic that passes is the traffic that looks legitimate. A request to an endpoint your inventory does not list. A valid API call with a manipulated identifier that returns another tenant’s data. Credential stuffing paced to resemble ordinary logins. Business logic abuse where every individual request is perfectly well-formed and the sequence is the attack.

The monitoring mode problem

This is the most common failure in practice, and it has nothing to do with product quality.

  1. The WAF is deployed in blocking modeReasonable defaults, managed rules enabled
  2. A rule blocks something legitimateUsually a large customer, usually at an awkward moment
  3. Somebody switches to monitoring to restore serviceCorrect call under pressure
  4. Tuning gets scheduledAnd then deprioritised behind shipping
  5. It logs attacks indefinitely and blocks noneThe dashboard looks busy and healthy

Worth checking today. Open your WAF console and confirm whether rules are set to block or to count. Plenty of teams discover the answer changed during an incident eighteen months ago and never changed back.

Treating this as a discipline failure misses the point. False positives are a design consequence of blocking by generic signature. Fix the model and the pressure to disable it largely goes away.

Negative and positive security models

Negative model block what looks bad Positive model allow what is known good Needs a rule per attack Novel attacks pass by default Rule list grows forever Tuning never finishes Learns your real traffic Unknown patterns refused Adapts as the app changes Fewer false positives A negative model is permanently one rule behind. A positive model inverts the default.

A negative model needs a rule for every attack, which means it is permanently behind. A positive model learns what your traffic actually looks like and treats deviation as suspicious, which inverts the default and closes the window on novel attacks.

Shadow APIs

You cannot protect endpoints you do not know exist. Undocumented endpoints accumulate through ordinary work: a service ships faster than the inventory updates, a deprecated version stays reachable, an internal endpoint becomes externally routable during a migration.

Any protection scoped from documentation inherits the gaps in that documentation. Discovery has to come from observed traffic rather than from a spreadsheet.

How to decide

Your situationReasonable position
Static marketing site, no user dataEdge protection is fine
SaaS application handling customer dataApplication-aware protection is warranted
Public APIs, or partner integrationsDiscovery and per-endpoint policy matter
Multi-tenant architectureObject-level authorisation abuse is your main risk
Pursuing SOC 2 or ISO 27001You need a demonstrable protection control, in blocking mode

How Osto does it

Osto’s WAAP runs as a reverse proxy in front of your application. It discovers applications and API endpoints automatically from real traffic rather than from a list you maintain, then builds a positive security policy from observed behaviour. It covers the OWASP Top 10, DDoS and bot traffic, and the self-configuring policy is what keeps false positives low enough that blocking mode survives contact with production.

It reports into the same platform as cloud posture, endpoint control and code security, so a web-layer signal can be correlated with what is happening elsewhere instead of sitting in an isolated console.

Find out what is reaching your application

A free assessment maps your internet-facing endpoints, including the ones missing from your inventory, and shows what current protection is actually blocking.

Get a free security assessment Book a platform walkthrough

Frequently asked questions

Do I need a WAF if I use Cloudflare or AWS?

You already have edge protection, which handles volumetric attacks and known-signature traffic well. What those default layers do not have is knowledge of your application: which endpoints exist, what parameters they accept, and what a legitimate request looks like. That gap is what a dedicated application-aware WAF addresses.

What is the difference between a CDN and a WAF?

A CDN caches and distributes content and absorbs volumetric traffic. A WAF inspects request content against rules to decide whether a request should reach your application. Many CDNs offer WAF functionality as an add-on, usually with managed generic rulesets rather than policies derived from your traffic.

Why do WAFs get put into monitoring mode and left there?

False positives. A rule blocks legitimate traffic, a customer complains, and the fastest fix is switching to monitoring. The intent is always to tune and re-enable, and it frequently does not happen. A WAF in monitoring mode logs attacks and stops none of them.

What is a positive security model?

Instead of blocking traffic matching known-bad patterns, a positive model learns the shape of your legitimate traffic and permits only what matches. Novel attacks are refused because they do not match known-good behaviour, rather than being allowed because no signature existed for them yet.

What are shadow APIs and why do they matter?

Endpoints running in production that are missing from your inventory and documentation. They appear through fast shipping, deprecated versions left running, and internal endpoints that became reachable. Protection scoped to documented endpoints will not cover them, which is why automatic discovery matters.

Does SOC 2 require a WAF?

Not by name. SOC 2 requires controls addressing system protection and vulnerability management, and a WAF is one common way to demonstrate protection for internet-facing applications. Auditors look at whether the control objective is met rather than at a named product category.

Related reading: SOC 2 controls CC1 to CC9 · VAPT explained

Accuracy note: Capabilities of third-party edge and CDN products change frequently. Verify current feature sets and rule behaviour with your provider. Current to August 2026.