Did you know about protocol-relative hyperlinks?

Summary:

  1. (For normal humans) IE and Firefox show perplexing messages on some pages due to a potential security vulnerability in the site you’re visiting. I’ll talk about what it means and how you can get it to go away.
  2. (For web developers) Don’t perplex your users with mixed content warnings. Use protocol-specific hyperlinks to deliver your page resources (images, CSS, Javascript) using the same protocol (HTTP/HTTPS) as the page.

Do you want to only read about this puzzling webpage prompt?

If you use IE8, you’ve probably puzzled over this dialog dozens of times:

Security Warning

In general, the warning is a good thing. Mixed content pages allow passing content between zones. That’s bad.

If added to the DOM, insecurely-delivered content can read or alter the rest of the page even if the bulk of the page was delivered over a secure connection.  These types of vulnerabilities are becoming increasingly dangerous as more users browse using untrusted networks (e.g. at coffee shops), and as attackers improve upon DNS-poisoning techniques and weaponize exploits against unsecure traffic.

Tampering with your HTTPS web page doesn’t just mean via Javascript. An insecure, tampered CSS file could do just about anything it wanted to with how the user views the page.

But this prompt is annoying!

It is annoying, yes. If it’s a site you use frequently, you’ve got some options.

  1. You can disable the prompt (Tools / Internet Options / Security / Custom / Misc / Display Mixed Content / Disable). This would generally be a bad idea since the mixed content warning is trying to help you.
  2. You can trust the non-secure domain (if you do trust it) and then only disable the mixed content prompt from the trusted zone. Remember that this is still a security risk, since HTTP content can be read and modified anywhere between your browser and the server.
  3. If it’s a site that’s under your control, you can fix it.

Fixing the real problem with protocol-relative hyperlinks

The real way to fix the problem is for web dev's to use protocol-relative hyperlinks, such as <img src="//www.google.com/intl/en_ALL/images/logo.gif" /> - that will use HTTPS if the page is HTTPS an HTTP if the page is HTTP, preventing both the security vulnerability and the security prompt. Rather than trying to fix the links in code, we’re relying on a specified and supported HTML feature (RFC 1808, Section 2.4.3, circa 1995)

Article ID: 59, Created On: 6/30/2010, Modified: 11/1/2013

Feedback (0)