Another lesson learned the hard way today: the J2EE declarative security model doesn’t apply when the application forwards the user request to another URL using a RequestDispatcher or an include. This means that your web application can (intentionally or not) bypass an HTTP authorization security constraint by forwarding the user request from a non-protected URL. The servlet spec does not dwell on the point, but section SRV.12.2 does say as much.
At best, this is inflexible. Having a property on the RequestDispatcher that specifies whether or not to perform auth checks would at least allow the programmer to state his intentions. At worst, it’s a security problem. If your application has a forward URL that’s not protected by HTTP authentication (not a particularly smart thing to do, but it happens), a malicious user could use that to gain access to protected parts of your application. So far I haven’t been able to use this techique between two webapps on the same server. When I try to forward a request to a protected URL in another webapp, I get a 404 error – not quite what I expected, but better that no protection whatsoever.
HTTP auth is not commonly used as an authentication strategy application-wide but sometimes we use it to protect administrative features, such as application management consoles. Having this misfeature in-place and not well-explained in the documentation sets programmers up for security problems. Sun, you can do better than that.