The Rationale Behind Selecting CSP
Incident reporting primarily focuses on stolen credentials and unpatched software. However, Cross-Site Scripting (XSS) has remained in the OWASP Top 10 for over a decade. This is because it does not require compromising underlying infrastructure—it only requires a client’s browser to execute a script unintended by the application.
The exploitation mechanism relies on injecting scripts through unsanitized inputs. With persistent vectors (such as comment fields), these scripts are stored and execute automatically in subsequent users’ browsers. With reflected vectors (such as search parameters or query strings), the script executes when a user loads a specifically crafted malicious link. In both scenarios, left unfiltered, these unauthorized payloads can access exposed data such as session tokens, payment forms, and user submissions.
CSP serves as the primary browser-enforced defense against this attack class, neutralizing injected payloads by restricting script execution exclusively to explicitly declared sources. We selected CSP as the focal metric for this study because it directly addresses script execution control with a highly favorable cost-to-benefit ratio.
Methodology and Scope
We wanted a number that was not filtered through vendor marketing or a company’s own claims about its security posture—just what a browser sees when it loads the page.
Target Selection and Dataset
We focused on the .com.ua zone rather than the national .ua domain. This distinction is critical: Ukraine’s registrar only issues .ua domains to holders of a matching registered trademark, effectively excluding most newly formed or small businesses. The .com.ua zone has no such requirement, providing a much better proxy for how an ordinary Ukrainian SME actually looks on the web.
Candidate domains were sourced from public Certificate Transparency logs. From an initial extraction of 150 .com.ua domains, we filtered out unreachable hosts and those redirecting to external targets, resulting in a final dataset of 83 active business websites.
Defining CSP Adoption
We established a deliberately low baseline: a site was counted as adopting CSP if the header was present in its HTTP response, regardless of whether the policy itself was strict or configured with insecure wildcards.
Consequently, the 12% adoption rate represents a ceiling on real protection, not a floor. Assessing the actual security value and configuration quality of these implemented policies remains an open question for future research.
Findings and Comparative Analysis
Of the 83 websites evaluated, 73 returned no Content-Security-Policy header, while 10 implemented it.
To contextualize this 12% adoption rate, we benchmarked it against Bitsight’s 2020 data, specifically their internet-wide baseline and the metrics for the world’s 1,000 most-visited domains. This baseline is corroborated by another 2020 study from Rapid7, which observed a broadly consistent ~7% valid CSP presence across the Alexa Top 1 Million.
Two primary observations emerge. First, the observed Ukrainian SME adoption rate exceeds these historical 2020 global baselines, nearly doubling them. Second, it remains substantially lower than the 24.5% adoption rate demonstrated by top-tier global sites.
(2020)
(2025)
(2020)
This trajectory confirms the broader pattern established by the original research: CSP adoption correlates directly with organizational size and traffic volume, rather than the maturity of the security standard itself.
Check Your Site in Under a Minute
The research highlights the security gap, while this section explains how to close it. To determine whether your website actively deploys this mitigation or remains exposed to baseline injection attacks, execute the following steps.
Open your website in Chrome or Firefox. Press F12 to initialize Developer Tools. Navigate to the Network tab and reload the page. Select the initial document request (your root domain). Inspect the Response Headers section for Content-Security-Policy.
If the header is absent, your site currently lacks this fundamental defense layer.
Implementation Guidelines
WARNING:
The directives in the policy below are intentionally restrictive. Enforcing this configuration as-is (by removing the -Report-Only suffix) is very likely to break existing site functionality as well as third-party integrations (analytics, chat widgets, CDNs, etc.). Always fine-tune the directives based on the violations logged in the browser console before switching to active enforcement.
Below is a restrictive baseline policy configured in report-only mode, structured as a safe starting point for testing on a typical business website:
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests;
This specific policy configuration limits all primary resources—including scripts, styles, images, fonts, network requests, and form submissions—strictly to the site’s own origin. By avoiding any relaxed exceptions or wildcards, it establishes a maximally restrictive baseline for testing. Additionally, directives like object-src 'none' and base-uri 'self' close legacy vulnerabilities like plugin content and <base> tag hijacking.
By establishing a strict “deny-by-default” baseline, this configuration illustrates the standard trade-offs in CSP deployment. Production environments often require loosening specific directives to accommodate CMS core engines, plugins, or third-party integrations, though any such relaxation requires a clear understanding of the resulting security risks. Conversely, depending on the application’s threat model, certain parameters can be tightened even further, such as restricting frame-ancestors to 'none' instead of 'self'.
Once you have fine-tuned the directives and legitimate traffic no longer triggers console errors, rename the header to Content-Security-Policy to begin actual enforcement.
Note that a header which is present but configured with 'unsafe-inline' or wildcard sources provides little real protection—which is exactly why the 12% adoption figure reported in this study should be read as an upper bound on protection, not a scorecard of which sites are actually safe.
What this study doesn’t claim
A few things worth keeping in mind before drawing bigger conclusions from this:
- 83 sites is a snapshot, not a census of the
.com.uazone—it’s an exploratory sample, not a statistically representative one. - We measured whether the header was present, not whether the policy inside it was well-configured. A weak policy still counts toward the 12%.
- Sourcing domains from Certificate Transparency logs means the sample only includes sites using TLS—HTTP-only sites weren’t measured at all.
- This is a single point in time (March 2025) compared against a 2020 baseline; a five-year gap means the comparison shows direction, not a synchronous head-to-head.