Bridge WAF
Bridge CDN →
Bridge WAF · part of Bridge CDN

Watch what it would refuse. Then decide to enforce.

Bridge WAF is the web application firewall of Bridge CDN, and you can watch it before you let it refuse anything. It has three modes and nothing hidden between them: off, monitor, and block. Monitor mode records what would have been refused, against your real traffic, so the decision to enforce is made with evidence rather than hope.

Get started See the three modes
Covers off · monitor · block Limits per domain Log: batched, sub‑second

Included with Bridge CDN. Start in monitor: nothing is refused until you decide it should be.

Who is actually asking

Not everything that reaches your origin is a person.
Refuse them all alike and you lose the indexing you depend on. Allow them all alike and you pay for the rest.

Requestspeople and not Automation you wantcrawlers, AI agents → delivered by BotBridge, not inspected Automation you pay forscrapers, stuffing, hammered endpoints → rate limit Automation aimed at youSQLi, XSS, traversal → the three modes Requestspeople and not Automation you wantcrawlers, AI agents→ BotBridge, not inspected here Automation you pay forscrapers, stuffing, hammered APIs→ rate limit Automation aimed at youSQLi, XSS, traversal→ the three modes

Automation you want

Search crawlers and AI agents that read a page to represent it elsewhere. What they need is delivery, not inspection.

Not here: BotBridge serves them prerendered.

Automation you pay for

Scrapers, spam submitters, credential stuffing, an API endpoint hammered by a script. Each request looks ordinary alone; the cost is in the rate.

Answered by rate limiting per domain.

Automation aimed at you

SQL injection, cross-site scripting, path traversal, command injection. Not volume but shape: a request built to make your application do what it must not.

Answered by the three modes.

Before anything else

Traffic that saturates the link never becomes a request.
Nothing here can see it.

A firewall at this layer examines requests. A volumetric attack fills the link before anything is a request, so it is answered elsewhere. If the site is unreachable right now, start with attack layers, not with this page. If requests are arriving and the application is what suffers, this is the layer.

L3 / L4 · saturates the linkVolumetric, protocol floods. Never becomes a request. Not stopped here.
L7 · becomes a requestHTTP flood, slowloris, injection, scraping. Inspected here. This page.
Delivery · prerenderCrawlers and AI agents. A delivery question, answered by BotBridge.
Where you are now

The expensive mistake is not the attack you missed.
It is the customer you refused, who never told you.

Every filtering decision has two failure modes, and they are not symmetrical. Missing an attack is a problem you can see, measure and respond to. Refusing a customer reports itself through nobody: the person leaves, assumes the site is broken, and does not come back to explain.

Enforce first, find out later

The list arrives from customers

A rule set that has never seen your traffic is a set of guesses about who it will refuse.

  • Refusals reported by the people they hit, or by nobody
  • Every rule is a guess until it has seen your traffic
  • The fix ends up being “turn it all off”

Silent failure. The customer is the notification.

Watch first, then enforce

The list arrives before anyone is refused

Monitor converts the guess into lines you read, against your own traffic, while it is still current.

  • Every would-be refusal is a line you read first
  • Exceptions added before enforcement, with an expiry
  • The switch to block stays yours

No surprise. Wednesday’s exception instead of Thursday’s complaint.

Missed an attackvisible · measurable · answerable Refused a customersilent · unmeasured · gone Two failure modes. One of them weighs more, and it is the one nobody reports. Missed an attackvisible · measurableanswerable Refused a customersilent · unmeasuredgone One of them weighs more,and it is the one nobody reports.

Running in monitor first converts that guess into a list. You see which of your own requests would have been caught, which integrations would have broken, and whether the pattern you were worried about appears in your traffic at all.

Web application firewall modes

A mode is the whole configuration surface.
There are three of them, they mean exactly what their names say, and there is nothing else to set.

The same five requests, in each mode. What changes is not the route they take but what happens at the filter, and whether a line is written down.

What arrived

  • POST /api/loginservedwould-block · served403 · refused
  • GET /?id=1+OR+1servedwould-block · served403 · refused
  • GET /servedservedserved
  • POST /searchservedwould-block · served403 · refused
  • POST /webhooks/stripeservedservedserved

What was written down

Nothing is inspected, so there is nothing to write down: every request goes straight to your origin.

What was written down

Each match is written down as would-block, and every request is still served. The list is what you read before deciding to enforce.

What was written down

The same matches are refused at the edge and still written down, so the list keeps growing after enforcement starts.

off

Inspection does not run. Nothing is examined, nothing is recorded, and traffic reaches your origin as it otherwise would.

// no entries

monitor

Requests are inspected and matches are recorded, and nothing is refused. This is the mode that answers the question every security change should start from: what would this have done to my traffic last week?

// recorded, served anyway

block

Requests that match are refused rather than forwarded, and they continue to be recorded.

// refused, still recorded

The order matters more than the list. Turning enforcement on without having watched first means discovering the false positives from customers, which is the most expensive way available to learn what a rule does.

A week in monitor, counted

