views:

65

answers:

2

In some of my E-Commerce applications I've started using src="//domain.com/file.js" in cases where I needed to reference externally hosted scripts that I wanted to include. In my E-Commerce applications not all pages actually use https as not every page has a form.

I'm wondering if there's really any disadvantage to always using this, as it's also a shortcut to http and you can always, always avoid the not-secure IE warning.

+4  A: 

If your intent is to load the resources from the same protocol as the page is loaded with, then using it is a perfect way to accomplish it. However, you may need to load some resources from http even when your page is currently served under https (let's say the resouce is served only on http or you prefer to reduce load on your server by not making it encrypt every image on the page). In that case, you need to explicitly specify the protocol name.

Mehrdad Afshari
+2  A: 

@Mehrdad_Afshari Sourcing resources from HTTP can open up injection vulnerabilities from MITM attacks that HTTPS is specifically supposed to protect you from. Classic example is sourcing a script over HTTP, but there have been bugs in the past (see http://www.adambarth.com/papers/2009/barth-caballero-song.pdf) that could allow script injection through an IMG tag by a MITM. Scheme-relative links were specifically recommended in the ForceHTTPS work (https://crypto.stanford.edu/forcehttps/) because of concerns like this.

Scott Wolchok
Yes. I understand. I'm not talking about `<script>` in particular. What if you were linking to a downloadable video file? The overhead may be too high for your server to deal with.
Mehrdad Afshari
I wasn't talking about <script> in particular either. If you actually look at the first paper I referenced, you'll see that old versions of browsers will (bizarrely) treat content delivered by tags other than script as script if the content itself looks like JavaScript and a MIME type isn't sent by the server. Thus, if you don't load such content over HTTPS, there is a possible (but arguably unlikely, depending on your threat model) code injection vulnerability.
Scott Wolchok