Application configuration security hardening
Before you can run an application in production, carefully harden its configuration by following best practices. If your application isn’t properly secured, external users might derive or inherit unauthorized privileges when they run it and gain access to sensitive information.
This sensitive information might contain information about your application and other users. By hardening your application configuration, you can prevent unauthorized exposure of sensitive information.
Understanding roles and mappings of users is key to securely configuring your application for production use. Incorrect role mapping can give inadvertent levels of access to users, which can result in users who can gain unapproved access to sensitive resources.
If you don’t configure roles in the
server.xml file, by default, Open Liberty uses the group names that a user is attached to as the role names for the user.
For conflicts in the role mapping of a servlet between the
web.xml file and annotations in the application, the configuration in the
web.xml file takes precedence.
If a conflict exists between the
server.xml files, then the configuration in the
server.xml file takes precedence.
If the information that is being specified can have multiple values, the values from the
server.xml file are added to the values from the application.
For example, if the
ibm-application-bnd.xml file defines two roles, such as
viewer, and the
server.xml file defines one role, such as
user, then all three roles are used.
A role that is defined in the
server.xml file can have the same name as a role that is defined in the
For example, the
admin role could be defined in the
In this situation, the
admin role from the
server.xml file overwrites the
admin role from the
When the role-mapping binding information isn’t specified for the application in the
server.xml files, the group name and role name must be the same.
For example, if the role name is
manager, then a user who belongs to a
manager group has access to that resource.
Avoid placing sensitive information in the WAR root.
The web container serves any files that are found in the root of the WAR file, which is okay if the root contains only servable content.
However, because the web container serves files from the WAR root, it must never contain any content that you don’t want users to see, including property or class files.
If you must place such information in the WAR file, place it in the
WEB-INF directory, as allowed by the servlet specification.
Information in this directory is never served by the web container.
Servlets can be served by class name or with a normal URL alias.
You can serve servlets by class name by setting the
serveServletsByClassnameEnabled property to
true in the
ibm-web-ext.xml file of the application.
For production purposes, don’t enable this property.
serveServletsByClassnameEnabled property makes it possible for anyone that knows the class name of any servlet to directly start it.
By default, Open Liberty does not allow servlets to be served by class name.
Instead of defining a mapping for each servlet, a single generic URI, such as
/servlet, serves all servlets.
The component of the path after the generic URI is assumed to be the class name for the servlet.
For example, the
/servlet/com.ibm.sample.MyServlet path refers to the
com.ibm.sample.MyServlet servlet class.
Servlets are secured by URLs, and each URL must be specified with security constraints.
The security constraints can be outlined by using JAX-RS annotations, or they can be included in the
web.xml file that describes the application.
A servlet can have more than one alias. For example, multiple URLs can access the same servlet class.
If a servlet has more than one alias, it can be easy to forget to secure an alias.
Because Open Liberty secures URLs and not the underlying classes, if just one servlet URL is insecure, an intruder might be able to bypass security.
To alleviate this risk, use wildcards to secure servlets wherever possible.
If using wildcards isn’t appropriate, carefully check your
web.xml file before deployment.
When you specify security constraints for servlets, ensure that you either list no methods or carefully list all the methods for a servlet, including GET, POST, PUT, and HEAD methods.
deny-uncovered-http-methods element in the
deny-uncovered-http-methods element is specified, the container denies any uncovered HTTP methods.
403 (SC_FORBIDDEN) status code is returned by the denied HTTP methods.
You can also use the http-method-omission element to specify an HTTP method to which a security constraint doesn’t apply.
In the following secure example, the
deny-uncovered-http-methods element is specified in the
<servlet-mapping id="ServletMapping_1"> <servlet-name>MyServlet</servlet-name> <url-pattern>/MyURLPattern</url-pattern> </servlet-mapping> <deny-uncovered-http-methods /> <!-- SECURITY CONSTRAINTS --> <security-constraint id="SecurityConstraint_1"> <web-resource-collection id="WebResourceCollection_1"> <web-resource-name>Protected with Employee or Manager roles</web-resource-name> <url-pattern>/MyURLPattern</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint id="AuthConstraint_1"> <role-name>Employee</role-name> <role-name>Manager</role-name> </auth-constraint> </security-constraint>
A message is logged in the
messages.log file for each URL pattern in each servlet.
These messages indicate the uncovered methods and whether those methods are accessible:
deny-uncovered-http-methodselement is specified in the
web.xmlfile, the messages indicate that the uncovered methods are unprotected and not accessible, as shown in the following example:
For URL MyURLPattern in servlet MyServlet, the following HTTP methods are uncovered, and not accessible: DELETE OPTIONS HEAD PUT TRACE
deny-uncovered-http-methodselement isn’t specified in the
web.xmlfile, the messages indicate that the uncovered methods are unprotected and accessible, as shown in the following example:
For URL MyURLPattern in servlet MyServlet, the following HTTP methods are uncovered, and accessible: DELETE OPTIONS HEAD PUT TRACE
You can further limit the risk of serving inappropriate content by disabling file serving and directory browsing in your web applications.
Set the following property in the
<enable-directory-browsing value="false" />
To ensure that applications run only over secure HTTP connections, specify the
transport-guarantee element with a value of
CONFIDENTIAL in the
<user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint>
Guide: Securing a web application