Understanding Content Security Policy (CSP) and Its Protective Value
Marketing websites now function as complex software systems rather than simple publishing platforms. As organizations increase their use of automation, personalization, analytics and customer data platforms, we have a growing responsibility to ensure that marketing technology environments are governed responsibly and do not introduce avoidable risk to customer data or brand trust.
At the same time, administrators and teams responsible for websites—especially marketing-driven sites that evolve quickly—must take a practical approach to implementation. Security measures that are "perfect in theory" but too disruptive to deploy in reality tend to get postponed indefinitely. The challenge is to adopt security controls that meaningfully reduce risk while still fitting the operational reality of modern websites.
What is a Content Security Policy?
Attackers don't always need to "break in" through some sophisticated server exploit to cause harm—they can often abuse the browser itself. One of the most important tools available for reducing browser-side risk is the use of HTTP security headers. These headers instruct the browser how to handle content, framing and resource loading.
A Content Security Policy (CSP) is a security header that restricts which resources a page is allowed to load and execute. CSP tells the browser where scripts, styles, images, fonts, frames and other resources may originate—and what to do when the page attempts to use something outside those rules. Unlike many security initiatives that require a complete platform re-architecture, security headers can often be introduced incrementally and enforced at the edge (Content Delivery Network), web server or application layer.
Understanding Common Attacks
CSP is best known for its ability to help prevent Cross-Site Scripting (XSS) attacks. XSS occurs when an attacker finds a way to inject malicious code into a page so it executes in a victim's browser. CSP reduces the chance that an injected script will run by restricting script execution to trusted sources and by blocking patterns commonly used in attacks (such as unexpected inline scripts).
CSP can also help mitigate clickjacking and other injection-based attacks by controlling whether your pages can be embedded in frames and by limiting where embedded content can originate. While CSP is not the only control relevant to clickjacking, it plays an important role in modern browser-enforced protections when configured appropriately.
The Reality of CSP Adoption
Despite the availability of guidance and browser support, CSP is not as widely implemented as it should be. A major reason is complexity: teams may understand CSP is valuable, but the effort and risk of breaking site functionality can delay adoption.
This creates a familiar outcome: CSP is recognized as "important," but remains unimplemented or permanently stuck in an early experimental stage. Complexity becomes a direct barrier to proper security implementation.
What Large B2B Brands Are Doing
To understand how CSP is being adopted in practice, I reviewed the Content Security Policies used by a cross-section of large business-to-business (B2B) brands from around the world. This segment was selected because these organizations typically have the resources to implement security controls well, often operate in regulated or frequently targeted industries, and resemble the types of marketing-driven websites many teams maintain.
The dataset was built by compiling a list of large U.S.-based B2B organizations and augmenting it with a list of large B2B organizations headquartered in Houston, removing duplicates. This produced 138 websites for evaluation. A simple Node.js script was used to load each homepage (following redirects where necessary) and extract the Content-Security-Policy header. A small number of sites blocked automated requests, and those were checked manually.
Because many of these organizations operate in critical sectors and face higher-than-average security scrutiny, the adoption rate in this sample is likely higher than the overall web average.
Interpreting the Results
The goal of this review is to understand adoption patterns, not to single out individual organizations. Some sites may have valid operational reasons for limited CSP deployment, and others may rely on compensating controls to reduce browser-side risk.
In a few cases, policies appeared to be configured primarily to satisfy automated checks rather than to meaningfully restrict behavior; those examples are not identified here.
Audit Results
This audit was performed on February 1st, 2026.
- "CSP" indicates that the header existed on the linked page
- "default-src" indicates that
default-src 'self'was included in the CSP - "Blocks unsafe-inline" indicates that either a
default-srcorscript-srcdirective exists andunsafe-inlineis not used anywhere in the CSP - "report-to" and "report-uri" indicate the existance of a reporting endpoint for monitoring CSP violations
An Overview of the Results
Of those 138, 62% (86) had a Content-Security-Policy header. The rest haven't implemented a CSP, or they've tried and given up. This is surprising when you consider that CSP has been widely available for close to a decade.
How Many Start Off on the Right Foot?
One critical directive that should appear in all CSPs is default-src 'self'. This directive tells the browser not to allow anything (well, almost) unless you have explicitly told it otherwise. Only then should you go back and add additional directives to allow the resources you actually need for your site, using the various *-src directives. Surprisingly, only 28% (39) of the companies in my list included default-src 'self' in their CSPs. The remaining 45 CSPs are likely not as strict as they could be.
Another directive that I would expect in all CSPs is report-to or report-uri. Either of these two directives will tell the browser to report attempted violations of the CSP to a monitored endpoint. This way, you will be notified of any attack or potential problems on your site. report-to is the modern way to handle reporting, while report-uri is more widely supported. Having neither in your CSP is a missed opportunity. I was surprised to find that fewer than 10% (13) of the websites on our list used either directive.
The Low-Hanging Fruit
There are a handful of less well-known directives that aren't covered by default-src, are easy to implement and have valid use cases. There's no reason for not having them:
base-uri 'none'orbase-uri 'self'restricts what domains are allowed in the <base> HTML element. Being able to change the base effectively allows an attacker to load assets from wherever they want, disrupting all instances of 'self' in your CSP. Very few sites ever need to change the base-uri from its initial value, but only 10% (14) of our companies include base-uriform-actionrestricts where forms can send the data that your users submit. There should be very few other places where this data should be sent, so this is an easy one to tackle. Surprisingly, only 7% (10) of our companies have the form-action directive. Start with form-action 'self' and open things up from there as neededframe-ancestors 'none'locks who can load your website via an iframe and prevents some types of clickjacking attacks. There are very few scenarios where your B-to-B site should be loaded into an iframe, so don't skip this one. Just under 46% (63) of our companies included the frame-ancestors directive, but that's the majority of companies that have a CSP.
The Case for Imperfect Security
Risk Assessment
It's tempting to delay CSP until the "perfect" policy is ready. But leaving websites completely unprotected is a meaningful risk—especially when many attacks don't require deep access to infrastructure, only a browser execution path.
Even partial CSP implementation can still reduce the attack surface. A policy that blocks obvious unsafe behaviors, restricts where scripts can load from and limits framing can make exploitation materially harder and reduce the blast radius of mistakes.
The Law of Diminishing Returns
There is a point where additional CSP strictness yields smaller incremental gains while significantly increasing cost and fragility. A basic CSP policy can still protect a site in meaningful ways. It may not eliminate all risk, but it sets a strong defensive posture.
Avoiding Over-Engineering as a Barrier
Over-engineering can become its own security problem. If perfectionism in security implementation prevents deployment, then the security control provides no real protection in production.
A practical security strategy prioritizes deployment over perfect security configurations. The goal is to introduce a CSP that the organization can actually run, monitor, maintain and improve—rather than a theoretically ideal policy that breaks critical site functions and gets rolled back.
A Pragmatic Path Forward: Phased CSP Implementation
Start with Report-Only Mode
A proven approach is to begin with Content-Security-Policy-Report-Only, which allows teams to test policies without enforcement. This provides visibility into what the browser would block—without disrupting real users.
During this phase, administrators can identify violations and monitor violations during the testing phase, revealing unexpected dependencies such as hidden third-party calls, legacy inline scripts or content loaded from domains that were never formally approved.
Monitoring and Gradual Tightening
CSP works best when paired with monitoring. Using violation reporting endpoints helps track policy effectiveness and detect unexpected behavior. This monitoring can also provide early warning of potential attacks or misconfigurations introduced by new deployments.
Over time, teams can progressively restrict sources as confidence grows. This creates a realistic balance: security improves steadily, but operational stability remains protected. The end goal is a CSP posture that reflects real business needs rather than an idealized policy that assumes a static, dependency-free website.
Conclusion: Achieving the Right Balance
In the end, Content Security Policy represents the same balancing act that defines modern marketing technology environments. These websites are no longer simple collections of pages—they are complex systems, and with that complexity comes responsibility.
When applied thoughtfully, CSP becomes a pragmatic control that helps organizations govern the increasingly sophisticated software ecosystems their marketing websites have become. By prioritizing deployment over perfection and accepting reasonable compromises, website administrators can implement meaningful CSP protection that balances robust security with operational feasibility—ultimately protecting their websites and users without creating an unsustainable burden on their teams.
