How does stateless mode affect security in the Play! framework?

Question

Stateless operation mode in the Play! framework is said to be less secure than stateful mode. How does it affect Play framework in general and is it possible to improve the security drawbacks for critical public web applications?

Answer 1

First of all, you say that stateless is less secure? Do you have any specific reason why you believe this is the case?

The idea of a stateless model, is that you do not store data in a session needlessly, server side, which results in you having to continue the 'session chat' on that same server for the duration of the session.

If you want to mimic a J2EE Session, then you can simply use the session.id and store all state in a database, and delete at the end of the session.

The session cookie itself is signed, so it cannot be tampered with, so there is no concern that someone can hijack the session id, but if you are particularly worried, then you can simply store your own identifier in the session cookie, and encrypt it with the Crypto utility class that uses the application's secret key to encrpyt/decrypt data.

Stateless is just a change of mindset, and as long as you do not store data needlessly in the session (which is probably where you are coming from), then you should have very little to worry about.

Answer 2

Its not that play's stateless model is less secure it just that there is no decent Java Security libraries out there that can rival the likes of Spring Security.

The security modules available for play at the moment at pretty basic, and don't provide a third of the functionality of Spring Security.

Until a security module is developed that rivals the like of Spring Security, I'm afraid there is no way play will have legs in the enterprise application world. At the moment it's fine for a simple blog application.

It's just a pity Spring Security has a dependency on Spring and the servlet API.