One Security Plane, Not a Stack of Products
Application security has long been sold as a collection of point products: WAF, bot management, API protection, client-side security. But the traffic those tools inspect is the same traffic, and the actions they take are the same actions. The product boundaries were useful for go-to-market, less useful for the engineer trying to lock down a modern application that is, at once, a website, a mobile backend, and an API.
Cloudflare is consolidating those interfaces into a single Application Security dashboard. The change reflects an underlying architectural shift: everything is treated as a signal applied to traffic, and all mitigation flows through one rule engine. If you have access to the Cloudflare dashboard, the new Security view is available now, with a toggle to fall back to the previous layout.
What Unification Actually Means
Strip away product names and the security problem reduces to three pieces: traffic, intelligence about that traffic, and rules that act on it.
- Web traffic over HTTP/S is the data.
- Detections and signals – bot scores, attack scores, file upload flags – are metadata generated from that data.
- Security rules combine any piece of metadata with an action: block, challenge, log, or allow.
Every product Cloudflare sells fits into that model as a different detector. Bot Management produces a bot score. The WAF produces an attack score. API security flags missing authentication. When those signals are generated continuously on all traffic, independent of any rule, they become metadata you can query before you ever write a policy.
Running detections ahead of the rule evaluation has two practical benefits. First, cross-signal queries become trivial. Combining the bot score with the WAF Attack Score, for example, reveals who is actually hitting your application and whether that traffic looks hostile. Second, the rule engine no longer cares which product a signal came from. A single rule can reference bot score, attack score, leaked credential checks, or a custom label on a file upload endpoint. Because detections are always on, exploring those signals in analytics acts as a preview: you can see what a rule would catch before deploying it, no log-mode trial run required.
That same approach extends to asset-specific logic. Labeling certain endpoints as file upload targets lets you say, "allow crawlers to index the site, but don't let them submit job applications," by combining the bot score with the upload signal.
The New Dashboard Layout
The redesigned Security area is organized around five views, each built around a task rather than a product.
- Overview aggregates risks, misconfigurations, and ongoing attacks into a prioritized list of suggestions.
- Analytics surfaces suspicious traffic at the top of the page and offers inline workflows to jump from a sampled log entry to a custom rule or related security events.
- Web assets shows discovered endpoints and files, letting you label them so threat detections can distinguish a public product page from a signup form.
- Security rules centralizes WAF custom rules, rate limiting rules, API sequence rules, and client-side rules in one interface.
- Settings puts advanced configuration in one place, organized by security need instead of product silo.
Overview
The new landing page is a daily checkpoint. It prioritizes suggestions across your entire security surface: detected attacks, risky configurations, and gaps in protection. The intent is that you start here, see what needs attention, and drill into the relevant tool from a single click.
Analytics
Security Analytics has been reorganized so that detections from every signal source surface at the top of the view. Filtering down to suspicious traffic is a one-click operation, and the sampled log view below offers actions to craft a rule from a specific traffic pattern or to review related events in context.
Web Assets
Web assets is a new concept that connects business context to detection. An asset is any endpoint, file, or document Cloudflare protects. The page lists what the system has discovered, and you can attach labels – automated where possible – to drive use-case-specific detections, such as stopping fraudulent signups while still letting search crawlers index your catalog.
Security Rules
All mitigation rule types now live on a single page. This gives you one place to see how traffic is being challenged, blocked, or rate limited, and how Cloudflare is preventing malicious client-side resources from loading. New rules can combine any detection signals the platform produces, which means a single policy can express intent that previously required weaving together several product-specific rule systems.
Settings
The Settings page splits the difference between guided defaults and manual control. Recommendations and alerts steer you toward a reasonable posture, but every underlying control is exposed here for teams that need to override the defaults or implement their own standards.
Trying It Out
The unified Application Security experience is available now in the Cloudflare dashboard. Navigate to Security, select “Check it out,” and the new interface takes over. If it doesn’t suit your workflow, the opt-out toggle returns you to the legacy design. Feedback can be left in the Cloudflare community forum or directly in the dashboard when you revert.
This release is the first pass at a broader rework of the Application Security experience. The roadmap ahead includes further refinement of the navigation and rule-building workflows based on usage and feedback.
