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.

Roles and access

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. For more information about how to map users to roles and groups, see Authorization.

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 ibm-application-bnd.xml and 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 admin and 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 ibm-application-bnd.xml file. For example, the admin role could be defined in the server.xml and ibm-application-bnd.xml files. In this situation, the admin role from the server.xml file overwrites the admin role from the ibm-application-bnd.xml file.

When the role-mapping binding information isn’t specified for the application in the ibm-application-bnd.xml or 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.

Web server document root

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.

Secure servlets

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. Enabling the 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.

Servlet aliases

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.

Specify the deny-uncovered-http-methods element in the web.xml file. When the deny-uncovered-http-methods element is specified, the container denies any uncovered HTTP methods. A 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 web.xml file:

<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:

If the deny-uncovered-http-methods element is specified in the web.xml file, 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
```
If the deny-uncovered-http-methods element isn’t specified in the web.xml file, 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
```

File serving and directory browsing

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 ibm-web-ext.xml file:

<enable-directory-browsing value="false" />

Confidential transport guarantee between the client and the server

To ensure that applications run only over secure HTTP connections, specify the transport-guarantee element with a value of CONFIDENTIAL in the web.xml file:

<user-data-constraint>
  <transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>