...seen that in premium version CSP 'strict-dynamic' is new thing been added but, can you explain me why you add unsafe-hashes to styles ? You said no unsafe-inline and no unsafe-hashes will be in new update, and all use nonces. why is the reason for you add this there?... - WHM/Cpanel user
Seeing your question pop up, let me quickly outline how I’ll walk through it: first recap what 'unsafe-hashes' actually does, then spell out why cPanel’s inline fragments force our hand, and finally lay out the alternatives if we want to revisit the policy.
why 'unsafe-hashes' shows up at all
In CSP terms: 'unsafe-hashes' doesn’t reopen the door to arbitrary inline code the way 'unsafe-inline' does. Instead, it tells the browser, “if you see a hash token matching this inline attribute or block, treat it as allowed.” Without that flag, hash allowances work only for <script>/<style> elements, not for inline attributes or event handlers.
cPanel’s WHM templates ship with inline attributes like onclick="..." and style snippets directly in the markup. Those aren’t coming from our code; they’re baked into the host page we’re loaded into. We can’t rewrite them because the page is authored by WHM itself.
When the browser encounters these attributes, even after we supply a matching 'sha256-…' hash, it will still block them unless 'unsafe-hashes' is present. The spec requires that flag to acknowledge you’re intentionally whitelisting hashed attributes.
why nonces alone don’t solve it
Nonces only apply when you render your own <script nonce="..."> or <style nonce="..."> blocks. They don’t cover attribute-based inline JS or inline style attributes.
WHM doesn’t give us a hook to sprinkle nonces onto their markup, nor to replace the inline attributes with external modules. So even though we add nonces to everything we control, the host’s attributes remain.
the trade-off
We intentionally avoided 'unsafe-inline', which would allow all inline code (a big regression).
By pairing 'unsafe-hashes' with narrow hash lists, we’re still enforcing CSP strictly: only the specific, hashed fragments (which we observed WHM already emits) get through. Everything else stays blocked.
If we removed 'unsafe-hashes', WHM’s built-in UI scripts would fail, breaking functionality (for example, their top navigation toggles and advanced search widgets).
alternative paths
Convince WHM to go fully nonce-based: if future cPanel versions stop emitting inline attributes/styles and instead accept nonces, we can drop 'unsafe-hashes'.
Inject a script that rewrites their DOM: doable but risky—manipulating upstream markup could be brittle and might be flagged as tampering.
Accept partial breakage: we could remove 'unsafe-hashes' today, but WHM users would immediately lose parts of the UI. That contradicts the “keep WHM usable” goal we set.
So, 'unsafe-hashes' is the narrowest possible exception that still keeps cPanel’s stock UI running under a strict CSP. If/when WHM stops relying on inline attributes, we can revisit and remove it.