A default installation of Nginx or Apache is built to work, not to resist attack. Every default configuration file ships with settings optimized for compatibility and ease of first-time setup — verbose error pages, permissive header disclosure, protocol support reaching back to versions with known weaknesses, and directory structures that assume a trusted operator rather than a hostile internet. Hardening a web server means systematically closing that gap between “works out of the box” and “survives sustained, automated attack traffic,” and doing it in a way that doesn’t quietly break the application running on top.
This guide walks through server-level hardening for both Nginx and Apache, the firewall architecture that should sit in front of either, and the operational discipline that keeps a hardened configuration hardened over time rather than drifting back toward its defaults through months of incremental changes. It’s written for architects and engineers who are past the “how do I install a web server” stage and need a concrete, prioritized hardening checklist grounded in actual attack patterns rather than a generic security theory.
Why Web Servers Remain the Most Targeted Layer
Public-facing web servers occupy a specific position in the threat landscape: they are, by definition, reachable from anywhere on the internet, they run complex software with a large attack surface, and they frequently sit directly in front of the application logic and data an attacker actually wants. This combination has made web servers a persistent, primary target for automated scanning and exploitation since the earliest days of the commercial internet, and federal guidance on securing public-facing web infrastructure has long emphasized that network design and perimeter controls alone cannot substitute for hardening the server software itself — the two have to work together as layered, complementary defenses (nist.gov).
The practical implication is that hardening isn’t a single task you complete once during deployment. It’s a layered set of controls applied at the operating system, the web server process, the application configuration, and the network perimeter, each addressing a different class of attack, and each requiring ongoing maintenance as new vulnerabilities and attack techniques emerge.
Foundational Hardening: Before You Touch Nginx or Apache Configuration
Several controls apply regardless of which web server software you run, and skipping them undermines everything else in this guide.
Principle of Least Privilege for the Server Process
Both Nginx and Apache should run as a dedicated, unprivileged user account, never as root, and that account should have write access only to the specific directories it genuinely needs — log directories and any explicitly configured upload paths, nothing else. Web server binaries, configuration files, and served content should be owned by a different user than the one the server process runs as, so that a compromised worker process cannot modify the server’s own configuration or the content it serves.
Operating System and Patch Discipline
A hardened web server configuration running on an unpatched kernel or an outdated TLS library provides a false sense of security. Automated patch management, subscription to vendor and CERT security advisories relevant to your specific server software and OS distribution, and a documented patching SLA tied to vulnerability severity are prerequisites, not optional extras. Guidance from university information security offices responsible for securing institutional web infrastructure consistently identifies routine patching and monitoring of security advisory mailing lists as a baseline, non-negotiable control rather than an advanced practice (cmu.edu).
Filesystem Segmentation
Web content, server binaries, and log files should live on separate filesystem partitions or volumes where practical. This limits the damage a filesystem-filling attack (log flooding, upload-based disk exhaustion) can do to unrelated parts of the system, and it makes it straightforward to mount content and log directories with restrictive options — noexec, nosuid — that prevent a successful upload-based compromise from executing arbitrary code directly from a web-writable directory.
Nginx Hardening in Depth
Nginx’s architecture — a small number of worker processes handling large volumes of concurrent connections — makes certain classes of hardening particularly high-leverage.
Suppress Version and Server Signature Disclosure
By default, Nginx includes its version number in the Server response header and in default error pages. This information is low-cost reconnaissance for an attacker fingerprinting known vulnerabilities tied to specific version ranges. The server_tokens directive, set to off within the http block, removes the version number from both the header and default error pages, and pairing it with a custom, minimal error page configuration removes further fingerprinting surface from 404 and 500 responses.
Restrict HTTP Methods to What the Application Actually Needs
Most web applications only require GET, POST, and HEAD. Leaving TRACE, PUT, DELETE, and other methods enabled at the server level, when the application never uses them, expands attack surface for no functional benefit. A limit_except-style method restriction, or explicit rejection of unused methods via a conditional return of an appropriate error status, closes this off. TRACE in particular has a documented history of enabling cross-site tracing attacks against session cookies and should be disabled unless there’s a specific, justified need for it.
Enforce Modern TLS Configuration
TLS configuration is one of the highest-value, lowest-effort hardening steps available. Disable TLS versions below 1.2 entirely — TLS 1.0 and 1.1 carry known protocol-level weaknesses and have been formally deprecated by the Internet Engineering Task Force. Configure the ssl_protocols directive to permit only TLSv1.2 and TLSv1.3, set ssl_prefer_server_ciphers to on so the server’s vetted cipher preference order takes precedence over a client’s potentially weaker request, and restrict the cipher suite list to modern, forward-secrecy-supporting suites rather than accepting the distribution’s full default list. Enabling HTTP Strict Transport Security through the Strict-Transport-Security header, with a meaningful max-age value and the includeSubDomains directive where appropriate, prevents downgrade attacks that attempt to force a client back onto an unencrypted connection.
Rate Limiting and Connection Controls
Nginx’s limit_req and limit_conn modules provide effective, low-overhead protection against both brute-force login attempts and basic denial-of-service patterns. A sensible baseline defines a rate-limiting zone keyed on client IP address, applies a conservative request rate to sensitive endpoints like login and password-reset forms specifically, and pairs this with a connection limit per IP to prevent any single client from monopolizing worker connections during a slow-request or connection-exhaustion attempt. These controls should be tuned against real traffic patterns — set too aggressively, they generate false positives against legitimate users behind shared NAT gateways or corporate proxies.
Restrict Access to Sensitive Paths and Hidden Files
Configuration should explicitly deny access to dotfiles (.git, .env, .htaccess remnants from migrated Apache configurations), backup file patterns, and any administrative or internal-only paths that shouldn’t be reachable from the public internet at all. A location block matching a leading dot in the URI path, returning a 404 rather than a 403 (to avoid confirming the file’s existence), is a standard, low-cost pattern that closes off a surprisingly common source of accidental data exposure — deployment artifacts and version control metadata left behind in a web root.
Buffer Size and Request Limits
Setting explicit limits on client_max_body_size, client_body_buffer_size, and large_client_header_buffers prevents both accidental resource exhaustion from oversized uploads and deliberate attempts to exploit buffer-handling edge cases through abnormally large headers or request bodies. These should be set to the smallest value that accommodates your application’s legitimate maximum, not left at generous defaults sized for unknown future use cases.
Apache Hardening in Depth
Apache’s module-based architecture creates a different, though overlapping, set of hardening priorities compared to Nginx.
Disable Unnecessary Modules
Apache’s default installation on most distributions enables far more modules than a typical deployment actually needs. Every enabled module is additional code running in the server process and additional attack surface. A hardening pass should audit the loaded module list and disable anything not in active use — mod_status and mod_info in particular expose internal server state and should either be disabled entirely on production systems or restricted to internal management networks only through explicit access controls, never left reachable from the public internet.
Suppress ServerTokens and ServerSignature
Analogous to Nginx’s server_tokens directive, Apache’s ServerTokens should be set to Prod, reducing the Server header to the minimum “Apache” string without version or module details, and ServerSignature should be set to Off, removing the version-disclosing footer Apache appends to default error and directory-listing pages.
Disable Directory Listing and Enforce Explicit Access Rules
The Options directive should explicitly exclude Indexes wherever directory listing isn’t a deliberate, intended feature, preventing automated directory browsing when an index file happens to be missing. Combined with a default-deny access policy at the top-level configuration — Require all denied as the baseline, with explicit Require directives opening access only where genuinely needed — this closes off accidental exposure of directories that were never meant to be browsable.
Restrict .htaccess Override Scope
AllowOverride, when left at its permissive default, lets .htaccess files in content directories override core server security settings, which is both a performance cost (Apache has to check for .htaccess files on every request) and a security risk if an attacker gains write access to any content directory. Setting AllowOverride to None globally, and enabling only the specific override categories genuinely required by the application in narrowly scoped directory blocks, keeps this surface tightly controlled.
Harden TLS and HTTP Header Configuration
The same TLS protocol and cipher restrictions described for Nginx apply directly to Apache through mod_ssl’s SSLProtocol and SSLCipherSuite directives. Security-relevant response headers — X-Content-Type-Options set to nosniff, X-Frame-Options or a Content-Security-Policy frame-ancestors directive to control framing, and Referrer-Policy configured to limit referrer leakage to third-party destinations — should be set through mod_headers rather than left to application-layer defaults, ensuring consistent enforcement regardless of what any individual application component does or doesn’t set on its own.
Limit Request Size and Timeout Behavior
Apache’s LimitRequestBody, LimitRequestFields, and Timeout directives serve the same purpose as Nginx’s buffer and body-size limits: bounding the resources a single request can consume and reducing exposure to slow-request denial-of-service techniques, where an attacker opens connections and sends data at a deliberately slow rate to exhaust available worker threads or processes. mod_reqtimeout, enabled with conservative header and body timeout values, directly mitigates this class of attack.
Comparing Key Hardening Controls Across Both Servers
The table below maps equivalent hardening controls across the two platforms, useful as a reference when auditing a mixed environment or migrating configuration intent from one server to the other.
| Hardening goal | Nginx directive | Apache directive |
|---|---|---|
| Suppress version disclosure | server_tokens off | ServerTokens Prod, ServerSignature Off |
| Restrict TLS protocol versions | ssl_protocols TLSv1.2 TLSv1.3 | SSLProtocol -all +TLSv1.2 +TLSv1.3 |
| Rate limit requests per client | limit_req zone | mod_ratelimit or third-party module |
| Prevent directory listing | autoindex off | Options -Indexes |
| Restrict HTTP methods | limit_except block | LimitExcept block |
| Enforce HSTS | add_header Strict-Transport-Security | Header always set Strict-Transport-Security |
| Limit request body size | client_max_body_size | LimitRequestBody |
| Mitigate slow-request attacks | client_body_timeout, client_header_timeout | mod_reqtimeout |
Firewall Architecture: The Layer Beneath the Web Server
Server-level hardening reduces what an attacker can do once traffic reaches the web server process. Firewall architecture determines what traffic reaches that process in the first place, and a well-designed perimeter meaningfully reduces the volume and variety of attacks the application layer ever has to handle.
Host-Based Firewall as the First Line
Even behind a network firewall or cloud security group, the host itself should run a host-based firewall — iptables, nftables, or firewalld on Linux — configured with an explicit default-deny inbound policy, opening only the specific ports genuinely required: typically 443 for HTTPS, 80 for HTTP-to-HTTPS redirection only, and a restricted, IP-allowlisted port for administrative SSH access. Every other inbound port should be closed by default, not merely unused.
Network-Level Segmentation
Web servers should sit in a segmented network zone — commonly a demilitarized zone (DMZ) — with explicit, narrow firewall rules governing what the web tier can reach on the backend network, rather than flat network access to databases and internal services. A compromised web server in a properly segmented architecture is contained to the web tier; a compromised web server with unrestricted access to backend systems becomes a pivot point for lateral movement across the entire environment.
Web Application Firewall as a Distinct Layer
A Web Application Firewall (WAF) operates at a different layer than a network firewall, inspecting HTTP request content itself rather than just packet headers and ports, and it catches attack patterns — SQL injection payloads, cross-site scripting attempts, known exploit signatures for specific CMS vulnerabilities — that a conventional firewall has no visibility into. Both Nginx and Apache support WAF functionality through modules (ModSecurity being the most widely deployed cross-platform option), and cloud and CDN-based WAF services provide equivalent protection at the network edge, before traffic ever reaches the origin server. A WAF is a complementary control, not a replacement for the server-level hardening described above — it catches malicious request patterns, but it doesn’t fix an underlying misconfiguration in the server itself.
Rate Limiting and DDoS Mitigation at the Network Edge
Volumetric and protocol-level denial-of-service attacks are generally better absorbed at the network edge — through a CDN, a cloud provider’s DDoS mitigation service, or an upstream network firewall with connection-rate thresholds — than at the individual server’s application-layer rate limiting alone, since the goal is to prevent malicious traffic from ever consuming server or bandwidth resources in the first place. Application-layer rate limiting on the web server remains valuable as a secondary control for attacks that pass through the edge layer looking like legitimate individual requests, such as credential-stuffing attempts against a login endpoint.
Firewall Rule Hygiene and Common Configuration Mistakes
Firewall architecture is undermined as often by rule sprawl and misconfiguration as by any deliberate attack, and a few recurring mistakes deserve explicit attention.
- Overly broad source address ranges. Rules permitting administrative access from “any” source address, even when the destination port itself is restricted, defeat the purpose of restricting the port in the first place. Administrative access should be scoped to specific, known source IP ranges or, better, routed through a VPN or bastion host rather than exposed directly.
- Stale rules from decommissioned services. Firewall rule sets accumulate entries for services and ports that were needed during a prior project phase and never removed. A periodic audit against actually-running services, cross-referenced against the current firewall rule set, catches this drift before it becomes an unmonitored open door.
- Logging disabled or ignored. A firewall rule set without logging on denied connection attempts provides no visibility into reconnaissance activity or attack patterns targeting the perimeter. Denied-connection logs, reviewed regularly or fed into a centralized monitoring pipeline, are one of the earliest indicators of targeted scanning against a specific server.
- No distinction between management and data plane access. Administrative interfaces — SSH, server status pages, monitoring dashboards — should never share the same firewall exposure profile as the public-facing web service itself. Conflating the two means a single overly permissive rule change can expose management interfaces that were never intended to be internet-reachable.
Ongoing Maintenance: Keeping a Hardened Configuration Hardened
Hardening is not a one-time project. Configuration drift, well-intentioned troubleshooting changes that are never reverted, and new vulnerabilities disclosed against server software all erode a hardened baseline over time if there’s no process to catch it.
- Version-control your server and firewall configuration. Treating Nginx, Apache, and firewall rule configuration as code — under version control, with changes reviewed before deployment — creates an audit trail and makes unauthorized or accidental drift immediately visible against a known-good baseline.
- Run periodic configuration audits against a documented baseline. Automated configuration scanning tools can compare a live server’s actual settings against your organization’s hardening standard, flagging deviations introduced through manual troubleshooting or incomplete rollbacks.
- Subscribe to and act on vendor security advisories. Nginx, the Apache Software Foundation, and your Linux distribution all publish security advisories for their respective components. A documented process for triaging and applying these — with a defined SLA scaled to severity — closes the gap between disclosure and remediation that automated exploitation tools are specifically built to exploit.
- Test hardening changes against real application behavior before production rollout. Overly aggressive rate limiting, method restrictions, or header policies can break legitimate application functionality — a webhook integration that relies on a restricted HTTP method, a legitimate API client that needs a larger request body limit than the new default allows. Staging environment validation before production deployment prevents hardening work from becoming an unplanned outage.
- Review access logs for evidence that hardening controls are actually working. A rate-limiting rule that never triggers might mean an attack pattern isn’t occurring, or it might mean the rule is misconfigured and never actually engaging. Correlating expected control behavior against real log data confirms the hardening is functioning as designed, not just present in the configuration file.
Closing Perspective
Hardening Nginx, Apache, and the firewall layer beneath them is fundamentally about closing the gap between a default configuration optimized for compatibility and a production configuration built to survive the internet’s baseline level of automated hostility. No single directive or firewall rule accomplishes this alone — it’s the combination of least-privilege process design, restrictive TLS and HTTP configuration, disciplined firewall segmentation, and ongoing maintenance discipline that produces a server genuinely resistant to the attack patterns it will face continuously, not just during an initial security review.
The organizations that maintain strong web server security over the long term treat this guide’s contents as a living operational standard, revisited on a schedule and enforced through configuration management and monitoring, rather than a one-time checklist completed at launch and never revisited again.