Incorrect hashes generated causing CSP violations

[warnyul]

Description

The CspHtmlWebpackPlugin generates incorrect hashes, causing issues when trying to use the generated CSP.

I have created a GitHub repository to reproduce the issue and deployed the site for reference:

• Reproduction repository: github.com/warnyul/bvarga.dev/pull/59/files
• Deployed site: bvarga-fe600--pr59-csp-m690t8vi.web.app

My observations

If I copy the content of the <style> or <script> tags from the generated index.html into an online CSP hash generator, I get different hash values. When I manually replace the generated hashes in index.html with these correct values, my site works as expected without CSP violations.

I could not prove it but maybe the issue is related to #111

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• testing related
• discussion

Requirements (place an x in each of the [ ])

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

---

Bug Report

Reproducible in:

slackhq/csp-html-webpack-plugin version: 5.1.0

node version: 22.10.0

OS version(s): macOS Sequoia 15.01, Ubuntu 24.04

Steps to reproduce:

1. Clone the reproduction repository: git clone https://github.com/warnyul/bvarga.dev.git
2. Install dependencies: npm install
3. Build the project: npm run build
4. Open index.html in dist folder using Safari or Google Chrome.

Expected result:

The hashes generated by the CspHtmlWebpackPlugin should correctly match the content of the built files.

Actual result:

The hashes generated by the plugin do not match the content of the files, causing CSP violations in the browser when accessing the deployed site. Manually generated hashes work correctly when applied.

[warnyul]

I investigated further and logged the generated hashes in the hash method. I discovered that the processCsp function is called twice during the build. The logs show that the correct hashes are generated, but they appear after the ones currently included in the index.html. Based on this, I think this issue is not related to #111 .

[warnyul]

It seems that removing the following SCSS definitions resolves the issue. With these definitions removed, the CSP plugin and the inline CSS plugin use the same CSS, resulting correct hashes:

> * {
   // style definition
}

[warnyul]

I think I’ve identified the root cause of the CSP violations. It’s related to cheerio when _useHtmlParser2 is set to true. In this mode, cheerio modifies the content of <style> and <script> tags by replacing special characters like <, >, and & with their HTML entities (<, >, &).

This transformation causes a mismatch between the original tag content (used to generate the CSP hash) and the altered content in the output, resulting in CSP violations. We’ll need to address this to ensure the CSP matches the actual content of the tags.

[MarshallOfSound]

Pinning cheerio to 1.0.0-rc.10 fixed this for me (it was working, then I updated some deps and rolled them back till it worked again)

[ecc521]

Pinning Cheerio to 1.0.0-rc.10 also worked for me, no other dependency changes were necessary.