Content Security Policy header?

Hello everyone,

A question that is not directly related to Sparkle but I’m hoping that someone can help me.
I’m struggling trying to define a content security policy (CSP) for my Apache’ .htaccess headers.
I’ve got the other headers working fine except the CSP.

So far I’ve successfully defined the below and it’s accepted (when testing with

However, when the site loads, I’m missing any text with animation and my menu is not active in addition to an image in a box not being rendered correctly.

Any ideas?

Thanks in advance for any pointers.

I have exactly this question too!
The problem is the INLINE CODE, right?

I’m not sure. CSP is a difficult one to implement.

Are you referring to this?
I have the less secure version already specified (at the very bottom) at least to test, but no luck.


I think I got it working (for my website at least). The site loads with everything intact. I used the below. Change to your website. Keep the wildcard (the asterisk) and give it a try.

Now, I’ll try to refine it and of course I’ll break it :rofl:

default-src ‘self’ *; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ *; connect-src ‘self’ *; img-src ‘self’ *; style-src ‘self’ ‘unsafe-inline’ *; font-src ‘self’ * data:; object-src ‘none’; frame-ancestors ‘self’ *;

In .htaccess it looks like this:

Header always set Content-Security-Policy “default-src ‘self’ *; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ *; connect-src ‘self’ *; img-src ‘self’ *; style-src ‘self’ ‘unsafe-inline’ *; font-src ‘self’ * data:; object-src ‘none’; frame-ancestors ‘self’ *;”

I wonder why you feel the need for a Content Security Policy? Because some website flagged it as missing?

Written like that the CSP is essentially useless, the unsafe-inline allows for everything the CSP is designed to prevent (cross site scripting, as an umbrella term).

For my understanding so far, to make CSP work the site would need to be let’s say “quasi static”, where the site HTTP headers and the page content are generated by say a PHP script, this would:

  • slow down the site somewhat (PHP execution on the server is always going to be slower than a plain static file download)
  • destroy caching (the site content needs to change at every HTTP request)

Now the point of CSP is that in case a hacker finds a way to inject some code into your page, so essentially via user generated content like a blog post comment, guestbook or other content, that code is ignored by the browser due to the CSP.

In general in a Sparkle site that scenario never happens, so I’m not sure I get the point of all this.

1 Like

Exactly. Pointless. It needs a nonce value that ties it to the site scripts and style and whitelist them. That’s why I said I need to refine it, and after researching it further I reached the conclusion that it’s not –easily– doable with what I have. I looked at some other sites too and most of them (almost all) used the “unsafe-inline” in their CSP which contradicts with the whole idea as you pointed out. So why do it if you end up with it not doing anything!

As for why I’m trying to make it work. To me (and I might be wrong), it looks like it affects how a site is rated by search engines for instance, or it appears to be that we’re heading in that direction. A few tools are presenting it when checking a website too (like TLS Inspector) and test sites like WebPage Test. Again, it might not be the case, websites are not my forte and I’m still learning :slight_smile:

Thank you for taking the time to explain it, Duncan. I think I’d leave it at that and won’t waste my time any further, although I’ve learned a few things along the way, so it’s not all wasted :slight_smile:

I don’t know that search engines rate sites based on the CSP, I never heard of it. To me it seems that flagging a site as “unsafe” is a scare tactic to upsell you something.