Home/ Questions/Q 6028105
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T04:41:23+00:00

When you use JSF, you’ll have the controller servlet javax.faces.webapp.FacesServlet that will be mapped

  • 0

When you use JSF, you’ll have the controller servlet javax.faces.webapp.FacesServlet that will be mapped to the following:

<servlet-mapping>
   ...
    <url-pattern>/somefacesurl/*</url-pattern>
</servlet-mapping>

Putting a mypage.xhtml in /, we have a security risk because it will be accessed in two ways (starting from the application context):
1) /somefacesurl/mypage.xhtml
2) /mypages.xhtml

The first is processed by jsf, and is correct.
The second is not processed by jsf and so is presented to the client exposing jsf tags and this is a security risk.

I’ve found only two solutions
1) mapping always to the root url:

<servlet-mapping>
   ...
    <url-pattern>*.xhtml</url-pattern>
</servlet-mapping>

Good solution but permits only mappings by file extension.

2) Map to whatever url, and use security constraint to disallow access to those files as suggested in:
How to avoid user access to .xhtml page in JSF?

Both solutions are presented in the JSF 2.0 spec as viable alternatives, BUT there is no word about the different security approach of the two solutions.

Since security is NOT considered, i wonder if the first is “secure” from the point of view of access to the xhtml files or perhaps there is an hack to get the .xhtml sources.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It is not true that the JSF spec mandates the first mapping. It just gives examples of the both mappings in chapter 11.1.2 of the JSF 2.0 spec (which you should be reading) and chapter 10.1.2 of the JSF 1.2 spec. Here’s an extract of relevance of the JSF 2.0 spec one (emphasis mine):

    11.1.2 Servlet Mapping

    All requests to a web application are mapped to a particular servlet based on matching a URL pattern (as defined in the
    Java Servlet Specification) against the portion of the request URL after the context path that selected this web
    application. JSF implementations must support web application that define a <servlet-mapping>
    that maps any valid url-pattern to the FacesServlet. Prefix or extension mapping may be used. When
    using prefix mapping, the following mapping is recommended, but not required:

    <servlet-mapping>
    <servlet-name> faces-servlet-name </servlet-name>
    <url-pattern>/faces/*</url-pattern>
</servlet-mapping>

    When using extension mapping the following mapping is recommended, but not required:

    <servlet-mapping>
    <servlet-name> faces-servlet-name </servlet-name>
    <url-pattern>*.faces</url-pattern>
</servlet-mapping>

    In addition to FacesServlet, JSF implementations may support other ways to invoke the JavaServer Faces request
    processing lifecycle, but applications that rely on these mechanisms will not be portable.

    I really don’t see why an extension (suffix) mapping is “tricky”. Even more, this is my favourite JSF mapping. I recommend using *.xhtml as JSF mapping. This gives you also the advantage that you don’t need to fiddle with security constraints to prevent direct access to source files.

    Update: Please note that the source leak is not a security issue per se as long as the view is declarative and does not contain any single line of Java source code wherein variables like database username/password are stored and exposed. Since Facelets disallows for embedded raw Java code (like JSP scriptlets) I don’t see how that’s a security leak. What can a hacker do with the view source? Edit it, render it and submit back somehow? (I’d really wonder how). That’s plain impossible since JSF by default relies on the view state in the server side as well.

    I however agree with the point that the JSF specification should inform the reader more about this. I’ve created JSF spec issue 1015 for this.

    • 0