如果应用框架提供安全支持，那么开发人员将会多么高效？

　　在安全支持这个问题上，尽管当前的框架确实提供了一些价值，但是仍然有许多工作是要做的，来消除像资料隐码攻击、跨站点脚本(XSS)和跨站点请求伪造(CSRF)这样的漏洞。

　　当前，开发框架是安全代码创建的最好支持，但他们不能防止非安全代码的创建。这意味着只有了解标准的框架和可用的安全设施的开发人员，才能更适合创建安全代码这个位置。但通常情况下，开发人员对安全代码实践都了解的比较少—尤其是对框架安全功能的了解—这也会给应用程序带来常见的漏洞。

　　在每个基础漏洞上，这里有一些常用的框架中的设备，这些框架会引入一些安全问题：

　　-SQL注入。像Hibernate这样的对象到关系映射(ORM)库可以提供了一些保护，通过吸引开发人员远离直接操作的查询，来防止SQL注入漏洞。然而，大多数ORM库允许开发人员创建自由格式的查询，但这仍给应用程序的开放留下了注入攻击。

　　-跨站漏洞(XSS)。.NET框架提供了一些开箱即用的XSS的保护，通过ValidateRequest属性可用。这很有用，但因为它依赖于一个已知的无效负载黑名单，这可能会被绕过。因此，开发人员仍然需要正确地编码数据，以防止XSS漏洞。

　　-跨站点请求伪造(CSRF)。Tomcat servlet容器的最新版本CSRF保护过滤器，它提供很多保护来防止CSRF攻击。

　　这是框架和应对策略的一个简单列表，但事实是，对于大部分开发平台，没有很好的标准工具集和库，来防止引入公共类的漏洞。

　　这一领域中的一项有趣的开发是来自于的playdoh项目。Playdoh是基于Django Python Web应用框架的一个Web应用模版。开发人员在Playdoh中建立应用程序来访问所有的Django的安全设施以及一些额外的默认安全库和设置。相对来说，Playdoh还是一个新项目，而且当于Java版本(JEE)或ASP.NET相对，Django在许多的协作环境下还不是很常用，但Django方法确是前途无量的。

　　未来，也许其他平台也会采取类似的、全面的和默认安全模型的安全编码。据说，虽然框架在帮助团队创建应用程序而不带来常见漏洞方面有一定的帮助，但没有什么可以替代所有的开发人员拥有的一些安全设计和编码原则的知识。