CSP: script-src unsafe-inline

Content Security Policy (CSP) is an added layer of security that helps prevent cross-site scripting (XSS) and other types of attacks by specifying which resources are allowed to be loaded on a web page. The 'CSP: script-src unsafe-inline' vulnerability occurs when inline scripts are allowed in the script-src directive of the CSP header. Inline scripts can be dangerous because they can be easily modified by attackers, allowing them to inject malicious code into the web page. In this guide, we will explain how to fix the 'CSP: script-src unsafe-inline' vulnerability in your web application.

‍

Step 1: Understand the CSP header

The CSP header is a security feature that allows web developers to specify which resources are allowed to be loaded on a web page. The header is added to the HTTP response sent by the server and can contain various directives, such as script-src, style-src, img-src, and others. Each directive specifies which types of resources are allowed to be loaded on the web page, and can contain a list of sources that are allowed.

For example, the following CSP header specifies that only scripts from the same domain are allowed:

Content-Security-Policy: script-src 'self';

The 'self' keyword specifies that only scripts from the same origin as the web page are allowed.

‍

Step 2: Disable inline scripts

To fix the 'CSP: script-src unsafe-inline' vulnerability, we need to disable inline scripts. Inline scripts are scripts that are embedded directly in the HTML code of the web page, using the 'script' tag. They can be easily modified by attackers and are therefore a security risk. Instead of using inline scripts, we should use external scripts that are loaded from a trusted source.

To disable inline scripts, we can add the 'unsafe-inline' keyword to the script-src directive of the CSP header. This keyword allows inline scripts to be executed, which is why it is a security risk. By removing this keyword, we disable inline scripts and force the browser to only execute external scripts.

For example, the following CSP header disables inline scripts:

Content-Security-Policy: script-src 'self';

‍

Step 3: Use the 'nonce' attribute

If we need to use inline scripts for some reason, such as for inline event handlers or to dynamically generate script code, we can use the 'nonce' attribute to specify a unique value for each script tag. The 'nonce' attribute is a random value that is generated by the server and included in the CSP header. When the browser encounters a script tag with a 'nonce' attribute that matches the value in the CSP header, it will allow the script to be executed.

To use the 'nonce' attribute, we need to generate a random value on the server and include it in the CSP header. We then add the 'nonce' attribute to each script tag that contains inline code.

For example, the following CSP header includes a nonce value:

Content-Security-Policy: script-src 'self' 'nonce-abc123';

The following script tag contains inline code and uses the 'nonce' attribute:

<script nonce="abc123"> // Inline script code here </script>

‍

Step 4: Use the 'hash' attribute

Another way to allow inline scripts is to use the 'hash' attribute to specify a cryptographic hash of the script code. The browser will only execute the script if the hash of the code matches the hash specified in the CSP header. This ensures that the script code has not been modified by an attacker.

To use the 'hash' attribute, we need to generate a cryptographic hash of the script code and include it in the CSP header. We then add the 'hash' attribute to each script tag that contains inline code.

For example, the following CSP header includes a SHA-256 hash of the script code:

Content-Security-Policy: script-src 'self' 'sha256-x4NdRf8/C1v9Xn6Uzg6U5RwUz48/Xn5V7NzRPbGg2IA=';

The following script tag contains inline code and uses the 'hash' attribute:

<script hash="sha256-x4NdRf8/C1v9Xn6Uzg6U5RwUz48/Xn5V7NzRPbGg2IA="> // Inline script code here </script>

‍

Step 5: Test and deploy

Once you have made the necessary changes to your CSP header, it is important to test your web application to ensure that everything is working correctly. You can use a CSP testing tool or a web browser's developer tools to check the CSP header and verify that it is correctly blocking inline scripts.

After testing, you can deploy your updated web application. It is important to monitor your web application for any issues or unexpected behavior, especially if you have made significant changes to the CSP header.

‍

Conclusion

The 'CSP: script-src unsafe-inline' vulnerability can be a serious security risk for web applications. By disabling inline scripts and using the 'nonce' or 'hash' attributes, we can reduce the risk of cross-site scripting attacks and other security issues. It is important to stay up-to-date with the latest security best practices and regularly test and update your web application's security features.

‍