Two days ago, a proposal to add "unsafe-webtransport-hashes" to the Content Security Policy specification was merged.

https://github.com/w3c/webappsec-csp/issues/683
https://github.com/w3c/webappsec-csp/pull/791

Here is how I understand the proposal, based on reading it and the documentation for WebTransport. I'm by no means an expert on WebTransport - I had never heard of it before today.

WebTransport is intended to replace Web Sockets; it allows a website to connect to a server over HTTP/3.

One feature of WebTransport is serverCertificateHashes, which is passed as an argument when creating a new socket.
serverCertificateHashes allows a website to bypass the normal public key infrastructure, instead telling the browser what certificates to trust.
It does this, as the name suggests, by providing the hashes of the certificates.

There is, of course, an inherent risk which comes with replacing the existing PKI with DIY. Allowing websites to restrict usage of this feature helps mitigate some of this risk.

This proposal builds on the existing connect-src CSP policy, which controls technologies like XHR, Fetch, etc.

If a website does not set connect-src in its Content Security Policy or doesn't have a CSP, then it can use serverCertificateHashes as it wishes.

However, if it sets connect-src, then serverCertificateHashes is disallowed.

That is where unsafe-webtransport-hashes comes into play. A website can allow specific certificates to be used with serverCertificateHashes by specifying the hashes of those certificates in unsafe-webtransport-hashes, which is part of the CSP and falls under connect-src.

So, as I understand it:

• no CSP or no connect-src: can use any certificates in serverCertificateHashes
• connect-scr set but no unsafe-webtransport-hashes: can not use any certificate in serverCertificateHashes
• connect-scr is set and contains unsafe-webtransport-hashes: only certificates allowlisted in the CSP are allowed for serverCertificateHashes, all others denied

All of this is based on reading the issue thread and doing a little background research. I probably got some of it, or all of it, wrong.
Point being; it is an interesting but very niche proposal.

#WebTransport #WebSecurity #ContentSecurityPolicy #CSP

Interesting learning today about Firefox behavior displaying video content and Content-Security-Policy.

I've got a Garage server which hosts some random content (photos, and now videos in MP4 format); there's an NGINX reverse proxy in front of it. The NGINX configuration includes a very strict CSP (which came from the CSP defaults documented for Mastodon image hosting) which includes "default-src 'none'".

There are four MP4 files in the bucket, ranging in size from 20MB to 882MB, with one at 254MB in between. All of the files except the largest one play just fine in Firefox with that CSP in place.

The largest file, however, starts playback and then a moment later Firefox says "Video cannot be played, file is corrupt.". Of course the file is not corrupt, it's fine, but whatever, writing error messages is not easy.

Using the Network console I could see that Firefox was trying to make at least one secondary request for content from this file, and was blocking itself from making the request because of the CSP! Adding "media-src: 'self'" to the CSP allows this secondary request to proceed, and the video plays fine. From the MDN docs, this CSP entry should only apply to a '<video>' element on the page, and of course there isn't one on this 'page' because this 'page' doesn't contain any HTML at all, but presumably Firefox is synthesizing an HTML page to perform the playback and that page does contain a '<video>' element.

Why this only happens on the largest of the files I cannot really guess.

#Firefox #ContentSecurityPolicy

My newest educational video on the #ContentSecurityPolicy is out on the @phparch #youtube channel. It's a powerful tool that can really increase the #security of your #SaaS applications.

#phpc #phparch

https://www.phparch.com/2025/11/the-secret-header-that-makes-your-php-app-10x-more-secure/

New tool: resource-rewriter

https://lib.rs/crates/resource-rewriter

It takes a single HTML file with inline styles and scripts and rewrites them to be compatible with a more restrictive Content-Security-Policy (and a few other things).

I still have a few more things I'd like to add in, like automated CSP generation, a WASM playground and maybe handling style= attributes. A blog post will follow once that's in place :)

#Rust #ContentSecurityPolicy #CSP

Neu im Forum:

CSP Problem mit Matomo

https://t3forum.net/d/899-csp-problem-mit-matomo

#t3academyforum #matomo #contentsecuritypolicy

I have no patience for dealing with the #RubyOnRails core team, but if •you• do, then…

It would be super if it were possible to append values to the #ContentSecurityPolicy configuration. For example:

```ruby
Rails.application.configure do
config.content_security_policy do |policy|
policy.script_src :self, :https

if Rails.env.development?
policy.script_src << :unsafe_inline
end
end
end
```

Template initializer source: https://github.com/rails/rails/blob/main/railties/lib/rails/generators/rails/app/templates/config/initializers/content_security_policy.rb.tt

Neu im Forum:

CSP für externe Scripte

https://t3forum.net/d/834-csp-fuer-externe-scripte

#t3academyforum #ContentSecurityPolicy #ExterneScripte

Des experts en #ContentSecurityPolicy ?

Pour mon site, j'ai :

<meta http-equiv="Content-Security-Policy" content="default-src https: data: 'unsafe-eval' 'unsafe-inline'; object-src 'none'">

Mozilla Observatory me dit :

Remove unsafe-inline and data: from script-src, overly broad sources from object-src and script-src, and ensure object-src and script-src are set.

Et si je mets :

Content-Security-Policy: default-src 'self';

ça casse mon site, mais je ne vois pas pourquoi. Quelqu'un saurait me dire ce qu'il me faut écrire, les ressources étant toutes sur mon site ?
Merci :)

Apropos of nothing, can anyone recommend any services that aggregate CSP policy reports that are suitable for hobby websites? (i.e. are free, because I just want to do the right thing where I can, and don't care enough to pay for it because it's not vital to operations)

#WebDev #Webmaster #CSP #ContentSecurityPolicy