Secure Your ASP.NET Site with web.config on Windows Hosting

Windows Hosting plans include server-side protection such as a web application firewall, malware scanning and anti-virus and spam filtering. Those defend the platform and catch common attacks, but they can't fix weaknesses in your own application. A few settings in web.config close the most common gaps in ASP.NET and Classic ASP sites.

Merge the snippets below into your existing web.config (one <system.web> and one <system.webServer> section only) and keep a backup copy before you start.

1. Turn off debugging and detailed errors

<system.web>
  <compilation debug="false" targetFramework="4.8" />
  <customErrors mode="RemoteOnly" defaultRedirect="~/error.html" />
  <trace enabled="false" />
</system.web>
<system.webServer>
  <httpErrors errorMode="DetailedLocalOnly" />
</system.webServer>

                        
                    

Debug mode and detailed errors show attackers your code, file paths and sometimes connection strings. If you enabled them while troubleshooting, switch them back now.

2. Hide version information

Headers such as X-AspNet-Version and X-Powered-By tell attackers exactly which software to target.

<system.web>
  <httpRuntime targetFramework="4.8" enableVersionHeader="false" />
</system.web>
<system.webServer>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

                        
                    

For ASP.NET MVC, also add this line to Application_Start in Global.asax.cs to remove X-AspNetMvc-Version:

MvcHandler.DisableMvcResponseHeader = true;

                        
                    

3. Add security headers

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="X-Content-Type-Options" value="nosniff" />
      <add name="X-Frame-Options" value="SAMEORIGIN" />
      <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
      <add name="Permissions-Policy" value="camera=(), microphone=(), geolocation=()" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

                        
                    

A Content-Security-Policy header gives the strongest protection against cross-site scripting, but a wrong policy breaks scripts, fonts and payment widgets. Build it gradually, starting with Content-Security-Policy-Report-Only. Add Strict-Transport-Security only once HTTPS works everywhere (see SSL and HTTPS on Windows Hosting). If a header already exists, remove it first with <remove name="…" /> to avoid duplicates.

4. Protect cookies and sessions

<system.web>
  <httpCookies httpOnlyCookies="true" requireSSL="true" sameSite="Lax" />
  <sessionState cookieless="UseCookies" timeout="20" />
</system.web>

                        
                    

sameSite on httpCookies needs .NET Framework 4.7.2 or later (with targetFramework set accordingly). Only use requireSSL="true" once the whole site runs on HTTPS.

5. Block sensitive files

IIS already refuses to serve web.config, source code, bin and App_Data. Backups and exports left in the web root are a common leak, so block those extensions too, and add any private folders to the hidden list:

<system.webServer>
  <security>
    <requestFiltering>
      <fileExtensions allowUnlisted="true">
        <add fileExtension=".bak" allowed="false" />
        <add fileExtension=".sql" allowed="false" />
        <add fileExtension=".log" allowed="false" />
        <add fileExtension=".inc" allowed="false" />
      </fileExtensions>
      <hiddenSegments>
        <add segment="backups" />
        <add segment="private" />
      </hiddenSegments>
    </requestFiltering>
  </security>
</system.webServer>

                        
                    

Blocking .inc matters for Classic ASP sites that keep database passwords in include files with that extension. Better still, rename them to .asp. If you see “Cannot add duplicate collection entry”, that extension is already blocked on the server; delete that line. Best of all, don't leave backups on the web server at all.

6. Keep secrets out of the web root where you can

• Store connection strings and API keys in web.config (which IIS never serves), not in .js, .txt or .inc files.
• Move large settings blocks to a separate file with <appSettings file="App_Data\secrets.config"> and never commit that file to Git.
• Use a separate database user with only the permissions the site needs, and a long random password.

7. Keep everything updated

• Update NuGet packages (especially Newtonsoft.Json, jQuery and anything that parses uploads) and re-publish.
• Remove unused pages, test scripts, old admin folders and phpinfo() files.
• Keep request validation on (the default in ASP.NET), and use parameterised queries everywhere, including Classic ASP.

Check your work

After saving, open your site and check the response headers in your browser's developer tools (F12 → Network, click the page request). Run curl -I https://yourdomain.com for a quick text view. Test the login, forms and file uploads again, as strict settings occasionally need tweaking.

Need help?

If something doesn't work as described, open a support ticket from your client area or message us on WhatsApp at 01818160926. If you suspect your site has been compromised, tell us straight away so we can help you check it.