3

I am new to the concept of Content-Security-Policy (CSP) so please forgive my ignorance.

The site https://securityheaders.com parses headers and provides a score. For example unibet.com is awarded a favorable "A" grading while having this security header:

content-security-policy default-src 'unsafe-inline' 'unsafe-eval' http: https: data: wss: blob: jockey: unibetpro: *;

IIUC this basically translates to "allow anything from anywhere regardless, I don´t care", and I would assume it suggest medium or low score.

The securityheaders.com do provide ample warning:

This policy contains 'unsafe-inline' which is dangerous in the default-src directive.
This policy contains 'unsafe-eval' which is dangerous in the default-src directive.

Besides ticking compliance boxes or manipulating automated reviews such as the one above, is there any benefit to having such a permissive CSP over having none at all? Or am I missing something important?

2 Answers 2

2

Assuming that's the whole policy (without follow-up restrictions for specific content types), there is no real-world benefit to the site owner or users. At best, they are deluding themselves. At worst, they are making themselves a target.

That content security policy appears to only exist for the sake of passing an extremely stupid checkbox-based "security" requirement. It is definitely not adding any security; even without the wildcard, it is allowing anything that an attacker could possibly want to do, so it really doesn't matter if it is in fact preventing some things (insecure websockets, I guess?). If the developer thinks it protects them at all - because the scanner marked it as good, for example - then they have literally lulled themselves into a false sense of security.

In fact, I'd argue that a policy like that is at least a major warning sign; while you might think "at least it shows that they care about security at all", in my opinion it shows the opposite. Somebody put in effort to create that non-policy, indicating (to my mind) a lower than baseline level of caring about security. Rather, they only care about appeasing some (extremely stupid) checklist, probably an automated scanner. Imagine you go to some site that handles money, and instead of having some generic statement about security, they specifically told you that they use the "ROT13 cipher"; wouldn't this lower your overall opinion of their security from the baseline?

Since this is the sort of policy that any half-competent security engineer would flag as broken, the site is effectively telling the world "Hey, nobody who can tell web security from a hole in the ground has ever looked at this site!". That is potentially a very interesting fact to any would-be attackers. Since clearly neither the developers nor whatever security auditing tool they are using are any good at their job (at least w.r.t. security), there's probably lots of other gaps in their protection, and likely some of those are actually exploitable. It's effectively a "kick me" sign to anybody who notices.

1

My understanding of this policy is:

  • "Allow only content that matches any of http:, https:, data:, wss:, blob: or custom schemes jockey: and unibetpro: from any origin."

Turns out in practice it is effectively allowing basically all possible schemes of (safe and unsafe) web content, but in the same time maybe not. It's hard to say as people can be really creative.

So yes it's almost equivalent to having no policy at all, but not strictly equivalent.

2
  • 1
    I think the inclusion of schemes does not restrict the wildcard directive here. If that would be the goal, the wildcard should be removed. The inclusion of https: for instance allows for https URL's from any source (equivalent to https://*).
    – Wouter
    Nov 24, 2023 at 16:12
  • 1
    I agree, expressed that way and so extensively it does not restrict much. The goal of the given policy is extremely obscure :)
    – bsaverino
    Nov 24, 2023 at 18:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .