OWASP AJAX Security Guidelines
- 1 AJAX Security Guidelines
- 1.1.1 Use .innerText instead of .innerHtml
- 1.1.2 Don't use eval
- 1.1.3 Canonicalize data (read: encode before use)
- 1.1.4 Don't rely on client logic for security
- 1.1.5 Don't rely on client business logic
- 1.1.6 Avoid writing serialization code
- 1.1.7 Avoid building XML dynamically
- 1.1.8 Never transmit secrets to the client
- 1.1.9 Don't perform encryption in client side code
- 1.1.10 Don't perform security impacting logic on client side
- 1.2 ASP.NET
- 1.3 Java
- 2 Project Contributors
- 3 Project Sponsor
AJAX Security Guidelines
There is a complete lack of guidelines for AJAX. This document will provide a starting point for AJAX security and will hopefully be updated and expanded reasonably often to provide more detailed information about specific frameworks and technologies.
Use .innerText instead of .innerHtml
The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.
Don't use eval
Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.
Canonicalize data (read: encode before use)
When using data to build HTML, script, css, XML, Jason, etc. make sure you take into account canonicalization. Data should be properly encoded before used to prevent injection style issues.
Don't rely on client logic for security
Least ye have forgotten the user controls the client side logic. I can use a number of browser plugging to set breakpoints, skip code, change values, etc. Never rely on client logic.
Don't rely on client business logic
Just like the security one, make sure any interesting business rules/logic is duplicated on the server side less a user bypass needed logic and do something silly, or worse, costly.
Avoid writing serialization code
This is hard and even a small mistake can cause large security issues. There are already a lot of frameworks to provide this functionality. Take a look at the JSON page for links.
Avoid building XML dynamically
Just like building HTML or SQL you will cause XML injection bugs, so stay way from this or at least use an encoding library to make attributes and element data safe.
Never transmit secrets to the client
I hope this is a "duh" item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.
Don't perform encryption in client side code
Use SSL and encrypt on the server!
Don't perform security impacting logic on client side
This is the overall one that gets me out of trouble in case I missed something :)
Avoid writing serialization code. Remember ref vs. value types!
Writing serialization code in .NET seems not to hard and yet everyone gets it wrong. Look for an existing library that has been reviewed. I'll post more on that as I eval them.
Services can be called by users directly
Even though you only expect your AJAX client side code to call those services the users can too. Make sure you validate inputs and treat them like they are under user control (because they are!).
Web service calls are not schema verified
You need to use a 3rd party library to validate web services.
Check out OWASP .NET Web Service Validation.
Avoid building XML by hand, use the framework
Use the framework and be safe, do it by hand and have security issues. Simple.
Avoid building JSON by hand, use an existing frameworl
This is to hard to get wrong. Use existing code for this. Check out the JSON site for information.