External JavaScript: A Blind Spot in Web Security
Modern web applications lean heavily on pre-built JavaScript libraries to ship features quickly. Repositories like cdnjs host thousands of such libraries, and according to W3Techs, Bootstrap alone appears on more than 20% of all websites. Beyond public repositories, SaaS platforms from vendors like Google, Meta, and Microsoft supply their own plugins. Page Shield data shows that large enterprise applications typically load and connect to dozens or even hundreds of distinct third-party destinations for analytics, payments, monitoring, and marketing tools.
This dependency on external code creates a significant attack surface. A single compromised library or SaaS provider can expose thousands of websites that embed it. While attacks like web skimming—often called Magecart-style when targeting payment pages—are well known, traditional application security products focus on the server-side application, not the end user's browser. That leaves a visibility gap that malicious actors exploit through supply chain compromises.
Cloudflare's Page Shield was built to address this gap with detection and alerting for malicious client-side activity. Now the platform is extending its capabilities to prevention with Page Shield policies, which use a positive security model to restrict what browsers may load and execute.
Positive Blocking with Policies
Page Shield policies take advantage of Cloudflare's position as a reverse proxy to enforce rules at the network layer. With a policy in place, browsers will only load and execute JavaScript from a pre-approved list of sources. Any script an attacker manages to inject into a page—whether through a compromised third-party script or another vector—will be refused by the browser. Vetted libraries continue to run without interruption.
Plans also include support for restricting data destinations with these policies, which would prevent browsers from sending data to unauthorized endpoints. That capability targets the exfiltration step in Magecart-style attacks, where stolen data is transmitted to attacker-controlled servers.
CSP as the Enforcement Mechanism
Page Shield policies are implemented using Content Security Policies (CSPs), a standard supported by all major browsers. CSPs are HTTP response headers added to HTML page loads; they contain directives telling the browser what it may execute in the context of that page.
Currently, Page Shield policies support the script-src directive, which controls where JavaScript files may be loaded from. Support for the connect-src directive, which governs where the browser may send data, is being finalized. For example, a page at www.example.com/index.html receiving this header:
Content-Security-Policy: script-src 'self' *.example.com cdnjs.cloudflare.com https://www.google-analytics.com/analytics.js
...allows scripts from the page's own hostname, any subdomain of example.com, all of cdnjs, and one specific Google Analytics script—nothing else. Attackers attempting to load scripts from other hosts would be blocked.
The Content-Security-Policy-Report-Only variant sends violation reports without enforcing the policy, which is useful for testing and auditing before going live. The script-src directive also supports statements like unsafe-inline and unsafe-eval to block inline scripts and unsafe function calls, helping mitigate cross-site scripting (XSS) attacks as well as script injection.
Managing Complexity with Suggestions
CSPs can become unwieldy at scale. Large applications tend to accumulate broad allowlists, and before long the policy becomes so permissive that it loses its protective value. Page Shield policies aim to avoid that trap by simplifying the management workflow.
Policy deployment begins with a filter using wirefilter syntax—the same syntax powering Cloudflare's WAF. This determines where the policy applies, such as a checkout flow or admin pages. Page Shield then uses its collected data to suggest directive values, so building a policy becomes a matter of reviewing a prepared list rather than writing CSP syntax from scratch. A preview shows the full policy before it's committed.
Policies can run in one of two modes: report only/log or enforce/allow. The reporting backend, currently in development, will alert on spikes in violation reports, signaling that a development team may have introduced a new script that needs to be reviewed and possibly added to the allowlist.
Detection Still Matters
Positive blocking policies reduce the likelihood of an attack by shrinking the attack surface, but they are not a complete security solution by themselves. CSPs do not detect malicious activity among allowed endpoints. Page Shield's automated malicious activity detection continues to operate in the background regardless of policy settings, so customers get both preventative control and ongoing threat monitoring.
All Cloudflare paid customers can access a subset of Page Shield features today. It can be enabled under Security > Page Shield. Full Page Shield policy features are available to enterprise customers through their account team.
