我正在考虑将Play用于大型项目，那么，是否有任何经过实战考验的Play框架适用于OWASP Top 10？您在Play框架中是否存在任何安全问题？
答案 0 :(得分：41)
在OWASP Top 10和Play（一些信息here）上：
A1：注射
默认情况下使用JPA并转义字符串
A2：跨站点脚本（XSS）
从版本1.0.1开始，Play的模板引擎会自动转义字符串
A3：身份验证和会话管理中断
游戏是无国籍的，不涉及任何会话。 Cookie受密码保护。通过散列将数据安全地存储在数据库（密码）上取决于用户，而不是框架
A4：不安全的直接对象引用
同样，这取决于开发人员验证对允许资源的访问权限，而不是框架
A5：跨站请求伪造（CSRF）
POST请求允许真实性令牌以防止这种情况发生。当然这取决于开发人员正确使用GET / POST
A6：安全配置错误
默认错误报告过程在生产中似乎是安全的（没有堆栈跟踪泄漏）。唯一的问题是路线中的“全部捕获”条目，但这应该在生产模式中注释掉
A7：不安全的加密存储
开发人员负责加密数据库中的敏感信息
A8：无法限制网址访问
开发人员必须实施安全限制（通过@Before，就像在教程中一样）禁止访问禁止的页面。
A9：传输层保护不足
Play支持SSL
A10：未经验证的重定向和转发
播放重定向是通过302，而不是硬编码字符串，这应该可以防止这种情况发生。
TL; DR：在框架可以完成所有工作的部分中，Play会这样做。在开发人员需要完成所有工作的部分中，开发人员需要完成所有工作。每个需要50％的零件，Play给出了50％。
让我们这样说吧：没有理由认为Play比其他任何Java框架更安全。在许多情况下，您可以认为它更安全。 Play是一个易于开发，无状态和REST框架，你可以减少混乱的机会。
答案 1 :(得分：5)
关于A3，你需要小心。 Play有两种类型的会话变量。一个是session() 进行数字签名，另一个是flash() 签名。此外 还存储在Cookie 客户端中，如果您决定在那里存储敏感数据，这可能会引发隐私问题。
另外，就A7（加密）而言，请注意Play提供了一个方便的Crypto库，但其加密使用ECB模式，再次打开whole new group of potential issues。