Content Security Policy (CSP) is a declarative security header that enables developers to dictate which domains the site is allowed to load content from or initiate connections to when rendered in the web browser. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code.

Spring Security and other frameworks do not add Content Security Policy headers by default. The web application author must declare the security policy/policies to enforce or monitor for the protected resources to benefit from this additional layer of security.

Duplicate security roles serve no purpose since only the last definition of a given security role will be applied.
Example 1: The entry from a web.xml file defines two admin roles.

<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>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

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>

It is good practice to define permissions on a granular basis that adhere to the Least Privilege Principle. A Kubernetes security context defines privileges and access control settings for a Container or Pod. A Container lacks security context if there is no such setting at both the Pod and Container level.

Example 1: The following configuration defines a Pod without any security context because there is no securityContext field.

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP

API operations define security requirements to inform API consumers of the authentication and authorization parameters required to successfully invoke them.

Operations that include an empty security definition might enable attackers to interact with sensitive API endpoints and allow them to perform actions that should be restricted to specific user accounts with explicit privileges.

Example 1: The following OpenAPI specification sets an empty security definition for a sensitive operation. This overrides globally defined security requirements and renders the createUsers operation vulnerable to unauthorized and unauthenticated access.

{
    "openapi": "3.0.0",
    "info": {
     ...
    },    
    "paths": {
      "/users": {
        "post": {
          "security": [],
          "summary": "Create a user",
          "operationId": "createUsers",
         ...
        }
    ...
    }
}

Global security requirements inform API consumers of the authentication and authorization parameters required to successfully interact with the API.

An empty Global security definition might enable attackers to interact with sensitive API endpoints and allow them to perform operations that should be restricted to specific user accounts with specific privileges.

Example 1: The following OpenAPI specification declares an empty global security definition. APIs that implement this specification might be vulnerable to unauthorized or unauthenticated access to sensitive operations.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },
    "servers" : [ {
        "url" : "/"
    } ],
    "security" : [],
    ...
}

API operations define security requirements to inform API consumers of the authentication and authorization parameters required to successfully invoke them.

Operations that do not include a security definition might enable attackers to interact with sensitive API endpoints and allow them to perform actions that should be restricted to specific user accounts with explicit privileges.

Example 1: The following OpenAPI specification fails to set a security definition for a sensitive operation. Additionally, without a global security definition, the createUsers operation is vulnerable to unauthorized and unauthenticated access.

{
    "openapi": "3.0.0",
    "info": {
     ...
    },    
    "paths": {
      "/users": {
        "post": {
          "summary": "Create a user",
          "operationId": "createUsers",
         ...
        }
    ...
    }
}

Global security requirements inform API consumers of the authentication and authorization parameters required to successfully interact with the API.

Optional security requirement entries defined within the global security definition might enable attackers to interact with sensitive API endpoints and allow them to perform operations that should be restricted to specific user accounts with specific privileges.

Example 1: The following OpenAPI specification declares a global security definition with optional security via the empty {} item. APIs that implement this specification might be vulnerable to unauthorized or unauthenticated access to sensitive operations.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },
    "servers" : [ {
        "url" : "/"
    } ],
     "security" : [ {}, { "oauth_auth" : ["write","read" ]} ],
    ...
}

Global security requirements inform API consumers of the authentication and authorization parameters required to successfully interact with the API.

An absent global security definition might enable attackers to interact with sensitive API endpoints and allow them to perform operations that should be restricted to specific user accounts with specific privileges.

Example 1: The following OpenAPI specification neglects to declare a global security definition. APIs that implement this specification might be vulnerable to unauthorized or unauthenticated access to sensitive operations.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },
    "servers" : [ {
        "url" : "https://example.org"
    } ],    
    ...
}

API operations define security requirements to inform API consumers of the authentication and authorization parameters required to successfully invoke them.

Operations that make security optional might enable attackers to interact with sensitive API endpoints and allow them to perform actions that should be restricted to specific user accounts with explicit privileges.

Example 1: The following OpenAPI specification makes security optional by including an empty object {} in the security definition for a sensitive operation. This overrides globally defined security requirements and renders the createUsers operation vulnerable to unauthorized and unauthenticated access.

