Web Security, Services and AJAX

About This Document

Web security is an ongoing concern of many - site developers, browser developers and everyday users. Some of the basics of Web security have been covered in a previous briefing paper [1]. However, the increasing use of Web Services and APIs in various contexts has led to some novel security concerns, as well as the resurgence of several older issues. This document will discuss a few of the security issues brought up by the use of AJAX and 'Web 2.0' service APIs.

Cross-domain Requests

Since Web services are not hosted locally, consuming data from such services involves making requests to services on other domains. Default security settings in JavaScript disallow this - most browsers will not permit it for security reasons. There are legitimate security reasons for this. If developers wish to overcome this restriction, they typically create a proxy for that service - a server-side script running on their local domain that forwards the request and returns the response. Proxies must be secured against unauthorised use. Many services will ask for an API key or password; be careful with this information and do not make it visible in the JavaScript of your page.

Multi-layered Security

Do not consider the browser as a secure environment; users can read JavaScript - even if it has been obfuscated - and alter it as it runs on their machine. In fact, they can tailor requests that do not make use of the page at all. Therefore, ensure that all the crucial business logic takes place on the server, rather than the browser. You may wish to perform it on the browser to avoid unnecessary crosstraffic between client and server, or for usability/interface reasons, but though this means that the logic has been duplicated, it is important to perform this step again when processing input requests.

According to research by Gartner Inc, 70% of attacks occur via the application layer [2]. Before deploying AJAX, consider the risks and ensure that your project is ready and able to meet the commitment required to complete the task securely. Access control in particular should be considered attentively, as well as communications channels - remember that by default XMLHTTPRequest does not encrypt the data it transmits.

Bandwidth and Speed

Several applications of AJAX have been designed to provide almost real-time input or feedback to the user, or for continuous small updates to be made to a page. When putting together an application using AJAX or frequent service calls in general, add up the amount of bandwidth that will be used during a typical interaction or use of the service.

Fallback Plans

If your service is slow or unavailable - or JavaScript is turned off on the browser - the majority of web applications should still work. The only exception to this is the relatively small subset of applications whose functionality depends directly on input taken from services, such as mash-ups based around maps taken from Google Earth.

Managing Complexity

Because AJAX applications share the business logic between the server and the client, the developers responsible for each element need to work together closely. Developers dealing with technology relatively new to them will need time to produce successive prototypes, since this is a learning process with few authoritative references from which to work.

Conclusions

As with traditional Web applications [3], make security a priority, and plan for maintenance in your budget. When specifying an application, page or component that takes user input, write down a list of possible vulnerabilities and ensure that you have addressed these during the design and build phases. Test your Web applications - both the JavaScript layer and the server-side layer(s). Speak to a security expert if possible, and ensure that you have taken reasonable precautions. A secure application can only be ensured by an ongoing commitment to that aim.

Finally, be conservative with application of novel technologies, and consider a 'feature-freeze' and testing cycle before deployment. New features will also require testing before deployment, so plan to add features only when there is time to audit the result.

References

1. An Introduction to Secure Web Practice, QA Focus briefing document no. 108,
   <http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-108/>
2. AJAX Security, Stewart Twynham, IT Observer,
   <http://www.it-observer.com/articles/1062/ajax_security/>
3. AJAX Threats Worry Researchers, Bill Brenner,
   <http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1207759,00.html>