#contentsecuritypolicy — Public Fediverse posts

🛡️ Content Security Policy in TYPO3

Content Security Policy (CSP) is a security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting of malicious content being executed in the trusted web page context.

➡️ https://docs.typo3.org/m/typo3/reference-coreapi/13.4/en-us/ApiOverview/ContentSecurityPolicy/Index.html

#TYPO3 #contentsecuritypolicy

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

#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

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

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

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

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

@me So the missing css look like a #csp issue.

#ContentSecurityPolicy #MastoAdmin #selfhosted #arghhhhhhh

Wie baue ich eine Content Security Policy (CSP) die nicht die ganze Webseite kaputt macht? :D

#ContentSecurityPolicy #CSP #ITSicherheit #Webseiten #Website #Followerpower

Looking into the current state-of-the-art for #NodeJS security and I'm kind of baffled by how primitive it is compared to browsers.

* No #TrustedTypes.
* No `SafeHtml`.
* No #ContentSecurityPolicy.
* No permission abstractions.
* Not even a way to ban `eval()`.

Best thing I've found is `--frozen-intrinsics`, which is interesting, and I don't think there's a browser equivalent. You still have to freeze `globalThis` though to get much value out of it.

https://nodejs.org/en/docs/guides/security/#monkey-patching-cwe-349

There are also some interesting security policies, which look like they have a lot of potential. However they're all experimental right now and seem focused on code integrity.

https://nodejs.org/api/permissions.html

This this really the state-of-the-art for #Node security right now? Am I missing something?

Content Security Policy is a framework of modern-ish browsers used to give applications an extra layer of security! In this week's blog, we introduce the concept of Content Security Policy and teach some of the technical aspects!

https://www.jumpingrivers.com/blog/content-security-policy-shiny-posit-connect/

#Security #RStats #r #ContentSecurity #csp #ContentSecurityPolicy #community #blog #Shiny

Argh, just spent far too long debugging my CSP settings to figure out why my scripts don't run.
Answer: Browsers really dislike unpadded base64 in the script-src 'sha...' directive and silently reject it, but Digest::SHA generates base64 without padding. (Sure, it's documented ... if you know what you're looking for.)

Solution: Add padding manually.

use Digest::SHA qw(sha256_base64);
my $script_hash = sha256_base64($script_code);
$script_hash .= '=' x (-length($script_hash) % 4); # padding!

#CSP #ContentSecurityPolicy #Base64 #Perl

In 5 years of trying to use a #ContentSecurityPolicy on audioboom.com I don’t believe it’s ever protected us against anything, just flooded me with error reports from bad browser extensions and caused a lot of busywork trying to get thirdparty packages to support nonces, avoid eval() etc. Am I just doing it wrong?

okay, modified an example #chromeExtension #browserExtension to get access to the headers, and modified the #Mastodon #ContentSecurityPolicy to allow unsafe-inline styles as well for now.
Once I get a bit more time, I'll either use a nonce instead, or dump the #userScript into this extension and hash the entire style so I can add the hash to the #styleSrc #CSP instead.

Great, I can no longer use GreaseMonkey to apply #userStyles along with my #userScripts due to the style-src #ContentSecurityPolicy of #Mastodon...
I guess a recent update of #Chrome (I assume) is now enforcing style-self #CSP? Or have these CSPs been added recently?

I hate the current #Web and its decreasing lack of self-control...

@sheogorath

Nice write-up!

The Firefox Laboratory extension to generate CSP header content while browsing a site is very helpful:
https://addons.mozilla.org/firefox/addon/laboratory-by-mozilla/

Another resource I also found useful is https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html

#HTTP #ContentSecurityPolicy #CSP

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

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

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