@LowWaterMark: I'm see this in a number of response headers, such as the response to https://www.wilderssecurity.com/threads/content-security-policy-header.384415/. Is this a (new?) XenForo default you are inheriting? Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://ssl.google-analytics.com https://assets.zendesk.com https://connect.facebook.net; img-src 'self' https://ssl.google-analytics.com https://s-static.ak.facebook.com https://assets.zendesk.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://assets.zendesk.com; font-src 'self' https://themes.googleusercontent.com; frame-src 'self' https://assets.zendesk.com https://www.facebook.com https://s-static.ak.facebook.com https://tautt.zendesk.com; object-src 'none' This came up in thread about "Google Tracking", reference https://www.wilderssecurity.com/threads/google-tracking.384408/#post-2571578
That extra header was added in response to the issues raised in this thread: https://www.wilderssecurity.com/threads/security-headers-on-wilders.383010/ The Content-Security-Policy entry is one that was recommended on a security site I used when researching those headers. It does include many standard things like google analytics and others that most websites use. We don't happen to use any of those here, but, I left them in as they seemed pretty standard to me. I did use them on another site where they do have google analytics and such, and it worked for them.
So why not remove stuff in Content-Security-Policy that Wilders doesn't use? Would that reduce the score on https://securityheaders.io/?q=https://www.wilderssecurity.com/
I was actually trying to keep it standard across all the sites I help out on. It makes debugging easier when things are the same on every site. I work on a large number of other forums now. I do forum conversions to XenForo professionally now. But, I suppose I could look at removing some of the excess there.
Hey, I get that But it would make some of the paranoids who use your site happier, maybe. Unless it reduces the score. Maybe there's some way to trick https://securityheaders.io/ This is rather silly, however. As I understand it, the extra stuff in the header doesn't actually do anything. Allowing third-party resources that aren't being used doesn't somehow automagically use them!
Well, those would do something if someone found a way to inject/tamper-with content. Which is obviously possible at some levels. I think related questions would be: How many scenarios would allow for content tampering but not response header tampering. What are the implications of allowing Content-Security-Policy to be specified via meta tag (a feature of Firefox 45 and some other browsers). I don't know enough to answer such questions.
Okay, the edit has been made. Score seems to be the same at the test site. And, I haven't found anything broken on the forum because of it. Even a slight misconfiguration on the Content-Security-Policy header can really mess up a site. When I first implemented those headers a while back, avatar uploads broke. But, they seem to be working okay after this change. Let me know if anyone finds anything broken.
Apart from the little dog being consumed by an energy vortex of some kind, everything appears fine. Step in the right direction too, me thinks
