We take security very seriously with DWR and thought it was worth explaining the steps we have gone through to avoid mistakes. Out of the box DWR protects users against CSRF and XSS attacks. We take steps to ensure that methods on the server are only executed when they should be and that scripts sent to browsers are only sent to the correct browsers.

First DWR takes the view that you should always know exactly what is being remoted, and how. The principle is that DWR should only be calling methods on your code with your explicit permission.

dwr.xml requires you to have a 'create' entry for each class that it remotes. You can further refine this by specifying include and exclude elements which give you fine-grained control over exactly which methods are called on your remoted beans.

In addition to this if you wish to allow DWR to convert your Java Beans to and from Javascript you need to give it permission, and again there is fine grained control over which properties of the beans get converted.

An obvious point, but one that is worth making - don't run with the test/debug console turned on in a production environment. Turning the debug console on and off is covered in the section on web.xml configuration.

Security Support

DWR has a mailing list designed specifically for discussing security issues. It is designed so that we have a way to discuss DWR security while minimizing the dangers associated with wide public dissemination. The list is not about keeping problems secret forever, but it is about responsible disclosure.

Further information about DWR mailing list and the security list in particular is available on the help and support section.

Auditing - DWR's Big Benefit

It is worth comparing DWR with servlets, JSPs or other web frameworks.

If you wish to audit the DWR based functions it's fairly easy. Look at dwr.xml and you can get a simple description of which methods are exposed to the outside world. You can also see the full extent of what is accessible using DWR.

However asking the same question of other systems is not as simple. With servlets you need to examine your WEB-INF/web.xml file and then look through the servlets looking for the calls to request.getParameter(...), with struts and other frameworks you need to examine the config file, and then follow a similar process of looking over the source to see what happens with the request information.

Access Control

DWR allows you to grant access using two J2EE based mechanisms. Firstly you can define access to dwr based on J2EE roles. Secondly within DWR you can define access to methods on a role basis.

Other Measures

DWR will not let you give create or convert access to any of its internal classes. This is designed to make it impossible to accidentally allow an attacker to manipulate the DWR core files to elevate permissions.


What opportunities does an attacker have to exploit your system? Using DWR an attacker can cause the server to create an instance of any Java object that you specify in your dwr.xml, and (if you are using the BeanConverter) any Java object that is in any of the parameters to the methods to those classes. Any of the properties in those classes can then be set with whatever data the attacker uses.

This is all a fairly obvious conclusion if you think about what DWR is doing, but it could cause problems to the unwary. If you create a FileBean with a appendStringToFile() method and export it using DWR, then you are giving an attacker a simple method of filling your file-system up.

It is important to think about the options you give attackers as a result of using DWR.

Generally speaking this type of scenario may make DWR sound risky, however generally speaking the same issues will exist with traditional web architectures, it's just that they are less obvious and so less likely to get fixed.

But I'm Paranoid

That's probably healthy; so what can you do to be extra double sure?

You can guard against failures in DWR access mechanisms by separating the classes accessed by DWR into a separate package and have them proxy to the real code. You can double check role based security yourself if you wish. These options just double up on checks already made by DWR.

Better than double checking might be to audit the DWR source to ensure that the checks it is doing are correct. The code has been checked over by several people already, but more eyes will always help.


While we take security very seriously we do not claim that DWR is totally secure, and we would be foolish to do so. The security of your web site is your responsibility. DWR can help you by providing source code under an open source licence that you can investigate for yourself, and we encourage you to do this, as many already have.