CSP management gets a dashboard-driven overhaul
Modern web applications routinely pull JavaScript from dozens of third-party sources and submit data to just as many endpoints, which makes client-side security a moving target. Content Security Policies (CSPs) give application owners a browser-enforced mechanism to control what can load and where data can go, but constructing and maintaining those policies in a fast-moving development environment has historically been painful.
Page Shield, Cloudflare’s client-side security product, now supports all major CSP directives, adds automated policy suggestions, improves violation reporting, and introduces role-based access controls. Enterprise customers can start using the new capabilities immediately.
Positive security model, minus the CSP syntax homework
Consider a typical application that embeds Stripe for checkout and Zendesk for chat. Both require JavaScript files to run in the browser and send data back to their own servers. You also serve a first-party script from example.com. Under a positive security model, you want to allow exactly those three script sources and block everything else by default.
Page Shield policies are an abstraction over CSPs that let you express that intent without hand-writing header syntax. From Security → Page Shield → Policies → Create policy, you give the policy a name and optionally scope it with the standard wirefilter syntax. For example, applying the policy only to URI Path contains “checkout” lets you focus enforcement on high-traffic, high-risk pages while you test elsewhere.
Two CSP directives carry most of the load here: script-src (Scripts) and connect-src (Connections). The former dictates where scripts may be loaded from; the latter dictates which endpoints those scripts may reach with data. For Stripe, both resolve to https://checkout.stripe.com.
When you add a directive, Page Shield draws on data it has already collected from your live traffic: if the product is enabled on the zone, it will suggest the JavaScript files and connection endpoints it has observed, presented as a checkbox list. No need to interrogate the development team about what is actually running on the site.
The builder lets you permit whole hostnames or drill down to specific URLs. First-party scripts appear under your own domain in the list, but since self-origin loads are ubiquitous, CSP provides the self keyword shortcut at the top of the builder for a concise policy. After repeating the process for the Connections directive, you deploy the policy in LOG mode for observation or ALLOW mode for enforcement.
Smarter suggestions, narrower policies
The suggestion engine powering that checkbox list is now context-aware. If you scope a policy to checkout pages only, the suggestions update to reflect scripts and connections observed on those pages, not the entire site. That matters because CSPs tend toward bloat, and large policies carry a performance cost in browser enforcement.
The builder also nudges you toward the right level of granularity. When you are loading hundreds of scripts from a single destination, it will propose allowing the hostname rather than enumerating every script URL in the policy.
Directive coverage, from scratch to import
Previously only script-src was supported. Today, Page Shield understands all major CSP directives, listed with their relevant keywords in the dashboard. Suggestions are still generated only for script-src and connect-src; suggestion support for the remaining directives is on the roadmap.
The upgrade-insecure-requests directive is also available. It forces the browser to rewrite HTTP URLs to HTTPS before making requests, which complements Cloudflare’s “Always Use HTTPS” feature: the former works at the origin proxy, while this directive makes the browser itself do the upgrading. The two can operate together.
Existing CSPs are importable. You can paste a full policy into the policy interface, and the system parses every directive into the builder for ongoing edits. Deprecated or unsupported directives produce an error message so you can correct the policy before re-importing.
Violation reporting with context
Deploying a CSP is only half the job; knowing whether it is misconfigured requires reading violation reports. Raw CSP violation streams can be voluminous, and building logging pipelines to digest them is exactly the kind of infrastructure work Page Shield is meant to eliminate.
The product now handles that collection automatically, and the policy overview screen shows which directive triggered each violation, so you can identify problem rules without correlating raw browser reports.
Domain intelligence where you need it
Judging whether a resource is malicious often comes down to domain forensics. The resource details page now surfaces domain WHOIS information and categorization data inline. A recently registered domain receiving connections from your application is a red flag worth noticing quickly; having that context on the same screen as the resource list saves a trip to external lookup tools.
Scoped access for teams
Page Shield deployments no longer require granting broad dashboard access. Two new user roles are now available when inviting or editing users: Page Shield (write/read) for teams that manage policies and Page Shield (read) for teams that only review posture and reports.
Availability
The features described here are part of the Page Shield enterprise add-on. Page Shield itself remains available with a limited feature set to all Pro plan users, and enabling it is a single click in the dashboard. Further detail on each directive is available in the Mozilla CSP documentation.
