When an attacker explores a web site looking for vulnerabilities, the amount of information that the site provides is crucial to the eventual success or failure of any attempted attacks. If the application shows the attacker a stack trace, it relinquishes information that makes the attacker's job significantly easier. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.

The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application.

Every filter mapping must correspond to a valid filter definition in order for it to be applied.

Example 1: The following example shows a filter mapping that references the non-existent filter AuthenticationFilter. Because the definition is missing, the filter AuthenticationFilter will not be applied to the designated URL pattern /secure/* and might cause a runtime exception.

<filter>
    <description>Compresses images to 64x64</description>
    <filter-name>ImageFilter</filter-name>
    <filter-class>com.ImageFilter</filter-class>
</filter>

<!-- AuthenticationFilter is not defined -->
<filter-mapping>
    <filter-name>AuthenticationFilter</filter-name>
    <url-pattern>/secure/*</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>ImageFilter</filter-name>
    <servlet-name>ImageServlet</servlet-name>
</filter-mapping>

A missing security-role for a role-name defined in an auth-constraint could indicate an out-of-date configuration.

Example 1: The following example specifies a role-name, but does not define it in a security-role.

<security-constraint>
    <web-resource-collection>
         <web-resource-name>AdminPage</web-resource-name>
         <description>Admin only pages</description>
         <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>

    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>

    <user-data-constraint>
        <transport-guarantee>INTEGRAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

The absence of a valid servlet mapping prevents all access to the unmapped servlet.

Example 1: The following entry from web.xml defines ExampleServlet but fails to define a corresponding servlet mapping.

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

    <servlet>
      <servlet-name>ExampleServlet</servlet-name>
      <servlet-class>com.class.ExampleServlet</servlet-class>
      <load-on-startup>1</load-on-startup>
    </servlet>

</web-app>

Entity beans that expose a remote interface become part of an application's attack surface. For performance reasons, an application should rarely use remote entity beans, so there is a good chance that a remote entity bean declaration is an error.

Example 1: The following entity bean declaration includes a remote interface:

<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>EmployeeRecord</ejb-name>
<home>com.wombat.empl.EmployeeRecordHome</home>
<remote>com.wombat.empl.EmployeeRecord</remote>
...
</entity>
...
</enterprise-beans>
</ejb-jar>

If the EJB deployment descriptor contains one or more method permissions that grant access to the special ANYONE role, it indicates that access control for the application has not been fully thought through or that the application is structured in such a way that reasonable access control restrictions are impossible.

Example 1: The following deployment descriptor grants ANYONE permission to invoke the Employee EJB's method named getSalary().

<ejb-jar>
	...
	<assembly-descriptor>
		<method-permission>
			<role-name>ANYONE</role-name>
			<method>
				<ejb-name>Employee</ejb-name>
				<method-name>getSalary</method-name>
		</method-permission>
	</assembly-descriptor>
	...
</ejb-jar>

Kubernetes API servers accept anonymous requests by default if the requests are not rejected by other configured authentication methods. Because an API server is the central management entity of a cluster, attackers can use anonymous requests to gain access to insufficiently protected and security sensitive service APIs.

Example 1: The following configuration starts a Kubernetes API server and permits anonymous requests by setting the --anonymous-auth=true flag.

...
spec:
  containers:
    - command:
      - kube-apiserver
...
      - --anonymous-auth=true
...

A Kubernetes API server writes audit events to standard output by default. The audit events should be logged to persistent storage. The audit events contain valuable data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

Example 1: The following configuration starts a Kubernetes API server without the --audit-log-path flag.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=RBAC
  image: example.domain/kube-apiserver-amd64:v1.6.0
...

A Kubernetes API server, the central management entity of a cluster, accepts HTTP Basic Authentication to authenticate users. HTTP Basic Authentication is deprecated and susceptible to brute force attacks and leaks user credentials to attackers in a misconfigured environment.

Example 1: The following configuration starts a Kubernetes API server and sets the --basic-auth-file=<filename>> flag to use HTTP basic authentication.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-apiserver
      - --basic-auth-file=<filename>
    image: example.domain/kube-apiserver-amd64:v1.6.0
    livenessProbe:
...

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Kubernetes keeps sensitive data in an etcd cluster. Every etcd instance must serve clients over TLS connections but the command-line flags for setting up the TLS connections are missing.

Example 1: The following configuration starts an etcd instance without specifying both the --cert-file and --key-file flags for setting up TLS connections.

apiVersion: v1
spec:
  containers:
    - command:
      - etcd
      - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
  ...