A request can be valid HTTP and still belong to an unwanted automated workflow. This is not a universal WAF failure. It is a scope question: which evidence does the configured control receive, how much state does it keep, and which application decision must it make?
Modern CDN, WAF, and bot products vary widely. Some include browser challenges, managed identities, behavioral models, or session features. Evaluate the product and plan you run, not a simplified category description.
What a WAF decision can see
The OWASP WAF overview describes a web application firewall as an application firewall for HTTP applications, typically operating as a reverse proxy. That position can provide request and response context useful for application-security rules.
RFC 9110 defines the semantics of an HTTP request. A request may expose a method, target, fields, and message content, but those elements do not prove the operator or purpose behind it.
A configured WAF or bot module may also have access to reputation, verified crawler lists, rate state, browser signals, and prior requests. Confirm the actual scope:
- Does it cover every host, route, method, and origin path?
- Does it inspect only the current request, or correlate a session?
- Which client and browser signals are collected?
- How are identities and allowlists updated?
- Which response actions are available on each route?
- What data is unavailable because of encryption, architecture, or plan limits?
The answers determine the decision boundary more accurately than the product label.
Where straightforward rules work well
Rules are effective when the policy can be expressed using evidence the control sees. Examples include a bounded request rate, a known malicious pattern, a route that should never be public, or a crawler identity that can be verified against current operator data.
OpenAI's crawler documentation, for example, distinguishes GPTBot, OAI-SearchBot, and ChatGPT-User and publishes network data for verification. A rule can use that verified identity as input to a resource policy. The name in the user-agent field alone remains untrusted input.
Rules become less decisive when the same request shape is common to both legitimate and unwanted traffic. A Chromium request from a consumer network is not unusual. Blocking that combination broadly can create false positives, while allowing it broadly can leave the abusive workflow unchanged.
Where a session view can add evidence
Some automation becomes clearer as a sequence. The useful observations may include route order, concurrency, retries, state reuse, navigation depth, interaction timing, and the application actions completed across several requests.
Session evidence can help when:
- the unwanted behavior is defined as a sequence rather than one request;
- the requests can be correlated without unsafe or unbounded state;
- the chosen integration observes the whole relevant path;
- legitimate automation and unusual users are represented in the baseline;
- the response can be applied before material harm occurs.
It does not make uncertainty disappear. Shared devices, changing networks, privacy controls, accessibility tools, and internal automation can produce uncommon sequences. Test each feature against labeled examples and preserve an unresolved state when the evidence conflicts.
Centinel is designed to contribute browser, network, crawler, and session evidence for these decisions. Available evidence and enforcement depend on your integration. A browser component has no authority over a direct request that never runs it, while a server or edge component needs the required application context supplied safely.
Test the gap before adding a product
Begin with a concrete failure case. “Bots get through” is too broad. “This automated cohort completes this expensive route sequence while the current policy allows it” can be tested.
Build a small matrix:
| Cohort | Expected policy | Why it belongs in the test |
|---|---|---|
| Ordinary supported browsers | Allow | Establish normal behavior and completion |
| Privacy and accessibility configurations | Allow or recover | Find legitimate edge cases |
| Approved monitoring or integration | Scoped allow | Prevent damage to required automation |
| Verified named crawler | Route-specific decision | Test identity and purpose separation |
| Stock browser automation | Defined by use case | Establish a reproducible automated baseline |
| Reproduced abusive workflow | Mitigate | Measure the actual gap |
Run the current configuration first. Record enabled controls, versions, expected decisions, reason codes, latency, and downstream work. Add or change one layer at a time. Use observation mode and a holdout where practical.
A successful test includes error review. Count false positives, false negatives, unresolved decisions, challenge failures, and lost legitimate completions. If ground truth is weak, report the uncertainty instead of converting the result into a detection percentage.
Use both layers without creating policy conflicts
When several components participate, give each one a clear responsibility. A common arrangement is:
request and application-security controls
-> automation evidence and session policy
-> route-specific allow, observe, rate-limit, challenge, or deny
-> application
The actual order depends on the integration. Verify how allow rules, cached responses, challenges, retries, and direct-origin access interact. One layer should not silently undo another layer's decision.
Define bounded failure behavior. If classification is unavailable, decide what each resource should do. A low-risk public page and an account recovery operation may need different fallbacks.
Do not buy a category label
A specialist bot product is useful only if its evidence closes a measured gap in the current stack. Ask every provider, including Centinel, to demonstrate:
- coverage of the relevant traffic path;
- the independent evidence families used for the decision;
- behavior on ordinary and approved automated cohorts;
- false-positive review and recovery;
- latency and failure behavior;
- reason codes, retention, and operator controls;
- a safe rollout and rollback plan.
If the current CDN or WAF bot controls already meet those requirements, another layer may add no value. If they do not, use the failed test to specify the missing capability instead of assuming every product in a new category supplies it.
See the configured comparison method for the full test plan and the bot management overview for the broader architecture checklist.