What are the key web server hardening best practices?

Reduce the server’s attack surface first

Hardening starts with shrinking what the server exposes. A web server should run only the services, modules, virtual hosts and upload paths it actually needs, because every extra listener, handler or content root expands the space an attacker can probe. Default content, sample apps and unused management interfaces are common sources of accidental exposure and should be removed before the system goes live.

That same principle applies to file-system layout and process separation. The web server should not have broad write access to application code, configuration or system directories, and different applications should not share permissions unless there is a deliberate need. This limits how far a compromise can spread and reduces the chance that one vulnerable site can tamper with another.

Well-run baselines are easiest to maintain when they are compared against a known hardening profile. CIS Benchmarks are a practical reference point for reviewing exposed services, module load order, directory permissions and other configuration drift that tends to accumulate over time.

Patch, configure and encrypt the traffic path correctly

Patch management is a web server control, not just a platform maintenance task. The operating system, web server package, supporting runtime and hosted web applications all need timely updates, because an apparently hardened server can still be compromised through an outdated module or application component. Configuration should also be reviewed after every change, since new virtual hosts, aliases or upload features often introduce exposure that was not present in the original build.

TLS should be configured as part of the hardening baseline, not bolted on later. Use modern protocol settings, valid certificates and secure redirects so that credentials, cookies and other sensitive data are not left travelling in clear text or being downgraded by weak transport choices. If the server terminates TLS at a reverse proxy or load balancer, the same discipline still applies to the internal hop and to any headers that carry security context.

Hardening is strongest when the server is treated as a default-secure platform rather than a collection of ad hoc exceptions. CISA Secure by Design reinforces the idea that secure defaults, reduced exposed functionality and careful configuration should be the starting point, not the remediation step after deployment.

Log the right signals and watch for abuse paths

Request and error logging should be enabled and retained with enough context to support investigation. Logs need to capture authentication failures, unusual response codes, upload activity, path traversal attempts, module errors and changes to virtual host routing, because those are the clues that usually show misconfiguration or early exploitation. Logging is most useful when it is paired with alerting on patterns that indicate scanning, probing or repeated access to sensitive paths.

File upload and public content handling deserve special attention. Upload directories should not execute code, serve untrusted content with unsafe MIME handling, or allow unrestricted filename and path control. The same review should cover directory browsing, backup files, test endpoints and legacy admin pages, since these are often forgotten even when the main application is otherwise well protected.

For teams that want a broader view of how attackers abuse exposed web functions, Web Application Attacks Guide is a useful companion for understanding why misclassified uploads, traversal paths and hidden interfaces matter during hardening reviews.

Risk and Threat Considerations

A weakly hardened web server gives attackers more than a public entry point, it gives them a smaller number of obvious signals and a larger number of places to hide. Unused modules, default content, writable web roots and overly permissive upload handling are all common ways to turn a routine web host into an execution or persistence foothold.

Failure mechanism: The server trusts paths, modules or permissions that were convenient during setup, then exposes them to untrusted internet traffic. That creates opportunities for remote code execution, content tampering, credential theft through exposed files, or lateral movement if the web process can read or modify sensitive system resources.

Impact: A compromise can spread from one site to the whole host, expose application data, and create a durable foothold that survives ordinary service restarts. Misconfigured TLS, logging gaps or forgotten admin interfaces also make incident detection slower and post-compromise cleanup harder.

Practitioner Guidance

What to prioritise: Start with exposed surface area, then move to patching, permissions and logging. If you can only do one review first, inventory what is reachable from the network and what the web server can write to on disk.

What to verify: Confirm that default pages are removed, only required modules are loaded, uploads cannot execute, and the web server identity cannot alter application code or system files. Validate those assumptions after every deployment change, not just during initial build.

Practitioner takeaway: The most effective web server hardening is the combination of minimal exposure, tight file and process boundaries, and continuous configuration review, because most real failures come from configuration drift and forgotten paths rather than the main application itself.

Related resources from NHI Mgmt Group

• What are the key Exchange Server hardening best practices?
• What are the key Virtual Machine Hardening best practices?
• What are the key fax server security best practices?
• What are the best practices for preventing SQL injection in web applications?