5

I used SonarQube to perform a static code analysis of my project and it detected a security vulnerability in one of my CSS files:

For security reasons, protocol-relative URLs should not be used.

Noncompliant Code Example

@font-face {
    src: url("//myfont");
}

Compliant Solution

@font-face {
   src: url("https://myfont");
}

See

stylelint Related Rules

Neither link is related to security, and I haven't been able to find an exploit abusing protocol-relative URLs.

This rule was added on September 2016.

Is there any security risk to using protocol-relative URLs in CSS stylesheets?

Community
  • 1
Benoit Esnard
  • 13,942
  • 7
  • 65
  • 65
  • 1
    I guess it's because `//myfont` might make a HTTP request. But it will only do so if you are already on plain HTTP, and then all bets are off anyway. Also, funny things will happend if you are on `file://` but thats not really a security issue. – Anders Sep 10 '19 at 11:56
  • @Anders that would be my guess. I would add that, in almost all cases, it's better to make sure your website always operates over https exclusively. As a result the protocol-agnostic version is unnecessary – Conor Mancone Sep 10 '19 at 12:04
  • 1
    @Anders Well, that was my first guess too. But as you said, there a lot more problems when using plain HTTP... and there's no security warning when a CSS stylesheet includes a plain HTTP link. – Benoit Esnard Sep 10 '19 at 12:10

1 Answers1

6

Your question links to a blog post by Paul Irish, which mentions that this is now considered an anti-pattern. (Since 2017)

Why was // used at all?

The reasoning was that you could write //mysite.com/some/resource and it would resolve to either http://mysite.com/some/resource or https://mysite.com/some/resource, depending on whether or not the site was called with HTTP or HTTPS.

Loading HTTP resources when your site is served over HTTPS can be problematic, as browsers usually complain about websites loading mixed content. Notably IE6 would display a big error message, asking you if you were really sure if you want to continue.

So why not redirect everything to HTTPS?

Because back in 2010, when this blog post was made, HTTPS was considered expensive. Not just because Let's Encrypt didn't offer free certificates back then, but because there used to be quite a performance difference between HTTP and HTTPS. These days, this is not the case anymore, and the overhead HTTPS causes is negligible.

What happens if I use //? Is it dangerous?

Not really, but there is also not reason to use it. The recommendation today is to use HTTPS on everything. Really, there is no excuse anymore to offer plain HTTP aside from redirecting to HTTPS. When browsers finally see HTTPS as the default, then there will be no reason for HTTP existing at all.

  • The old argument was also that if the end user saves the web page on the disk, the browser could then use prefix `//` to refer to file in local filesystem. This would be one kind of Self-XSS which really cannot be prevented in general. – Mikko Rantalainen Jun 15 '21 at 08:14