Designing and implementing a security model for java applications from scratch is a very complex task and a severe test for even the best applications programmer. However the good news is that industrial strength J2EE applications are designed to execute within a java application server and it's the application server which provides most of the security services which the application needs. In the case of a web application the developer dictates when and how URIs are to be protected and the server implements the restrictions. This removes a layer of complexity from the application and allows administrators more flexibility. In fact it's possible to expand the EAR file and change the deployment descriptors so that the app runs completely unprotected without making any code changes. The point to remember is that most successful hackers break into sites by exploiting known weaknesses in the web server, application server or underlying operating system to gain command line access. Their prime objective is the collection of userids and passwords that unlock gateways to valuable corporate data. Hacking a site by breaking the application is more difficult because each application is unique and the hacker has to spend time profiling the application to find weaknesses. There is not much you can do about the security infrastructure but you can help lock a few doors if they do get in. Ensure that the page source code does not contain hard coded userids, passwords, sql or system commands. Spec the application so that all sensitive data is transmitted over SSL with client side certificate authentication. Do not store sensitive data such as userids, passwords, database id’s etc as clear text in property files. That’s hacker nirvana. Use strong encryption. Remember there is no native account lockout with forms auth i.e. no three strikes and your out. This is one feature that has to be coded in the app otherwise a password cracker will eventually guess the password. Ensure that all client input is validated to prevent script/sql injections. Session ids and cookies which are randomly generated by the appserver and transmitted over SSL are very difficult to hijack. However if they are persisted to a database or flat file system on a compromised machine then they may be available to the hacker.