Security a Concern as HTML5 Gains Traction

From animated logos to Web videos for hip, independent bands, HTML5 is getting buzz and gaining traction. But concerns about the security of features in the new version of the Web’s lingua franca persist. 

From animated logos to Web videos for hip, independent bands, HTML5 is getting buzz and gaining traction. But concerns about the security of features in the new version of the Web’s lingua franca persist. 

Every technology innovation has its coming out party, and Google Inc.’s recent “dancing balls” logo experiment was widely interpreted as a high-impact debut for the next version of HTML, dubbed HTML5. But web security experts are warning that the sprawling new Web standard may favor functionality over security, enabling a new generation of powerful Web based attacks.  

Currently under development by the World Wide Web Consortium (W3C), the Web’s standards-setting organization, the HTML 5 specification is an effort to revamp the Web’s lingua franca after its last major makeover, HTML4, in the late 1990s. The new specification adds features that support the kind of rich interactions and application functions that have become common on the Web, mostly through the addition of third party tools like Adobe’s Flash and Microsoft’s Silverlight platforms. Among the additions to HTML5 are new elements and APIs that will enable two dimensional drawing, native rendering of video and audio files, drag and drop capabilities and offline capabilities for Web applications using local storage and databases.

HTML5 has some major backers, among them: search giant Google. In addition to its eye catching logo animations, that company has lent development talent to the development of HTML5 with projects like the Arcade Fire Web video “the Wilderness Downtown,” which highlight the capabilities of Google’s Chrome Browser, and which Google promoted on its blog. The company has also created a Web site,, to extol the virtues of the new version of HTML.

The new standard does make strides in plugging up some gaping security issues inherited from earlier versions of HTML, said Adam Barth of the University of California, Berkeley, who has been involved with the development of the new specification. 

For one thing, HTML5 actually specifies how HTML code should be parsed by Web browsers. Previous iterations of the language left it up to individual platform vendors to develop their own interpretations of how the code should be parsed, which led to differences in how the language was rendered on different browsers. That also created opportunities for attackers to exploit quirks in the HTML parsing of specific browsers in Cross Site Scripting and other Web based attacks, Barth wrote in an e-mail response to questions from Threatpost. 

New features are also intended to make HTML5 more secure than its predecessors. Among them is a new sandbox attribute that allows Web sites that use iFrames to aggregate untrusted content from external sources to run it in a secured environment. The postMessage() feature, for cross document messaging, allows secure communication between different web sites in the browser, Barth said.  

Web security experts contacted by Threatpost agree that there are security enhancements in HTML5, but all expressed the same concern: that the new specification will greatly increase the “attack surface” of HTML – providing more avenues by which malicious code can be delivered through the Web.

“HTML5 has an enormous amount of functionality. The (specification) is just huge,” said Jeremiah Grossman of Web security firm WhiteHat. The breadth of the new specification gives him concern. “I know that we’re still finding vulnerabilities in HTML4,” Grossman said. 

Others echoed that concern. 

“With any new functionality you’re going to have new security concerns. HTML5 is going to increase the attack surface considerably,” said Neil Daswani of Web security firm Dasient. 

Though no specific vulnerabilities or attacks against HTML5-specific features are documented, experts point to a few areas of concern: 

Local, database and session storage: More options for storing user data locally will make it easier to develop Web applications that can also work in offline environments. They’ll also reduce the reliance on session cookies and improve the performance of Web based applications, which can retrieve data locally instead of having to make requests out to a Web server and retrieve the results.

The conventional wisdom has been that these sensitive data stores will be a rich target for malicious hackers who might leverage cross site scripting attacks or other means to siphon sensitive data from them. Security experts we talked to played down that threat, noting that local storage has been around for a long time with technologies like Flash. However, engineers at Veracode in May raised warnings about an implementation issue with the sessionStorage feature that could make it vulnerable to manipulation from untrusted Web sites. 

The new sandboxing and postMessage() features are examples of tools that, if not used properly, could fail to provide protection against hacks, or even enable new types of attacks. Veracode, in its analysis of HTML5,  raised red flags about the security of the postMessage() feature, as well, noting that Web applications that use cross-document messaging could be vulnerable to attack from malicious Web sites, which could spoof rogue messages. 

Even features, like postMessage() designed to improve security could actually make Web sites less secure if they’re implemented incorrectly, said Isaac Dawson, a security researcher at Veracode. 

“As with any security functionality, over reliance or simple misuse of it could unknowingly make a site less secure,” he wrote. 

