Insecure or unset HTTP headers - Content-Security-Policy - Java

Need

Implementation of secure and properly configured Content-Security-Policy headers

Context

1. Usage of Java 8 for developing applications with enhanced features and performance
2. Usage of javax.servlet-api for developing Java web applications with Servlets

Description

Insecure Code Example

import javax.servlet.http.HttpServletResponse;

public class UnsafeHeaderServlet extends HttpServlet {

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // ... some code here ...
    }
}

The above Java servlet does not set the `Content-Security-Policy` HTTP header in its responses. This is a security vulnerability because the `Content-Security-Policy` header is used to prevent Cross-Site Scripting (XSS) attacks and other code injection attacks resulting from execution of malicious content in the trusted web page context. The `Content-Security-Policy` header allows you to create a whitelist of sources of trusted content, and instructs the browser to only execute or render resources from those sources. Even if an attacker can inject a script tag into your HTML content, the browser will not execute the script if the script's source is not in the whitelist. In the above code, the `doGet` method sends a response to the client without setting the `Content-Security-Policy` header. This means that the response could potentially contain malicious script that the browser will execute.

Steps

1. Understand the purpose of the Content-Security-Policy header and its importance in web application security.
2. Determine the appropriate security policies that need to be defined in the Content-Security-Policy header based on the application's requirements.
3. Ensure that the Content-Security-Policy header is included in the server responses.
4. Define the mandatory security policies in the Content-Security-Policy header to enforce secure behavior.
5. Avoid using insecure values in the security policies, such as 'unsafe-inline' or 'unsafe-eval'.
6. Regularly review and update the Content-Security-Policy header as needed to adapt to changes in the application's requirements and security best practices.

Secure Code Example

import javax.servlet.http.HttpServletResponse;

public class SafeHeaderServlet extends HttpServlet {

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // Define the Content-Security-Policy header
        response.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';");

        // ... some code here ...
    }
}

The above code fixes the vulnerability by setting the `Content-Security-Policy` header in the server's HTTP response. The `Content-Security-Policy` header is a security feature that helps prevent attacks such as Cross-Site Scripting (XSS) and data injection attacks. It does this by specifying the domains that the browser should consider as valid sources of executable scripts. In the fixed code, the `Content-Security-Policy` header is set to only allow resources (scripts, images, stylesheets, etc.) to be loaded from the application's own domain (`'self'`). This is done using the `setHeader` method of the `HttpServletResponse` object. The `default-src 'self';` directive sets the default policy for fetching resources such as JavaScript, Images, CSS, Font's, AJAX requests, Frames, HTML5 Media from the same origin. The `script-src 'self';` directive restricts where the browser can load JavaScript from to only the application's own domain. The `connect-src 'self';` directive restricts URLs which can be loaded using script interfaces. The `img-src 'self';` directive restricts from where the browser can load images. The `style-src 'self';` directive restricts from where the browser can load stylesheets. By setting these policies, the application is protected against loading potentially malicious resources from unauthorized domains. This is a crucial step in securing the application against common web vulnerabilities. Please note that the actual `Content-Security-Policy` header value should be defined based on your application's specific requirements. The above is just a basic example and might not fit all use cases. Regularly review and update the `Content-Security-Policy` header as needed to adapt to changes in the application's requirements and security best practices.

References

Last updated

2023/09/18