Security on any server is a core requirement, and Jaxer is no different. Although only in beta, Jaxer has been designed with security in mind, as well as ease of use and extensibility. And like any other server, even if architected for security, it does not relieve developers from thinking hard about what to make available to users and how to guard against attacks.

Here are some key security design features of Jaxer:

• Jaxer centralizes and automates the wrapping and unwrapping of data for transmission over HTTP(S), as well as the decision of which functions to call and whether they are allowed to be called. It uses native JavaScript structures on both ends to minimize the chances of a mismatch between e.g. what the browser is sending and what the server receives. The usual problems of escaping data across multiple languages and handling exceptions during callbacks are eliminated.
• While Jaxer unifies the development paradigms of client and server, it does not at all "replicate" the server environment on the client. In fact, server-side code never leaves the server, nor is there any automatic synchronization of data or DOM between them, which could lead to inadvertent security breaches. Any sensitive code can stay on the server and be proxied, if necessary, to the client. Because it's so easy to do this and to control what runs where, there are few barriers to doing it the right way. Of course that also means developers should not simply proxy all their server-side functionality — that would be like exposing their entire back-end API to the internet. Like with conventional approaches, developers need to carefully consider what web services they make available — but with Jaxer, implementing the decision is really, really easy.
• To be clear: Only functions marked explicitly as callable are accessible from the browser.
• Usually when we think of Ajax we're thinking of HTML and JavaScript in the user's browser, over which the developer has little visibility and no control. But JavaScript running on the server is in a known, controlled, protected server-side environment, usually behind a firewall and subject to policies and monitoring.
• Browser pages can only access functions explicitly made accessible on those same pages (but you can share code of course —explicitly)
• The Jaxer DB API encourages the use of prepared statements to eliminate SQL injection attacks, one of the most common weaknesses in web applications.
• Jaxer supports suppressing any detailed error messages that could reveal sensitive information or code from being sent to the browser; you can even just use your own error page.
• If page processing terminates prematurely, a 500 server error is returned to the browser rather than the partially-processed page.