Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m thinking about using Play for a large-scale project, so, has anyone battle-tested Play framework for OWASP Top 10? Are there any security problems you know of in Play framework?
On the OWASP Top 10 and Play (some info here):
A1: Injection
Uses JPA and escapes strings by default
A2: Cross-Site Scripting (XSS)
Since version 1.0.1, Play’s template engine automatically escapes string
A3: Broken Authentication and Session Management
Play is stateless, no session involved. Cookies are protected with cryptography. Storing data safely on the database (passwords) via hashing depends on the user, not the framework
A4: Insecure Direct Object References
Again this depends on developer verifying access to allowed resources, not so much the framework
A5: Cross-Site Request Forgery (CSRF)
POST requests allow for authenticity tokens to prevent this. Of course this depends on developer using GET/POST properly
A6: Security Misconfiguration
The default error reporting process seems safe on production (no stack trace leaks). The only concern would be the “catch all” entry in routes, but this should be commented out in production mode
A7: Insecure Cryptographic Storage
Developer is responsible to encrypt sensible information in the database
A8: Failure to Restrict URL Access
Developer must implement a security restriction (via @Before, like in the tutorial) to disallow access to forbidden pages.
A9: Insufficient Transport Layer Protection
Play supports SSL
A10: Unvalidated Redirects and Forwards
Play redirect is via 302, not hardcoded strings, which should prevent this.
TL;DR: In the parts that the framework can do all the work, Play does it. In the parts that developer needs to do all the work, well, developer needs to do all the work. Parts that need 50% of each, Play gives its 50%.
Let’s put it this way: there is no reason why you should consider Play less safe than any other Java framework. In many cases you can consider it more safe. And with Play being an easy to developer, stateless and REST framework you get less chances to mess it.