7 Security tips for secure coding your HTML 5 applications

Since the release of HTML 5 standard is expected in 2011, it is important to prepare for the potential impacts on security due the adoption of HTML 5. Currently, we can review the working draft from W3C and start looking at this standard from the secure coding perspective and specifically on how to write secure HTML 5 software. Since this blog is dedicated to software security, I thought I should try to put out a list of top security concerns that need to be addressed when coding applications in HTML 5. Herein included is my top 7 list of software security best practices that need to be addressed when coding HTML 5 applications:
1) Be careful when using cross domain messaging features
HTML 5 APIs allow to process messages from an origin that is different from the one of the application processing the message. You should check the origin of the domain of the message to validate that can be trusted such as by whitelisting the domain (accept only request from trusted domains and rejects the others). Specifically, when using HTML 5.0 APIs such as PostMessage(), check the dom-MessageEvent-origin attribute before accepting the request.
2) Always validate input and filter malicious input before using HTML 5.0 APIs.
You should validate data input before you process any messages of HTML 5.0  APIs such as the PostMessage() API. Input validation should be done at a minimum, on the server side since client side validation can be potentially bypassed with a web proxy. . If you are using client side SQL such as WebSQL (like Google gears for example) you should filter data for any SQL injection attack vectors and use prepared SQL statements. 
3) Make sure that the use of any offline-local storage is secure
Whenever possible, do not store any confidential or sensitive data in the offline-local storage, if you do, make sure you encrypt the data. If you do encrypt the data in the offline-local storage, do not store any encryption keys on the client rather, use the server to encrypt this data on demand. Make sure the encryption key is tied to the user’s session and to the device that is storing it. Beware that HTML 5 offline applications are vulnerable to cache and cache poisoning hence validate the data before putting anything in offline/local storage. If should also consider to restrict the use of offline/local storage as requirement of your HTML 5.0 security coding standards is possible. Consider that right now (Jan 2011), offline-local storage is not supported by IE browsers, only by Google Chrome, Safari, Firefox and the beta of the Opera browsers.
4) Secure code review HTML 5 code and the coding of HTML 5 tags, attributes and CSS.
You should update your secure code analysis rules to include security checks for special HTML coding attributes and HTML 5.0 tags. Some of HTML 5 tags attributes for example can be potentially be injected JavaScript (JS). You should made a requirement to source code review these new HTML 5 tags for security to make sure any JS input is validated. A new version of HTML 5 CSS also might allow an attacker to control display elements via JS injection. HTML 5 source code with tags, attributes and HTML 5 CSS files should be considered in scope for source code reviews before deployment.
5) Consider to restrict or ban the use of HTLM 5.0 websocket API.
HTML 5.0 websocket API provide a network communication stack to the browser that can be used for backdoors. You should check with your security team whether the use of web sockets is allowed by your organization information security policies and application security standards.
6) Make sure your company legal approve any use of geolocation API.
Consider the impact of privacy when using geolocation APIs to make sure the use is allowed and compliant by your company legal-privacy laws/regulations. The use of geolocation might have privacy impacts, hence should be reviewed to be in compliance with privacy policies that might include notify the user when these APIs are deployed as part of your application.
7) Leverage the security of sandboxing iFrame attributes
One of the HTML 5  features is the sandboxing attribute for iFrame that enables a set of extra restrictions on any content hosted by the iFrame. When this is attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled and links are prevented from targeting other browsing contexts and plug-ins are disabled. Ian Hickson, the editor of the HTML 5 has a post on what the sandbox is good for. You should consider updating your organization’s secure coding standards to cover how to code securely applications that leverage the HTML 5.0 sandbox attribute for IFrames.

*** This is a Security Bloggers Network syndicated blog from Writing Secure Software authored by Unknown. Read the original post at: