IIS7网站未配置X-frame-options却报Deny错误的排查求助

Let’s walk through targeted troubleshooting steps to track down where that stubborn X-Frame-Options: DENY header is coming from, and resolve your iframe embedding and X-XSS-Protection errors. You’ve already checked your site-level web.config, so we’ll focus on less obvious sources:

1. Check Global & Server-Level Configurations #

IIS7 inherits settings from higher-level config files and server-wide modules that might be adding the header without your knowledge:

• Machine.config: Navigate to C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config (or the framework version matching your app) and look for <customHeaders> under <system.webServer>. If there’s an X-Frame-Options entry set to DENY, that’s a global override affecting all sites on the server.
• HTTP.sys Response Headers: Use Command Prompt to check for server-wide headers added via HTTP.sys:

  netsh http show responseheaders
  

  Look for any X-Frame-Options entries here—these apply to every site hosted on the server.

2. Audit IIS Modules & Extensions #

Third-party or built-in IIS modules can inject security headers automatically:

• List Installed Modules: Open IIS Manager, select your site, and go to Modules. Look for security-focused modules (e.g., WAF tools, malware scanners, custom security extensions) that might add X-Frame-Options headers. You can also use this command to list all modules:

  appcmd list modules
  

• Test by Disabling Modules: Temporarily disable non-essential modules one by one, then test the iframe embedding to see if the DENY header disappears. This helps isolate the culprit.

3. Inspect Application Code for Dynamic Header Injection #

Your ASP.NET application might be adding the header programmatically, even if it’s not in web.config:

• Global.asax: Check events like Application_BeginRequest or Application_PreSendRequestHeaders for code that uses Response.AddHeader("X-Frame-Options", "DENY") or Response.Headers["X-Frame-Options"] = "DENY".
• Page-Level Code: Look through your ASPX code-behind files (e.g., Page_Load methods) for any response header modifications.
• Libraries & Dependencies: If you’re using third-party libraries (e.g., security frameworks, CMS plugins), they might be adding the header silently. Check their documentation or source code if possible.

4. Dig Deeper with Failed Request Tracing (FRT) #

You mentioned enabling FRT, let’s refine how you use it to pinpoint the header source:

• When reviewing the FRT log, look for events labeled MODULE_RESPONSE_HEADERS or SEND_RESPONSE. These entries will show exactly which module or code component added each response header.
• Pay close attention to the Module Name column—this will tell you if the header is coming from an IIS module (like UrlRewriteModule) or your application code (like System.Web).

5. Resolve the X-XSS-Protection 400 Error #

Your issue with removing the block parameter leading to a 400 Bad Request is likely due to IIS7’s strict validation of the X-XSS-Protection header format. Valid values for this header in IIS7 are:

• 1 (enable XSS protection without blocking)
• 1; mode=block (enable and block suspicious requests)
• 0 (disable XSS protection)

Avoid partial values like 1;—instead, set it to 1 if you don’t want the blocking behavior, then test again.

6. Validate Response Headers Directly #

Use a tool like curl or Postman to send a HEAD request to your site and inspect all response headers. This helps confirm how many X-Frame-Options headers are present and their values:

curl -I https://your-site-url

Look for duplicate X-Frame-Options entries—this will confirm if two different sources are adding conflicting values.

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