Impact of Multiple CSP Headers

Oct 13, 2025 by miodeya.com 126 views

Introduction

Content Security Policy (CSP) is a crucial security feature that helps protect web applications from various types of attacks, such as cross-site scripting (XSS) and cross-site request forgery (CSRF). The HTTP Archive's Almanac provides valuable insights into the adoption and usage of CSP across the web. However, upon reviewing the CSP statistics, we identified two potential concerns that may lead to misleading results. In this article, we will discuss these concerns and explore possible solutions.

Concern 1: Overcounting of `unsafe-inline` Policies

The csp_script_source_list_keywords.sql query counts the number of policies that contain unsafe-inline. While this query is technically correct, it overcounts the prevalence of CSPs that actually allow unsafe-inline. This is because a policy with strict-dynamic automatically ignores unsafe-inline, making it a backwards-compatible strict CSP. As a result, the recommended way of creating a strict CSP is getting flagged as containing unsafe-inline.

Impact of `unsafe-inline` in Nonce-Based CSPs

At Google, we always include unsafe-inline in our nonce-based CSPs. This is likely to lead to an inflation of the unsafe-inline metric, making it less accurate. The inclusion of unsafe-inline in nonce-based CSPs is a common practice, and it's essential to consider this when analyzing the CSP statistics.

Concern 2: Counting Separate CSP Headers

The csp_script_source_list_keywords.sql query selects the CSP headers using UNNEST(response_headers). This means that if a page sets two CSP headers (e.g., one strict nonce-based policy and one allowlist-based policy), those will get counted separately. From a web security perspective, what really matters is that a given page has a nonce-based policy. Therefore, it would be ideal to have a metric that says "What percent of pages have a nonce-based CSP?" rather than a metric that says "What percent of CSPs are nonce-based?"

Impact of Multiple CSP Headers

At Google, many of our services set both a nonce-based policy and an allowlist-based policy. This contributes to the metric calculation method being sub-optimal. It's essential to consider the context in which CSPs are used and how they interact with each other.

Next Steps

We are seeking feedback on these concerns and potential solutions. There are two possible approaches:

Update csp_script_source_list_keywords.sql: We could update the query to accurately reflect the usage of CSPs in the wild. This would involve revising the query to account for the nuances of CSP usage, such as the inclusion of unsafe-inline in nonce-based CSPs and the counting of separate CSP headers.
Save for the next edition of the Almanac: We could save this issue for the next edition of the Almanac, where we can revisit and refine the CSP statistics.

Conclusion

The HTTP Archive's Almanac provides valuable insights into the adoption and usage of CSP across the web. However, upon reviewing the CSP statistics, we identified two potential concerns that may lead to misleading results. By understanding these concerns and exploring possible solutions, we can improve the accuracy and usefulness of the CSP statistics. We invite feedback and suggestions on how to address these concerns and improve the CSP statistics.

Recommendations

Revisit the csp_script_source_list_keywords.sql query: Update the query to accurately reflect the usage of CSPs in the wild.
Consider the context of CSP usage: Take into account the nuances of CSP usage, such as the inclusion of unsafe-inline in nonce-based CSPs and the counting of separate CSP headers.
Provide more granular metrics: Offer more detailed metrics that reflect the actual usage of CSPs, such as the percentage of pages with a nonce-based CSP.

Introduction

In our previous article, we discussed two potential concerns that may lead to misleading results in the Content Security Policy (CSP) statistics provided by the HTTP Archive's Almanac. We received feedback and suggestions from the community, and we're excited to share a Q&A article that addresses some of the most common questions and concerns.

Q: What is the issue with counting `unsafe-inline` policies?

A: The issue is that a policy with strict-dynamic automatically ignores unsafe-inline, making it a backwards-compatible strict CSP. As a result, the recommended way of creating a strict CSP is getting flagged as containing unsafe-inline.

Q: Why is it a problem to count separate CSP headers?

A: From a web security perspective, what really matters is that a given page has a nonce-based policy. Counting separate CSP headers can lead to an overestimation of the prevalence of nonce-based CSPs, making it less accurate.

Q: How does this affect the accuracy of the CSP statistics?

A: The overcounting of unsafe-inline policies and the counting of separate CSP headers can lead to an inflation of the metrics, making it less accurate. This can have significant implications for web security professionals who rely on these statistics to inform their decisions.

Q: What can be done to address these concerns?

A: There are two possible approaches:

Update csp_script_source_list_keywords.sql: We could update the query to accurately reflect the usage of CSPs in the wild. This would involve revising the query to account for the nuances of CSP usage, such as the inclusion of unsafe-inline in nonce-based CSPs and the counting of separate CSP headers.
Save for the next edition of the Almanac: We could save this issue for the next edition of the Almanac, where we can revisit and refine the CSP statistics.

Q: What are the benefits of revising the CSP statistics?

A: Revising the CSP statistics can provide more accurate and useful insights into the adoption and usage of CSP across the web. This can help web security professionals make more informed decisions and improve the overall security of the web.

Q: How can I contribute to the discussion?

A: We invite feedback and suggestions from the community. You can share your thoughts and ideas on the HTTP Archive's GitHub repository or by commenting on this article.

Q: What are the next steps?

A: We will continue to monitor the discussion and gather feedback from the community. Once we have a clear understanding of the concerns and potential solutions, we will revisit the CSP statistics and make any necessary updates.

Conclusion

The CSP statistics provided by the HTTP Archive's Almanac are an essential resource for web security professionals. However, upon reviewing the statistics, we identified two potential concerns that may lead to misleading results. By understanding these concerns and exploring possible solutions, we can improve the accuracy and usefulness of the CSP statistics. We invite feedback and suggestions from the community to help us address these concerns and provide more accurate and useful insights into the adoption and usage of CSP across the web.

Recommendations

Revisit the csp_script_source_list_keywords.sql query: Update the query to accurately reflect the usage of CSPs in the wild.
Consider the context of CSP usage: Take into account the nuances of CSP usage, such as the inclusion of unsafe-inline in nonce-based CSPs and the counting of separate CSP headers.
Provide more granular metrics: Offer more detailed metrics that reflect the actual usage of CSPs, such as the percentage of pages with a nonce-based CSP.

By addressing these concerns and improving the CSP statistics, we can provide more accurate and useful insights into the adoption and usage of CSP across the web.