What is a WAF? How are firewalls, WAF, and CDN different

The three terms are often used interchangeably, but they sit in different places and look at different things.

2026-09-06Insights

Think of your IT system as an office building. The gate guard controls who can enter the building. The website is the one office inside the building that's open to outside visitors, and it has its own front-desk security who only watches people entering that office and checks whether the forms they fill in carry anything harmful. Regional reception outposts let visitors check in closer to home, and fake visitors get absorbed there. These three roles are the firewall, the WAF, and the CDN.

The short answer first: a three-column comparison

Each one sits in a different position, and none can substitute for the others.

Firewall

Looks at the source address and port of a connection and decides whether to allow or block the whole thing. It doesn't look at content.

Controls who can enter the building
WAF (Web Application Firewall)

Understands the content of a web request: URL parameters, form fields, cookies, and API data, checking whether it carries attack payloads.

Understands web page content
CDN (Content Delivery Network)

Puts website content on the node closest to the user, so visitors check in nearby; fake traffic gets absorbed here.

Check-in point closest to the userAbsorbs fake traffic
Diagram: division of labor between firewall, WAF, and CDN Traffic entering from the internet passes through three checkpoints in order: the CDN's global outposts, the firewall, and the WAF, before reaching the website and API. Each checkpoint checks something different, and none can replace the others. Internet Real users Attack scripts High volumes of fake traffic CDN global outposts Catches traffic close to each country, blocking some of it before forwarding the rest inward High-volume fake traffic (DDoS) is absorbed right here so it never clogs the data center Firewall Controls "who can enter the building": source address, port, protocol Looks at the connection itself. To it, web page content is just ordinary traffic that it can't read WAF Web Application Firewall Reads web page content: checks what every request sends in SQL injection, cross-site scripting, malicious bots, credential stuffing, API abuse, skimming scripts planted on checkout pages Websites, app back ends, and APIs Only clean traffic reaches this point The three checkpoints check different things, and none can replace the others

The firewall handles connections, the WAF handles content, and the CDN handles traffic volume. Most businesses already have a firewall; what they're missing is the layer that understands web page content.

Why a firewall can't stop website attacks

For a website to operate, its public web port has to stay open to the whole world. An attacker doesn't need to force a door. They walk straight through the front entrance, using a web request that looks identical to any regular visitor's. To the firewall, that's just normal web traffic, so it lets it through.

The difference is hidden in the form fields. A firewall doesn't parse web page content and doesn't know which field feeds into a database; it can't tell whether the "product name" box contains "ballpoint pen" or a database command. The gate guard doesn't flip through the papers a visitor is carrying.

What a WAF actually blocks

  • SQL injection: the search box is meant for a product name, but an attacker enters a database command instead, tricking the site into pulling out the entire member list.
  • Cross-site scripting (XSS): the attacker posts a piece of code on a message board, and every visitor's browser runs it on the attacker's behalf.
  • Malicious bots: ticket-grabbing scripts buy out inventory the instant sales open, and price-scraping crawlers copy your price list every day.
  • Credential stuffing: usernames and passwords leaked elsewhere are tried one by one against your login page, and a successful attempt looks like a normal login.
  • APIs (application programming interfaces) getting exploited: a mobile app's back-end API has no visible interface, but once it's traced, it can be called directly to pull large amounts of data in one go.
  • Card-skimming JavaScript planted on checkout pages: a third-party script is tampered with, so when a card is charged, the card number goes to the payment processor and to the attacker at the same time.

When you should add one

  • You have a public-facing website collecting form submissions: registration, sign-ups, orders, customer service messages.
  • You have a mobile app or a front-end/back-end-separated website, meaning you have a publicly exposed API.
  • You need to comply with PCI DSS (Payment Card Industry Data Security Standard), which requires public-facing web applications to have a mechanism for detecting and blocking attacks.
  • You've already been hit once: spam comments flooding in, data pulled out, pages defaced.
  • An auditor or customer's security questionnaire asks whether your web application has a WAF.

Common misconceptions

"I have an SSL certificate, so I'm safe": a certificate encrypts the transmission, protecting it from being intercepted along the way, but it doesn't check whether the content is good or bad. An attack payload can just as easily arrive encrypted.

"My site is too small for anyone to attack": most attacks aren't targeted at you specifically. Scanners knock on doors across the internet, checking which ones are unlocked.

"We already have a firewall": the two operate at different layers. The generic web rules bundled with a next-generation firewall aren't tuned to your website's specific fields.

How to fit the three layers of protection into your existing architecture depends on where your traffic comes from and the state of your data center.

View Web & API Protection (WAF) How to choose among the three protection layers Ask about protection planning
← Back to Insights
LINE Ask us on LINE