6

For various reasons, I need to shrink my CSP header a bit without degrading its effectiveness. I'm able to save some bytes by wildcarding some subdomains, but I'm also tempted to strip out all instances of https://.

Example:

connect-src 'self' https://domain1.com https://a.domain2.net https://b.domain2.net https://c.domain2.net https://domain3.net

Could become:

connect-src 'self' domain1.com *.domain2.net domain3.net 

Which is a drop of >50% from 125 B to 56 B.

My understanding is that:

  1. If we're enforcing HTTPS with HSTS...
  2. and mixed content is now upgraded to HTTPS or blocked... (src)
  3. then we shouldn't need to specify HTTPS for each CSP source

However, I'd like to be more confident that this will not undermine the CSP's efficacy from a security perspective.

So, wise wizards of Stack Exchange, is there something I've missed? Do I need to keep the scheme after all?

1 Answer 1

9

You can safely omit the scheme if the page which sets the CSP header is loaded via HTTPS.

Without an explicit scheme, the scheme of the origin is assumed (it doesn't mean that the scheme can be arbitrary). The matching algorithm for schemes allows an upgrade from an insecure scheme to a secure one, but not a downgrade. So if the original page is loaded via HTTPS, then only HTTPS URLs are permitted. Note this is true for all CSP directives, not just connect-src.

To ensure that the initial page is transmitted via HTTPS, use HSTS preloading.

You must log in to answer this question.

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