The Road Ahead
AJAX is evolving fast and the interactive client has achieved a good level of usability improvements compared to traditional Web applications. Still, AJAX cannot hold a candle to real desktop applications. One gap to close in AJAX is desktop integration, such as interoperability with applications like MS Office. The reality today is that not much software is available as a service, so there exists a need for desktop integration in AJAX. In addition, requirements will come for application security policies to be enforced directly on the client, as well as the requirement for reliable client authentication and client identity propagation. The current client security model doesn't allow this, which is why a server-based security model is advisable for AJAX applications built today.

It is time to move the AJAX runtime environment to the next level to ensure that security meets the need of future Web applications. Otherwise, we will never see AJAX succeeding in becoming a desktop application equivalent. In the following sections, I list improvements I consider useful additions to AJAX security, which allow us to go beyond what is possible today and in the future.

AJAX Runtime Environment
It would help if AJAX applications did not rely solely on a browser. By having an AJAX runtime environment in the form of a browser plug-in, or a stand-alone container, or an embedded container in the OS, AJAX applications could execute in a controlled and trusted environment that comes with limited overhead.

Such an AJAX container can be imagined as a client version of a JEE container that provides client services such as security context and encryption for AJAX applications. It would provide an advanced security infrastructure that allows signed scripts to execute with extended privileges and apply fine-grained, permissions-based access control protection on the XHR object and the DOM. Using an isolated runtime environment to execute client programs in a controlled environment is not a new idea and has been used successfully in technologies such as Flex.

Extra benefits gained from a standardized AJAX runtime environment would be a solution to the current browser incompatibility problem and an option to get rid of unwanted overhead such as browser back buttons and URL fields.

Fine-Grained Access Control to DOM
Today all scripts that are loaded to the client are trusted, which means they are granted full access to the DOM in which they can retrieve visual page elements and JavaScript objects. There is no security context that enforces scripts to access the DOM with the authenticated user rights. This would be needed, for example, to prevent scripts from updating read-only fields.

AJAX Request Method
Instead of encoding AJAX requests in a parameter flag added to the request URL, equivalent XHR methods should be provided for GET, POST, PUT and DELETE. This way AJAX requests are distinguished from Web requests. This can be used to prevent server-side methods from being invoked from URLs typed into a browser URL field.

Signed Content
Because XHR requests can be submitted to the server without the client knowing, it should be possible to enforce signed scripts to be used. Looking forward, signed scripts could provide the security foundation for desktop access and secure cross-domain access.

PKI API
Allow trusted scripts to access public and private keys. In addition, extend the XMLHttp request object to be able to leverage PKI for SSL communication. The latter also requires that the same origin policy can be lowered in a secure way.

Private Scope Objects, Functions, and Variables in JavaScript
Provide a way to define private scope in JavaScript. Private scoped methods, such as those used in JavaScript object encapsulation, should be hidden from Prototype inheritance and access. Objects that are flagged as private should only be accessible within the script file in which they are located. There should be an option to define JavaScript page variables as private so they cannot be accessed from a browser URL field but only from within the page.

OpenAJAX Alliance and W3C
Security in AJAX should be by design and default. Today there is no official standard in AJAX security, which seems odd if this technology is supposed to be used to build enterprise class business applications. The W3C (which holds the specification on the XMLHttpRequest object) and the OpenAjax Alliance (an organization of vendors, open source initiatives, and individual contributors) are suited to handle AJAX standardization. Standards usually develop slowly, but once they exist, they improve the consistency and interoperability of technologies.

Summary
You can build secure AJAX applications today, but you can't have security policies reliably enforced on the client. AJAX applications are Web applications and can inherit security from the JEE business service, allowing robust and road-tested security solutions to be used. The JavaScript security model used on the AJAX client is added on top of JEE security to protect the client from script access to the desktop. The AJAX presentation layer should be kept as simple as possible and should use JavaScript only to make the interactive user interface (UI). You can use JavaScript as a convenience for immediate user feedback upon failed validation, but you should not rely on this.

Undoubtedly, Web 2.0 has changed the way Web applications work and interact with the application user. So-called mashups provide UIs that appear as a single application, though in fact they are composed of software services. Unfortunately, because the browser is not a trustworthy integration layer, a specific AJAX runtime environment in the form of a privileged browser plug-in, an operating system (OS) runtime container, or an AJAX-aware OS should be considered.

Security has to improve with the technology because the desire to build interactive Web applications and mashups don't justify insecure Web applications. Certainly, education is the best security money can buy.

References
•  Open AJAX: www.openajax.org
•  Russell, Alex: http://smokey.rhs.com/web/blog/PowerOfTheSchwartz.nsf/d6plinks/RSCZ-6C5G54
•  van der Stock, Andrew: http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1201083,00.html
•  AJAXian: http://ajaxian.com/archives/210-ajax-frameworks-and-counting
•  W3C Working Draft 27 February 2007: www.w3.org/TR/XMLHttpRequest/