struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Webapp Security?
Date Thu, 03 Jul 2003 17:34:30 GMT

On Thu, 3 Jul 2003, Adam Hardy wrote:

> Date: Thu, 03 Jul 2003 13:47:20 +0200
> From: Adam Hardy <>
> Reply-To: Struts Users Mailing List <>
> To: Struts Users Mailing List <>
> Subject: Re: Webapp Security?
> Adam Hardy wrote:
> > Marc wrote:
> >
> >> To protect your JSP, put them in a subdir of WEB-INF. Actions are
> >> still able to redirect to those JSPs but they are not direct accessible.
> >>
> >> To protect your other files, just make a servlet and use path-mapping
> >> like '/resources/*' to map all requests to this servlet.
> >
> >
> >
> > What kind of security breaches are JSPs susceptible to, once they
> > protected by a security-constraint path mapping?
> what I mean is, are other files like HTML & style sheets & images
> vulnerable?

The reason people are concerned about putting JSP pages inside /WEB-INF is
generally to avoid clients trying to access them directly (by typing a URL
into the location bar); it is not really a security issue.  In effect, the
container provides an automatic security constraint that disallows ALL
direct accesses from the client to anything under /WEB-INF.

What you generally care about (from a security perspective) is ensuring
that only authorized persons can perform dynamic actions on your web
application.  If you don't care who can do something, then don't protect
it with a security constraint.  The same goes for static content -- if the
content is confidential to people that only have a particular role, then
protect it with a security constraint that requires that role before
allowing access.  It doesn't matter whether the particular resource is
implemented with JSP pages or ASP, or whether it's static or dynamic --
the key question is "should person X be able to access it".

It is *generally* simpler to use container managed security for things
like this, because you can declare the constraints declaratively in your
web.xml file, and not have to enforce it with functional logic inside your
app.  But there are also going to be cases where your needs go beyond what
standard container managed security provides -- the way you make a choice
should start from understanding what you're trying to protect and from
whom, before deciding how to protect it.


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

View raw message