ASP.NET网站部署后因CSP限制导致内联脚本无法执行的问题求助

Hey there, I’ve dealt with this exact headache before with ASP.NET Web Forms sites—let’s break down what’s going on and how to fix it.

First, Why Are You Seeing "script-src 'self'" When You Didn’t Configure It? #

The most likely culprit is that your server (IIS, Azure App Service, or another hosting platform) is automatically adding a default Content Security Policy header that’s overriding your meta tag. HTTP response headers always take priority over <meta> tag CSP settings, so your meta tag’s rules are being ignored entirely.

To confirm this:

• Open your browser’s DevTools (F12)
• Go to the Network tab
• Reload the page, click on the main page request, and check the Response Headers section for a Content-Security-Policy entry. That’s where the "script-src 'self'" is coming from.

Solutions to Fix the Inline __doPostBack Script Issue #

ASP.NET Web Forms automatically generates inline onclick handlers for controls with AutoPostBack="True", which triggers the CSP violation. Here are your best options, ordered by security:

1. Use a Nonce (Most Secure) #

A nonce is a random, unique value generated per request that allows specific inline scripts to run. Here’s how to implement it:

Step 1: Generate the Nonce in Code-Behind

In your page’s Page_Load method, create a nonce and add it to the CSP header:

protected void Page_Load(object sender, EventArgs e)
{
    // Generate a random nonce (unique per request)
    string nonce = Guid.NewGuid().ToString("N");
    // Store it in ViewState to reuse if needed
    ViewState["CSPNonce"] = nonce;
    // Add the CSP header with the nonce
    Response.Headers.Add("Content-Security-Policy", $"script-src 'self' 'nonce-{nonce}';");
}

Step 2: Associate the Nonce with ASP.NET’s Generated Scripts

For ASP.NET’s auto-generated __doPostBack script, you’ll need to register it with the nonce. Add this to your page’s code-behind as well:

protected override void Render(HtmlTextWriter writer)
{
    base.Render(writer);
    // Get the nonce from ViewState
    string nonce = ViewState["CSPNonce"] as string;
    if (!string.IsNullOrEmpty(nonce))
    {
        // Re-register the __doPostBack script with the nonce attribute
        string doPostBackScript = @"
            function __doPostBack(eventTarget, eventArgument) {
                if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
                    theForm.__EVENTTARGET.value = eventTarget;
                    theForm.__EVENTARGUMENT.value = eventArgument;
                    theForm.submit();
                }
            }";
        ClientScript.RegisterStartupScript(this.GetType(), "doPostBack", $"<script nonce='{nonce}'>{doPostBackScript}</script>");
    }
}

This replaces the auto-generated inline __doPostBack with a script tag that includes your nonce, bypassing the CSP restriction.

2. Use the Script Hash (Good for Static Inline Scripts) #

The error message already gives you the SHA-256 hash of the inline onclick script: sha256-ET0SWzTymVfQ+qjfGmR3CUWjxDefnjlCs53WMtvYTeU=. You can add this hash directly to your CSP to allow that specific inline script.

Add this to your Web.config to override the server’s default CSP:

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="Content-Security-Policy" value="script-src 'self' 'sha256-ET0SWzTymVfQ+qjfGmR3CUWjxDefnjlCs53WMtvYTeU=';" />
        </customHeaders>
    </httpProtocol>
</system.webServer>

⚠️ Note: This only works if the inline script generated by ASP.NET doesn’t change. If you rename controls or modify auto-postback behavior, the hash will break and you’ll need to generate a new one.

3. Use 'unsafe-inline' (Quick Fix, Less Secure) #

If you need a temporary solution or security isn’t a top priority, you can allow all inline scripts with 'unsafe-inline'. Make sure to add it to the server’s CSP header (not just a meta tag):

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="Content-Security-Policy" value="script-src 'self' 'unsafe-inline';" />
        </customHeaders>
    </httpProtocol>
</system.webServer>

If your site failed to load after adding this to Web.config before, double-check for syntax errors (like missing closing tags) or conflicting headers from other modules/plugins on your server.

Final Checks #

• After applying any fix, clear your browser cache and recheck the Network tab to ensure the correct CSP header is being sent.
• If you’re using a hosting platform like Azure App Service, check if there’s a security setting in the portal that’s enforcing a default CSP—you may need to disable or override it there.

内容的提问来源于stack exchange，提问作者ezepter