#contentsecuritypolicy — Public Fediverse posts

I am playing around with the CSP - Content Security Policy of my website, actually starting from scratch, for the first time.

I have managed to set the following and the website works:

connect-src
object-src
form-action
base-uri
frame-ancestors

but as soon as I set the following, the website is no longer functional:

default-src
script-src
style-src

has anyone had similar issues and knows what I can look for to make this work? What am I doing wrong? 🤦

#Website #CSP #ContentSecurityPolicy

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

Neu im Forum:
Instanz für gepachte Extensions – wie macht ihr das?
https://forum.t3academy.de/d/657-instanz-fuer-gepachte-extensions-wie-macht-ihr-das
#t3academyforum #TYPO3Extension #ContentSecurityPolicy

#contentsecuritypolicy #csp an important additional line of defense for #webapplication to protect #security and #privacy of your user. You can add them to any web applications (even if you do not have the code!). More information: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

Content security policy for #wordpress: https://jornfranke.codeberg.page/technology-tutorials/wordpress-csp/

Content security policy for your own #springboot and #angular application: https://codeberg.org/ZuInnoTe/spring-boot-angular-example

Setting up CSP headers closer to the client helps - setting up CSP headers as meta tags inside the index.html. This is protecting your website as early in the process as possible.

https://www.youtube.com/watch?v=iHEs4hUIR5Q

#contentsecuritypolicy #websitesecurity

This is a great article to familiarize yourself with the Content Security Policy (#CSP) security concept. Many thanks to #b13 for sharing the well-founded information. #TYPO3 #CyberSecurity #ContentSecurityPolicy
https://b13.com/blog/introduction-to-content-security-policy-csp