[W3Conf] Brad Hill: “HTML5 Security Realities”

Avatar of Chris Coyier
Chris Coyier on (Updated on )

Brad Hill (@hillbrad) works at PayPal work works with the W3C on security issues.

These are my notes from his presentation at W3Conf in San Francisco as part of this live blog series.

You can’t read anything about security without huge hyperbole about HTML security. Is it correct? Brad says no. The state of security on the web is better than it’s ever been an HTML5 is largely responsible for that.


Script injectiong (or XSS, or “Cross Site Scripting”) is the most common application vulnerability (~ 95% of all web apps).

“If someone else’s code gets to run in you’re web app, it’s not your web app anymore.”

Current defenses:

  • Input filtering – strip dangerous stuff
  • Output filtering – encode user data so it isn’t treated as markup

There is more of this in HTML5 (hence the hyperbole), but these filters were already broken.

“I just showed you the shore of a continent of horror.”

Book on this subject: Web Application Obfuscation.

“XSS filters were doomed from the start.”

Because: browsers are different, algorithms were secret, browsers have proprietary features, etc.

HTML5 now has an “official” parsing model (for the first time). By standardizing this, it’s a posture change in security on the web.

Content Security Policy (invented by Mozilla, now in W3C). HTTP header to enforce, in the client, a least-privilege environment for scripts and other content. Not a new idea. Brad relates this to the story of Homer, who ties himself to the mast and tells everyone to to listen to anything he says.

The Content Security Policy is like a set of instructions (whitelist/blacklist) of things to ignore/allow. For example, only allow scripts from this domain. Only allow iframes from these other domains (perhaps YouTube and Vimeo). Only allow fonts from these other domains (perhaps your CDN). Reminds me of an app cache manifest file. I had no idea this existed. Apply via meta tag.

Templating is the most common pattern of construction web applications. “They are a hive of XSS vulnerabilities”. There is a new spec for templates that solves this.

Secure Mashups

These type of apps incorporate content from multiple origines under one. Pretty much every app is this, in one way or another.

In the past, Flash allowed this because it had a cross-domain-policy.

“A star (“*”) in your crossdomain.xml is a huge disaster.”

How do you do cross domain in HTML? There has always been a loophole. You can load a script from another domain, and you can put content in that script to use. (JSONP). Brad has been worried about this for a long time but nobody was listening. They listened when Facebook had a huge problem with it a few weeks ago.

Cross-Origin Resource Sharing (CORS) (been around 4-6 years) is the way forward from this.

(We’re using more and more of this on CodePen. This HTML5 Rocks tutorial is awesome.)

“Voluntarily relax the Same-Origin Policy.”

Some say “beware the promiscuous asterisk” in CORS as well, but it’s actually much less of a big deal.

If you need data from elsewhere, there are more options.

  • Sandboxed iframes – <iframe sandbox="allow-scripts" src="different.domain"></iframe>
  • postMessage – window.parent.postMessage(loginName, "trusted.mydomain.com");, test when you get it

“The most important paper in web security in a long time:” Privilege Separation in HTML5 Applications (PDF) by Devdatta Akhawe, Prateek Saxena, and Dawn Song.

“Treat your own code like a mashup.”

There is TONS coming to the future of security. Future = bright.