{
    "openapi": "3.0.0",
    "info": {
     ...
    },    
    "paths": {
      "/users": {
        "post": {
           "security": [
            {},
            {
              "my_auth": [
                "write:users"
              ]
            }
          ],
          "summary": "Create a user",
          "operationId": "createUsers",
         ...
        }
    ...
    }
}

The securitySchemes definition specifies the security mechanisms that may be used globally or by specific API operations.

The securitySchemes definition is typically specified under the reusable components object and is referenced globally or by specific operations to dictate security requirements for interaction.

Example 1: The following OpenAPI specification fails to define the securitySchemes definition.

{
    "openapi" : "3.0.3",
    "info" : {
        "title" : "My API",
        "version" : "1.0.0"
    },   
    "components": {
        "schemas": {
        "GeneralError": {
            "type": "object",
            "properties": {            
            ...
            }
        }
}

Programs that transmit messages without transport or message security cannot guarantee the integrity or confidentiality of the messages. When a WCF security binding is set to None, both transport and message security are disabled.

Example 1: The following code sets the security mode of a WCF Basic HTTP Binding for a fictitious Widget Service to None.

BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;

ServiceHost serviceHost = new ServiceHost(typeof(Widget), baseAddress);
serviceHost.AddServiceEndpoint(typeof(Widget), binding, new URI("ExposureAddress"));

Transport security specifies that confidentiality, integrity, and authentication are provided by transport-layer mechanisms (such as HTTPS). When using a transport like HTTPS, this mode has the advantage of being efficient in its performance and well understood because of its prevalence on the Internet. The disadvantage is that this kind of security is applied separately on each hop in the communication path, making the communication susceptible to a man-in-the-middle attack. WCF offers two other transfer security modes, both of which are preferable: message and transport with message credential. Message security uses the WS-Security specification to ensure confidentiality, integrity, and authentication at the message level. This provides end-to-end security and flexibility in transport methods. However, it reduces performance.

The final method, transport with message credential, is a hybrid of transport and method. Message security is used to authenticate the client and transport security is used to authenticate the server and provide confidentiality, and integrity. It is nearly as efficient as pure transport security.

If a service relays messages to other services, the messages are exposed to the weakest transport mechanism used between relay points. REST by itself does not include any security mechanisms, so this service relies on the transport layer for message integrity and confidentiality.

The following configuration enables REST:

<axisconfig name="AxisJava2.0">
...
    <parameter name="disableREST" locked="true">false</parameter>
...
</axisconfig>

The Rampart WS-Security module is not enabled. WS-Security is an extension of SOAP that provides end-to-end message integrity and confidentiality regardless of the transport protocol. When WS-Security is not used, messages rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security eliminates the transport security dependency and builds security into the message itself.

The Rampart WS-Security module is not enabled. WS-Security is an extension of SOAP that provides end-to-end message integrity and confidentiality regardless of the transport protocol. When WS-Security is not used, message rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security removes the transport security dependency and builds security into the message itself.

WS-Security is an enhancement to SOAP that provides end-to-end message integrity and confidential regardless of the transport protocol. When WS-Security is not used, message rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security removes the transport security dependency and builds security into the message itself.

The absence of an <securityResponseGeneratorServiceConfig> tag in the IBM WebSphere WS-Security server deployment descriptor extension file indicates that inbound message security is not enabled.

WS-Security is an enhancement to SOAP that provides end-to-end message integrity and confidential regardless of the transport protocol. When WS-Security is not used, message rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security removes the transport security dependency and builds security into the message.

The absence of an <securityResponseConsumerServiceConfig> tag in the IBM WebSphere WS-Security client deployment descriptor extension file indicates that outbound message security is not enabled.

WS-Security is an enhancement to SOAP that provides end-to-end message integrity and confidential regardless of the transport protocol. When WS-Security is not used, message rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security removes the transport security dependency and builds security into the message.

The absence of an <securityRequestGeneratorServiceConfig> tag in the IBM WebSphere WS-Security client deployment descriptor extension file indicates that outbound message security is not enabled.

WS-Security is an enhancement to SOAP that provides end-to-end message integrity and confidential regardless of the transport protocol. When WS-Security is not used, message rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security removes the transport security dependency and places it in the message.

The absence of an <securityRequestConsumerServiceConfig> tag in the IBM WebSphere WS-Security server deployment descriptor extension file indicates that inbound message security is not enabled.