我们很谨慎的对待 DWR 的安全问题，并且认为有必要解释一下避免错误要做的事情。
首先 DWR 让你明确哪些是被远程调用的，是如何被远程调用。原则就是 DWR 必须调用那些你明确允许的代码。
dwr.xml 要求你为每一个远程类定义一个’create’项。你还可以通过指定 include 和 exclude 元素来更精确的控制远程调用 Bean 中可以被调用的方法。
除此之外如果你希望允许 DWR 在转换你的 JavaBean 到 Javascript 或者从 Javascript 转换到 JavaBean时有一定的许可限制，同样可以精确控制哪些 Bean 的属性可以被转换。
一个很明显但又必须指出的 – 不要在生产环境中打开 test/debug 模式控制台。如何打开或关闭 debug 控制台在配置 web.xml 部分可以找到详细描述。
审查 - DWR 带来的最大好处
很值得对比一下 DWR 和 Servlet、JSP 或周围的其他 web 框架。如果你要审查基于 DWR 的功能，那是非常简单的。看看 dwr.xml 你就能得到一个哪些方法被暴露到外面的描述了。你也可以俯视全局用 DWR 可以访问哪些资源。但是要在其他系统里做这件事可不是这么容易。如果是 Servlet 你需要检查 WEB-INF/web.xml 文件，然后检查写在 Servlet 中的 request.getParameter(…)。如果是 Struts 和其他 Framework 你需要检查配置文件，然后顺着流程检查代码，看请求信息出了什么问题。
访问控制
DWR 允许你通过两种基于 J2EE 的机制来进行访问控制。首先你可以基于 J2EE 角色定义 DWR 的访问。其次你可以在 DWR 里面定义访问方法的角色。
其他方面
DWR 不允许你定义任何内部类的 create 和 convert。这样设计是为了不出现意外的攻击来操作 DWR的核心文件以提升访问权限。
风险
有什么机会可以让攻击者窥视你的系统呢？使用 DWR 你攻击者可以使服务器创建任何你在 dwr.xml中指定的Java 对象的实例。并且(如果你用 BeanConverter)Java 类的任何方法、以及方法任何参数都是可见的。这些类的任何一个属性都有可能是攻击者需要的。
如果你知道 DWR 是怎么工作的，这些都是很显而易见的结论，但是往往粗心会造成问题。如果你创建了一个有 appendStringToFile()方法的 FileBean 的类，而且用 DWR 把它暴露出去，那么你就给了攻击者一个机会来填满你的文件系统。
你必须时刻注意用了 DWR 以后，有没有给攻击者什么机会。
一般来说这样的情景让人感觉使用 DWR 是有风险的，但是这样的问题在所有的传统 web 架构中都存
在，只是在那些架构中这些不明显，所以就很难被修复。
保证更加安全
这已经很安全了，那么你还能做什么来保证更加安全了？首先记住上面这些关于审查的内容，当 web应用的其他地方不安全时，即使它看上去很安全，过多的关注 DWR 是很愚蠢的。如果 DWR 让人感觉恐惧，那是因为它的问题都在明处。所以第一步是多检查几遍传统架构的问题。
你可以通过把可远程访问的类放到不同的包里，并且使用代理来防止 DWR 访问机制出问题。如果你愿意还可以再次检查基于角色的安全控制。这些内容只是在检查 DWR 已经为你做的事情。比多检查几次更好的方法是检查 DWR 的源码，保证它是在正确的工作。这些代码已经被很多人检查过了，但多双眼睛总是有好处的。
整合 Acegi
DWR 可以整合 Acegi security framework。更多的信息见整合 DWR 和 Acegi
