IIS security best practices: How to secure an IIS server and web applications

Microsoft’s Internet Information Services (IIS) remains a core component of many enterprise environments, especially where Windows Server, Active Directory, and ASP.NET-based web applications are in use. While it no longer dominates the public internet as it once did, IIS still supports millions of sites and internal systems, making it a relevant and often overlooked attack surface.

Most IIS security guidance focuses on baseline IIS configuration. That is necessary, but it does not reflect how attackers actually approach a web server. In practice, vulnerabilities arise not just from missing controls but from how exposed functionality, authentication mechanisms, and application behavior interact under real conditions.

This guide takes a practical approach to hardening IIS by examining how IIS environments are tested and exploited, how to apply meaningful security controls, and how to continuously validate that your IIS server configuration remains secure over time.

What is IIS security?

IIS security refers to the process of protecting a Microsoft IIS web server and the web applications it hosts from unauthorized access, misconfiguration, and exploitation. This includes securing server configuration, authentication mechanisms, file system permissions, and application-layer vulnerabilities such as SQL injection and cross-site scripting (XSS).

Understanding the IIS server attack surface

What makes IIS a target

The Microsoft IIS ecosystem is tightly integrated with Windows authentication, NTFS permissions, and ASP.NET frameworks. This interconnected functionality increases risk because a weakness in one layer can expose others. For example, a misconfigured web.config file combined with excessive write permissions in the underlying file system can allow an attacker to escalate from a web application issue to direct server access.

In many organizations, IIS is used to host internal tools and APIs behind a firewall and assumed to be safe. In practice, these systems often receive less monitoring and become attractive targets for lateral movement once an attacker gains initial access.

Common IIS misconfigurations attackers exploit

Across real environments, attackers repeatedly find the same patterns. Directory listing may expose file structures and log files, while default pages can reveal incomplete deployments or IIS configuration details. Server headers often disclose Microsoft IIS versions, and weak SSL/TLS configurations can allow downgrade or interception attacks.

Other common issues include unnecessary HTTP methods being enabled and legacy functionality such as WebDAV or FTP remaining active without a clear business need. These weaknesses are rarely critical in isolation, but together they significantly expand the attack surface and enable more targeted attacks.

IIS-specific attack techniques

IIS includes several platform-specific behaviors that attackers actively test for because they can reveal hidden assets or bypass intended controls.

Tilde enumeration is a good example. By exploiting short filename handling, attackers can discover files and directories that are not exposed through normal HTML navigation. This can reveal backup files, configuration artifacts, or legacy endpoints that would otherwise remain hidden.

WebDAV is another frequent target. When enabled unnecessarily or combined with weak authentication and write permissions, it can allow attackers to upload or modify files on the IIS server. Even when not directly exploitable, it expands the available attack surface in ways that are easy to overlook, so it’s good to be familiar with WebDAV authoring rules.

Access to sensitive config files is also a recurring issue. If IIS configuration controls such as request filtering or hidden segments are misconfigured, files such as web.config may be exposed. These can contain connection strings, authentication settings, or other critical data that accelerates further exploitation.

How pentesters approach IIS security

Reconnaissance and fingerprinting

Pentesting an IIS web server begins with identifying its characteristics through response analysis. By examining headers, error messages, and behavior under edge-case requests, testers can determine whether Microsoft IIS or even older environments such as IIS 8 are in use, what modules are enabled, and whether ASP.NET functionality is present.

Even small details, such as how the server handles malformed requests or reveals its IP address handling, can guide further testing.

Enumeration techniques

After fingerprinting, testers move on to systematic enumeration. This involves exploring accessible paths, identifying hidden endpoints, and probing for exposed resources within the file system.

Techniques such as forced browsing, directory traversal attempts, and tilde-based requests are used to uncover files that are not linked in the application interface. This often reveals backup files, log files, or configuration artifacts that provide insight into server configuration and authentication flows.

Exploitation paths in real engagements

In practice, attackers rarely rely on a single issue. Instead, they chain multiple weaknesses into a viable attack path.

For example, directory listing may expose log files or backup archives that contain credentials. Those credentials can then be used to bypass authentication controls or access restricted functionality. In another scenario, an exposed WebDAV endpoint combined with overly permissive write permissions can allow an attacker to upload a malicious file and execute code on the IIS server.

At the application layer, vulnerabilities such as SQL injection or cross-site scripting remain common in IIS-hosted web applications. These risks align with widely recognized categories such as the OWASP Top 10 and are not prevented by IIS hardening alone.

Why manual testing alone doesn’t scale

Manual testing provides depth and context, but it cannot provide continuous coverage. As new web applications are deployed and IIS configuration changes over time, previously secure systems can become vulnerable without clear visibility.

This creates a gap between intended server configuration and actual exposure.

IIS security best practices – how to secure an IIS server

These best practices align with guidance from Microsoft and industry benchmarks such as the CIS Microsoft IIS baseline, focusing on controls that directly reduce real attack paths when hardening IIS.

Reduce server exposure

Limiting exposure begins with removing default content, suppressing unnecessary server headers, and disabling unused modules such as legacy ISAPI extensions. These steps reduce the amount of information available during reconnaissance and make the IIS server less predictable to attackers.

Lock down access and permissions

Access control should follow the principle of least privilege. Application pool identities should have only the permissions they need, and NTFS permissions should restrict access to application directories. Write permissions should be tightly controlled, especially for directories containing config files such as web.config.

Where multiple web applications are hosted on the same IIS server, each should be isolated in its own application pool to prevent cross-application access.

Secure HTTP behavior

HTTP behavior should be restricted to what is required for application functionality. IIS request filtering provides a built-in mechanism to block specific URL patterns, file extensions, hidden segments, and HTTP verbs. Properly configuring request filtering helps prevent access to sensitive paths and reduces the risk of traversal and injection attacks.

Disable risky or legacy features

Features such as WebDAV, FTP services, and legacy handlers should be disabled unless explicitly required. Even when needed, they should be carefully configured and monitored to prevent misuse. Short filename handling should also be reviewed, as it can enable enumeration techniques that expose hidden resources.

Strengthen SSL and transport security

All IIS deployments should enforce secure communication using modern SSL/TLS configurations by disabling legacy protocols such as TLS 1.0 and 1.1 and requiring TLS 1.2 or higher, with TLS 1.3 enabled where supported.

Harden ASP.NET applications on IIS

Application-level controls are critical for securing web applications running on IIS. This includes protecting VIEWSTATE integrity, securing machine keys, and disabling debugging features in production. Authentication mechanisms, including anonymous authentication and Windows authentication, should be configured based on the application’s requirements and risk profile.

Keep IIS and Windows Server patched

Regular patching is critical. IIS and Windows Server updates should be tracked through the Microsoft Security Update Guide to ensure known vulnerabilities are addressed promptly.

IIS security checklist for quick reference

Exposure controls

• Disable directory listing
• Remove default pages and sample applications
• Hide IIS version and server headers

Access and authentication

• Apply least-privilege NTFS permissions
• Secure web.config and other config files
• Configure authentication (anonymous and Windows authentication) securely

Protocol and transport

• Disable unnecessary HTTP methods
• Enforce modern SSL/TLS configurations

Features and services

• Disable WebDAV and FTP unless required

Monitoring and visibility

• Configure IIS logging
• Monitor log files for anomalies

Why continuous validation is critical for IIS security

Even when all these controls are in place, they only reflect the intended IIS configuration. What matters is whether those controls actually hold up under real-world conditions.

Why one-time configuration is not enough

IIS environments evolve continuously as applications are updated, new functionality is introduced, and configuration changes are made. Over time, this leads to configuration drift, where the actual state of the IIS server no longer matches the original baseline.

Without continuous validation, these gaps can remain undetected until they are exploited.

What automated IIS vulnerability scanning should cover

Automated scanning should reflect how attackers interact with an IIS server. This includes detecting misconfigurations such as directory listing, exposed WebDAV functionality, unsafe HTTP methods, and improper request filtering. It should also identify IIS-specific issues such as tilde enumeration, which can reveal hidden resources.

At the same time, scanning must cover application-layer vulnerabilities in ASP.NET web applications, including SQL injection, XSS, and authentication weaknesses. This ensures that both server configuration and application behavior are evaluated together.

Benefits of DAST for IIS environments

Dynamic application security testing provides an outside-in perspective by interacting with running web applications and services. This approach helps identify vulnerabilities that are actually reachable and exploitable, rather than theoretical issues based solely on configuration.

By continuously testing the IIS web server and the applications it hosts, teams can detect configuration drift, uncover hidden endpoints, and validate that security controls remain effective. Advanced scanning techniques can also confirm exploitability for certain classes of vulnerabilities, reducing the effort required to validate findings manually.

Combining pentesting and automated scanning

Pentesting and automated scanning serve complementary roles in IIS security. Manual testing provides depth and insight into complex attack paths, while automated scanning ensures consistent and repeatable coverage across environments.

Together, they allow organizations to maintain a realistic and continuously updated understanding of their security posture.

Conclusion: Moving from IIS hardening to continuous IIS security assurance

Securing Microsoft IIS requires more than applying a checklist. It involves understanding how attackers interact with the web server, reducing unnecessary exposure, and ensuring that both server configuration and web applications are aligned with security best practices.

Hardening IIS establishes a strong baseline, but ongoing validation is what keeps systems secure as they evolve. By combining targeted configuration controls with continuous testing, organizations can move from static security baselines to a more resilient approach.

In short, IIS security best practices focus on reducing attack surface, enforcing strong configuration and authentication controls, and continuously validating real-world exposure through testing. Regularly testing your IIS environment with a modern DAST solution like Acunetix helps ensure that both server configuration and web applications remain secure over time – see how this works in practice by scheduling a demo.