Before block, the list.
This is what a week of it looks like.

An illustration of the form, not a customer’s numbers. Most of what monitor writes down has the shape of an attack. The lines that pay for the week are the few that do not: your own integrations, found on Wednesday instead of reported on Thursday.

Illustration, not live datawould-block · attack shapewould-block · your own integration
MonTueWedThuFriSatSun MonTueWedThuFriSatSun
1,284would-block lines in seven days
3sources you recognise as yours
2exceptions to add before switching to block

Two of those lines were yours. Found on Wednesday, not from a customer on Thursday.

What the rules match

Named, so you can tell whether any of it is already in your traffic.
In monitor these are written down and served anyway. In block they are refused and still written down.

Present in the example week above · shape matched on what the request is · rate matched on how often

How a request is filtered

The same request, the same route.
What changes is the outcome at the filter.

CLIENT EDGE WAF ORIGIN off monitor block inspect match decide LOG off monitor block CLIENT EDGE WAF ORIGIN inspect match decide LOG

Inspected

The request was examined against the named rules. Happens in monitor and block, never in off.

Recorded

A matching request was written down: time, request, rule. Happens in monitor and block. This is the list the decision is made from.

Refused

The request was not forwarded. Happens only in block, and only after you switched to it.

Edge rate limitingRate limiting is applied per domain,
which is the unit the limits are defined and counted against.

Limits here belong to a domain rather than being derived from something about individual callers, so the question to answer before setting one is what volume the domain as a whole should be prepared to accept. Pick a burst: the allowance refills at a steady rate; a burst spends it; what arrives when it is empty gets a 429.

refill · steady 429 allowance 39 / 40allowance 30 / 40allowance 0 / 40

allowance 39 / 40 · served 1 · 429 0

Limits are counted per domain, not per IP, user or key. If the question you need answered is “how much may one caller do”, that is a different mechanism: see by IP, user or key.

Nothing to tune

Deliberately, and it is a design position rather than an omission.

There is no numeric level to raise or lower, no aggressiveness score to trust, and no dial whose meaning is left for you to infer. This makes the system less adjustable and considerably more predictable, and it removes the class of change where somebody moves a control by one step and nobody can say what that changed.

Here: what changed

Nothing is inspected. Nothing is written down.Every match is written down. Nothing is refused.Every match is refused, and still written down.

What you can set: an exception, with an expiry. What you cannot: a rule of your own, or a level. What is left when it refuses somebody wrongly is finding who was refused, not a control to turn.

The activity log

What was flagged, as it was flagged.

Entries are delivered in batches with sub-second latency, which is what makes monitor mode practical rather than academic: you read the result while the traffic that produced it is still current. The panel replays a stretch of such a log; it is an illustration of the form, not a customer’s data.

Illustration, replayed — not live datarecorded 8refused 3
TimeRequestMatchedModeOutcome
12:04:11.318POST /api/logincredential stuffingmonitorwould-block · served
12:04:11.902GET /?id=1+OR+1SQL injectionmonitorwould-block · served
12:04:12.140POST /searchcross-site scriptingmonitorwould-block · served
12:04:13.005POST /webhooks/stripeAPI abusemonitorwould-block · served · yours
12:04:13.011GET /wp-login.phpcredential stuffingmonitorwould-block · served
12:06:00.000exception /webhooks/stripe——added · expires 30d
12:06:02.418mode—blockswitched
12:07:41.318POST /api/logincredential stuffingblockrefused · 403
12:07:41.560GET /?id=1+OR+1SQL injectionblockrefused · 403
12:07:41.771POST /webhooks/stripeAPI abuseblockexception · served
12:07:42.003GET /etc/passwdpath traversalblockrefused · 403

It is not a traffic overview, not a view of volumetric attack statistics, and not a general analytics surface. Those are different questions with different answers, and a log that tried to be all of them would be worse at the one thing this is for: recording what the firewall flagged, while it is still relevant.

Alongside the alternative

What is three buttons here is a control panel in a rules engine you run yourself.
Both are true, and which one you need is the question this table is for.

Configuration surface, monitor-before-block, rate-limit unit, custom rules and log latency: this layer against a rules engine you install and operate on your own server. No vendor is named; the rows describe the two shapes, not a product.
What you getBridge WAFA rules engine you run yourself
Configuration surfaceThree modesLevels, thresholds, per-rule actions
Monitor before blockBuilt in: the first modeA detection-only switch, if the engine has one
Rate limiting unitPer domainWhatever you write
Custom rulesNoneUnlimited
Log latencyBatched, sub-secondLocal file, immediate
Something to tuneAn exception, with an expiryAll of them
PriceIncluded with Bridge CDNFree software, your server, your time

The caveat that belongs with that table. “None” under custom rules is a limit, not a feature, and it is stated so that nobody discovers it after a DNS change. If your application needs a rule of its own, an allowlist by path or a block on a header value, this layer does not have it, and the other column does.

Is this you

Whether this is worth switching on.
The honest answer depends on how filtering has failed you before, not on how much traffic you have.

