Is there any reason I shouldn't precompile JSP pages?

Question

My understanding of JSP technology is that the server must translate the JSP into a servlet and compile it the first time that JSP is requested. The server I'm working on (IBM Websphere) has an option during deployment to "precompile JSP pages." By default, this option is disabled.

Since this JSP compilation must be performed at some point anyway, it seems unarguably better to do this at deployment when it won't impact user interactions (due to a longer page load). Granted, this compilation would only occur for the first user to visit the page, but still....

Is there any reason I shouldn't precompile JSPs on Websphere (or any Java server, for that matter)? Why would it be disabled by default?

Answer 1

Since this has lasted three years without anyone mentioning security, allow me to mention security.

Pre-compile your JSPs, put the class files in a JAR, sign all of your JARs, and put a security policy in place that mandates code signing for application logic.

A web server that compiles JSPs on demand is open to code-injection attacks. If an attacker can get a JSP onto the server, the server will compile it and add its logic to the application. Pre-compiling JSPs and disabling on-demand compilation on a production server prevents someone from doing this. It also allows you to have a somewhat more-secure server since the server does not need to compile Java, just run it. You are not putting dev tools on your server.

Now, before someone jumps in and says, "Hey, if you can put a JSP on a target server, what's stopping you from putting malicious compiled code there?" let me address that.

One benefit of using a JSP as an attack vector is that there is usually a straightforward way to trigger the execution of any logic in the JSP. It's also possible to add code to an existing JSP in order to use it as an execution hook. It is harder -- but not impossible -- to do this with code in a JAR.

What would make a malicious JAR impossible to execute is JAR signing. If your JVM is configured to run only signed JARs (as far as application code goes), then uploaded class and JAR files will not execute in the JVM, period.

The best time to address security is before you deploy your application and not after you've leaked the personal data of 143 million people. Just sayin'.

* I've been pointing this out since at least 2003 and to date, no one has actually heeded this advice. I'm still putting it out there**.

** None of my applications have used JSPs since 2011, so this has been -- for me -- a moot point for some time.

Answer 2

I'm not certain about this. I'm not a JBOSS guru by far, but I think if you consider the reasons for this, it's probably a question of trade off. I would imagine that if you pre-compile your pages, that process is going to take some time. While if you just compile the pages as you hit them, that's going to spread that work out over time as each page only gets compiled when it gets called.

The difference is that not all pages need to be complied in one scenario so that the app spins up faster but the pages you want must be compiled before you can generate the response.

The place where this probably makes the biggest difference is in development, as you only compile the page you're actually going to hit if you compile on demand. That way your app compiles more quickly, you deploy more quickly your complie debug refactor cycle is sped up.

In the real world, for production deployments you probably always want to pre-compile all jsp files.