In addition, HTML5’s ability to support native rendering of audio and video files could allow attackers to take advantage of security vulnerabilities in supported audio and video file formats for Web based attacks. 

“I imagine we’ll see a lot of people building custom fuzzers for the supported video codecs,” said Dawson. That will put the onus on the Web browser makers themselves – Microsoft, Google, Mozilla and Apple – to review the code used for video parsing and rendering heavily to prevent them from being exploited, he said. 

Grossman, of WhiteHat, also worries about the ripple effects of HTML5 adoption. In particular, the way that new HTML features will break or disable Web security filters that are designed to block malicious activity. In just one example, he notes that HTML5’s broader support of event handlers on HTML elements could defeat blacklist filters designed to allow HTML but block scripting. 

Still, with the HTML5 not finalized and adoption still in its infancy, the full impact of the specification – for good and bad – won’t be felt for years, experts agreed.

Grossman said he sees support for HTML5 in around 10% to 12% of the 2,000 Web sites his firm monitors. It could be three years or more before the security implications of the new capabilities in HTML5 are fully grasped, he said. 

However, HTML5 features could start working their way into the fabric of the Web long before wholesale adoption of the new standard, as Web sites look to take advantage of features, like local storage, on browsers that can support it, Grossman said. 

“Honestly, I think it will make some things better,” said Dawson of Veracode. “But as with all technologies it’s going to take a while for the repercussions of certain designs to be fully known.” 

Suggested articles

biggest headlines 2020

The 5 Most-Wanted Threatpost Stories of 2020

A look back at what was hot with readers — offering a snapshot of the security stories that were most top-of-mind for security professionals and consumers throughout the year.


  • dd on

    Browsers, IM tools, Skype, and other such tools should ALWAYS run under very restrictive permission levels. I don't need my browser writing anywhere on my computer except for maybe one folder (usually). I don't need it changing the registry. I don't need it to be able to unsandboxed execute code.

    So keep it isolated using permissions. That is the the last line of defense against malicious sites.

  • T on

    Start coming up with spcific instances and test cases instead of trying to spread FUD in order to try to validate your position as a security professional, "White hat" people please.

    The spec is still largely open for debate. The spec has not been published as final yet and is a major important step up from HTML 4. Nothing that anyone can say will refute that statement.

     There certainly are challenges facing browser makers but they relish them. Innovation is what drives the open web and the software industry in general (Unless you are in the states where patents are more important than software innovation) yet : there _may_ be a threat IS NOT GOOD ENOUGH. There is ALWAYS a threat.

    Sure, there will be some but actually, if you think about it; there are very few software specifications for open specs which deal specifically with security. Unless you are talking about a security product.

    The bottom line is this : If you find a threat - report it. If you can't find any - don't talk as if there _may_ be one if you didn't find a single specific one because you look and sound as if you don't understand the topic or the spec.

    It is very safe to say that no one with any sense is granting the above quoted subjective opinion piece  any merit based on the fact that _maybe_ is not the same as _fact_.

    Please go read the spec, learn HTML 5  and then go to the W3C with your exploit disclosures. That's how it works.

  • Isaac Dawson on

    @T, In my case I consider the majority threats to be more of in implementation, not of the spec itself. Although it didn't make it into the article, I stated that quite a few times. I think the spec *is* a good thing I think it will remove a lot of legacy issues we've had. The issue is, and almost is always the case, in how developers chose to use the information. The postMessage api is a great example you can still find examples of people writing it without checking the source origin of where the method comes from. If these examples are copied (which I am almost certain they will be) you have a high chance of uninformed developers not knowing the power of the API that they are using, and just assuming it is secure by default. If you need examples, just search postMessage example html5 you'll find a few, granted they may be old, but people will still reuse those examples.

    To note, I have read the spec, and I also subscribe to WHATWG's mailing list, so I am keeping up with how it is progressing.




  • Anonymous on

    Stopped reading when you mentioned google's dancing balls in reference to html5. No html5 was used in that.

  • Anonymous on

    In relation to the post above:

  • Diego Perini on

    Security is a concern now not in the future !

    Can security really be worst than what it actually is ?


  • Andres Galindo on

    Not to sound like an elitist developer, but the bouncing balls on Google's front page are NOT html5 though it does display what would be be thought of as the evolving utility of Javascript.

    Please check your sources before you put something in your articles.

    Besides that, the rest is true but the way it's written is insubstantial, some facts and attack vectors would be nice.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.