Worth switching on

You have turned a firewall off before because it refused someone real. You have a login, a search box, an API, a webhook, and no list of what hits them. Monitor gives you the list before anyone is refused.

Not the mechanism you need

The site is unreachable right now: that is volumetric, a different layer. You need limits per user or per key. You need rules of your own. Or the site cannot be served through Bridge CDN at all. Better to know now.

Worth switching on quietly

Nothing is wrong, nothing is filtered, and nobody knows what would be on the list. Monitor refuses nothing, so finding out costs a week of reading.

Scope and handoffs

Four handoffs, stated so that nobody discovers them later.

L3 / L4Saturates the link. Never a request. Not here: attack layers.
L7 · this layerBecomes a request. Inspected, recorded, refused by mode.
DeliveryCrawlers and AI agents. Prerendered by BotBridge.
Naming · caching · certificatesBridge DNS, Bridge CDN, Bridge SSL.

Volumetric attacks are not stopped here

Traffic that saturates a link never becomes a request, so nothing at this layer can examine it. What does address each family is on attack layers.

Bot and AI-agent delivery is a different layer

Serving prerendered content to crawlers and agents is what BotBridge does, and it is a delivery question rather than a filtering one.

Limits are per domain, not per caller

If the question is how much one IP, user or key may do, that is a different mechanism and it is not here.

It requires the site to be served through Bridge CDN

Filtering is part of serving the site, and the serving layer is Bridge CDN. If the site is delivered from your origin directly or through another CDN, there is nothing here that can stand in front of it.

WAF documentation

This documentation is useful whether or not you ever become a customer,
which is the only reason worth writing it.

DDoS attack types

Sorted by what they exhaust: the link, the tables that track connections, or the application itself. Each family has a different answer, and only one of them is a firewall.

Malicious bots

Scrapers, credential stuffing, spam submissions, and the detection signals people rely on, including what each signal costs when it is wrong.

Rate limiting

What a limit protects, what it breaks, and the decisions to settle before one refuses real traffic.

Operations

The order that keeps customers working, how to read what would have been blocked, and why exceptions need an expiry.

WAF rules

What a rule matches and what it misses: where rule sets come from, how scoring works, and what rules cannot reach.

Comparisons

A firewall, an intrusion system and a request filter look at different things. What each can see, and how to tell which one you need.

Tools

Checks that answer one question each about a site or an address, and the page that explains the result.

Glossary

The words behind the rules, defined plainly and pointed at the pages that cover the mechanism.
WAF for CDN pricing

The firewall layer is included with Bridge CDN rather than sold separately,
so there is no separate plan to choose and nothing to add.

Current terms live where signup does, at Bridge CDN.

WAF questions

What people ask first.

What is Bridge WAF?

The web application firewall and rate limiting layer of Bridge CDN, not a separate product. It has three modes, off, monitor and block; limits apply per domain; flagged requests reach an activity log in near real time. It inspects requests, which is a different job from a network firewall. It is included with Bridge CDN.

I turned a WAF off once because it blocked a customer. Why would this be different?

Because it starts in a mode that refuses nothing. Monitor writes down every request it would have refused, against your own traffic, and you switch to block only when the list says so, with exceptions already in place for the lines that were yours.

What do the three modes do?

off runs no inspection at all. monitor inspects requests and records what matched without refusing anything. block refuses matching requests and keeps recording them. That is the entire configuration surface, so there is no fourth state and nothing to calibrate between the three.

Can I write my own rules?

No. The rules are the named set above; what you can add is an exception, with an expiry. If the application needs a rule of its own, this layer does not have it.

Do the limits apply per IP?

No. Limits are applied per domain, which is the unit they are counted against. Per-IP, per-user and per-key limiting are different mechanisms, described on the rate limiting pages.

How quickly do flagged requests appear?

Close to immediately: entries arrive in batches, each within a second of the request. You can act on what monitor recorded this morning, instead of reviewing a report about what happened yesterday.

Is the activity log a view of attack statistics?

No. It records requests the firewall flagged, which is a different question from how much traffic arrived or where it came from. Volumetric attack figures and general traffic analytics are separate surfaces, and a log attempting to serve all three would serve each of them badly.

Does this handle search crawlers and AI agents?

No, and that is deliberate. Delivering content to crawlers and AI agents is a delivery problem rather than a filtering one, and it belongs to BotBridge rather than here. Keeping the two apart is why neither has to compromise about what it treats as unwanted traffic.

Does it work on a site served from somewhere else?

No. Filtering is part of serving the site, and the serving layer is Bridge CDN. If the site is delivered from your origin directly or through another CDN, there is nothing here that can stand in front of it.

Who runs this, and how to start

Watch first. The list decides. Then block.

Bridge WAF is the filtering layer of Bridge CDN, which covers the infrastructure between a visitor and a server: naming, delivery, certificates, and traffic filtering. Filtering is part of serving your site, so setting it up means setting up delivery.

Get started Start in monitor mode

No separate plan to choose. No dial to set. Requires the site to be served through Bridge CDN.