启用IIS Request Filtering后，ASP.NET Web Forms应用无法加载.js文件

Ah, I get it—your Request Filtering config is working a little too well! It's not just blocking users from directly browsing the Scripts folder or its JS files, it's also stopping your Web Forms pages from loading those same scripts via <script> tags. The issue is that Request Filtering doesn't distinguish between a user typing a JS URL into their address bar and your page making a legitimate request for the script.

Let's break down three solid solutions to fix this while keeping your security team happy:

Solution 1: Fine-Tune Request Filtering Rules #

Instead of blocking all access to Scripts/JS files, create targeted rules that only block unwanted direct access:

1. Open IIS Manager, navigate to your web app, and double-click Request Filtering.
2. Go to the Rules tab, then click Add Rule... on the right.
3. Create two rules:
   • Block Scripts Folder Browsing:
     • Rule type: Request Blocking
     • URL pattern: ^/Scripts/$ (adjust the path if your Scripts folder isn't at the root)
     • Check Abort Request, then save.
   • Block Direct JS File Requests:
     • Rule type: Request Blocking
     • URL pattern: ^/Scripts/.*\.js$
     • Switch to the Conditions tab and add a condition:
       • Condition input: {HTTP_REFERER}
       • Check type: Does Not Match the Pattern
       • Pattern: ^https?://yourdomain\.com/.* (replace yourdomain.com with your actual site domain—don't forget to escape the dot with \)
     • Check Abort Request, then save.

This setup blocks:

• Users trying to view the Scripts folder's file list
• Users directly accessing JS files via URL (since their request won't have your site as a referrer)
  But allows your pages to load scripts normally, since those requests include your site's referrer.

Solution 2: Use IIS URL Rewrite (More Flexible) #

If Request Filtering feels too restrictive, the URL Rewrite module gives you more control. First make sure it's installed (use IIS's Web Platform Installer if not), then add this to your Web.config under <system.webServer>:

<rewrite>
  <rules>
    <!-- Block direct access to Scripts folder listing -->
    <rule name="Block Scripts Directory Browsing" stopProcessing="true">
      <match url="^Scripts/$" />
      <action type="AbortRequest" />
    </rule>
    <!-- Block JS requests without a valid referrer from your site -->
    <rule name="Block Direct JS Access" stopProcessing="true">
      <match url="^Scripts/.*\.js$" />
      <conditions>
        <add input="{HTTP_REFERER}" pattern="^https?://yourdomain\.com/.*" negate="true" />
        <add input="{HTTP_REFERER}" pattern="^$" negate="false" />
      </conditions>
      <action type="AbortRequest" />
    </rule>
  </rules>
</rewrite>

Again, replace yourdomain.com with your actual site domain. This achieves the same goal as the Request Filtering rules but is easier to tweak if you need to adjust later.

Solution 3: Disable Directory Browsing (Simplest Option) #

If your security team only cares about preventing users from browsing the Scripts folder's file list (not blocking direct JS access entirely), this is the quickest fix:

1. In IIS Manager, find your Scripts folder and double-click Directory Browsing.
2. Click Disable on the right sidebar. This stops users from seeing the folder's contents when they visit /Scripts/.
3. Double-check that the Scripts folder has read permissions for the IIS_IUSRS user—this ensures your pages can still load the JS files normally.

Note: This doesn't block direct JS file access if someone knows the exact URL (they could get it from your page's source), but it's often enough to meet basic security requirements.

Testing Tips #

After setting up any of these solutions, verify:

• Visiting /Scripts/ directly gives a 403 or blocked error
• Visiting a JS file URL directly is blocked (for solutions 1/2) or accessible (solution 3)
• Your Web Forms pages load without JS errors in the browser console, and all functionality works as expected

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