Enhancing Web Security with Content-Security-Policy (CSP) in IIS

In today’s digital landscape, securing web applications from malicious attacks is more critical than ever. One essential security measure is the Content-Security-Policy (CSP), a powerful HTTP header that helps prevent cross-site scripting (XSS), data injection attacks, and other vulnerabilities.

This article explores how to configure CSP in Internet Information Services (IIS) to enhance the security of your web application while maintaining functionality.

What is Content-Security-Policy (CSP)?

CSP is an HTTP response header that dictates which resources can be loaded by the browser, reducing the risk of executing malicious scripts. It allows developers to specify trusted sources for scripts, styles, images, and other assets, preventing unauthorized content from being executed.

Why Implement CSP in IIS?

• Mitigates XSS attacks by blocking inline scripts and restricting script sources.
• Prevents data exfiltration by controlling connections to third-party services.
• Enhances application security by enforcing a strict security posture.

Configuring CSP in IIS

Follow these steps to implement CSP in IIS:

Step 1: Open IIS Manager

1. Launch IIS Manager on the server where the web application is hosted.
2. In the Connections panel, select the website you want to secure.

Step 2: Configure HTTP Response Headers

1. Under the Features View, double-click on HTTP Response Headers.
2. Click Add in the right-hand Actions panel.
3. In the Name field, enter Content-Security-Policy.
4. In the Value field, specify the CSP rules based on your security requirements.

Example CSP Configurations

Basic CSP Policy (Restricting Sources)

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self';

• Allows scripts, styles, and images only from the application’s domain ('self').

CSP with Trusted Domains

Content-Security-Policy: default-src 'self' https://trusted-resource.com; script-src 'self' https://trusted-scripts.com;

• Allows scripts from 'self' and trusted-scripts.com.
• Expands source policies for improved functionality.

Handling Inline Scripts and Unsafe Directives

Some applications rely on inline scripts and eval(), which are blocked by CSP. If code modifications are not feasible, the following approach may be necessary:

Content-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval';

• While not recommended, this policy allows inline scripts and eval(), but increases the security risk.
• A nonce-based approach should be implemented instead when possible.

Using Nonces for Inline Scripts

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

• This approach allows only scripts with the specified nonce, reducing XSS risks.

Testing and Deploying CSP

1. Test CSP in a Staging Environment – Ensure the policy does not break functionality.
2. Use CSP Report-Only Mode – Log policy violations without enforcing them:

   Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri /csp-violation-report;
   

3. Gradually Enforce CSP – Implement strict policies in phases to avoid disruptions.
4. Monitor Logs – Use browser developer tools to check for blocked resources.

Additional Security Headers

For enhanced security, consider adding these headers:

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: no-referrer

Final Thoughts

Configuring Content-Security-Policy (CSP) in IIS is an essential step in securing web applications against common vulnerabilities. While it may require adjustments to existing scripts and assets, the added security benefits significantly outweigh the challenges.

By testing and implementing CSP gradually, organizations can enhance web security while ensuring a seamless user experience.

For more insights on web security best practices, stay tuned to our blog.