Java Reference
In-Depth Information
Follow these guidelines to properly secure a web application:
• Do not list HTTP methods within constraint definitions. This is the simplest way
to ensure that you are not leaving HTTP methods unprotected. For example:
Click here to view code image
<!-- SECURITY CONSTRAINT #1 -->
<security-constraint>
<display-name>Do not enumerate Http Methods</display-name>
<web-resource-collection>
<url-pattern>/company/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>sales</role-name>
</auth-constraint>
</security-constraint>
If you list methods in a constraint, all non-listed methods of the effectively infinite
set of possible HTTP methods, including extension methods, will be unprotected .
The following example shows a constraint that lists the GET method and thus
defines no protection on any of the other possible HTTP methods. Do not use such
a constraint unless you are certain that this is the protection scheme you intend to
define.
Click here to view code image
<!-- SECURITY CONSTRAINT #2 -->
<security-constraint>
<display-name>
Protect GET only, leave all other methods unprotected
</display-name>
<web-resource-collection>
<url-pattern>/company/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>sales</role-name>
</auth-constraint>
</security-constraint>
• If you need to apply specific types of protection to specific HTTP methods, make
sure you define constraints to cover every method that you want to permit, with
or without constraint, at the corresponding URL patterns. If there are any methods
that you do not want to permit, you must also create a constraint that denies access
Search WWH ::




Custom Search