tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mekkelsen Madden, Steve" <>
Subject RE: how to prevent user access to JSP pages?
Date Sun, 19 Aug 2018 12:41:22 GMT
If it helps, I also needed to do something very similar where if the user connected to the
right server running Tomcat and has the right port but wrong context or servlet, they would
see a default Tomcat page not found revealing the application server used (Tomcat) and its
version which for us was a security concern.  Reading over previous emails here, I used the
filter option:
<Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false"
In the conf/context.xml file and now if the user connects to the wrong url, all they'll get
	HTTP Status 404 -- Not Found
With nothing else revealed so this was perfect for us.  There were other changes I needed
to make in each servlet to also customize the response screens, it was only the invalid ones
that were more difficult to figure out how to do.

Kind Regards,

Steve Mekkelsen Madden 

-----Original Message-----
From: Terence M. Bandoian <> 
Sent: Saturday, August 18, 2018 10:39 PM
To: Tomcat Users List <>
Subject: Re: how to prevent user access to JSP pages?

On 8/17/2018 8:52 AM, Christopher Schultz wrote:
> Hash: SHA256
> Mark,
> On 8/17/18 3:54 AM, Mark Thomas wrote:
>> On 16/08/18 18:19, Berneburg, Cris J. - US wrote:
>>> Due to security concerns and general fussiness on my part, I'd like 
>>> to prevent users from requesting JSP pages directly, except for the 
>>> login page.  I want all requests to be handled by servlets.  That 
>>> way I can legitimately claim that all requests are being validated, 
>>> input scrubbed, JSP's cannot be taken advantage of w/o their servlet 
>>> chaperones being present, etc.
>> I'm struggling to understand what risks exists with JSPs that don't 
>> with Servlets. After all, a JSP is just an alternative way to write a 
>> Servlet. Tomcat translates the .jsp file to the .java source for a 
>> servlet, compiles it and runs it.
>> Can you elaborate?
> JSP support for input validation, etc. is basically non-existent. I'm 
> sure someone has a crappy library that can do it, and yes, you can 
> implement everything in JSP using miles of tag libraries and stuff 
> like that, but in the application world, that's a serious no-no.
> MVC (or some version of it, under various names) is the "proper" way 
> to build software, and JSPs are relegated to the "V" portion of that 
> paradigm.
> Once you have decided that JSPs are squarely in the "V" category, it's 
> no longer appropriate for them to be treated as "C" components and 
> therefore they should not be accessed directly. Protecting them from 
> direct-access is a reasonable decision for a number of reasons, 
> including security if you have pages that cough-up sensitive 
> information under the assumption that authentication and authorization 
> requirements have previously been satisfied.
> Sure, the container's authentication and authorization should be able 
> to protect those JSPs just fine, but the application may have other 
> controls in place that also need to sanity-check things before the JSP 
> takes over.
> So, while there isn't anything particularly "dangerous" about 
> direct-access to JSPs, there are a number of "best practices" that 
> suggest that hiding them is a good idea.
> I hope that helps explain Cris's (likely) reasoning a little more.
> - -chris

As far as I know, there is no input validation that can be performed in servlets that can't
also be performed in JSP pages using the same Java code.  Also, I'm not aware of any functional
limitation that prevents JSP pages (classes) from being used as controllers.  As I understand
them, JSPs can do anything that can be done in servlets and offer additional facilities and
ease-of-use.  They may be thought of as view-generators only but I don't think that's a functional

Could a servlet filter be used to reject external requests for JSP pages?

-Terence Bandoian

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message