Apache HTTP Server Hardening Guide

Apache HTTP Server (httpd) will serve any file it can map from a URL unless you tell it not to, and most httpd compromises come from that default, from unpatched releases or from the code and secrets that sit behind it. CISA's Known Exploited Vulnerabilities catalog lists four httpd flaws, including the 2021 path traversal pair CVE-2021-41773 and CVE-2021-42013, which only reached files outside aliased directories where the default deny on the filesystem root had been removed. This guide covers how authentication and authorisation work in httpd 2.4, who should control the server, how to handle proxy, API and service credentials, what to log, and a hardening baseline built from the Apache project's own documentation. It is for web platform engineers, Linux administrators and application security teams. For the application layer, see the PHP and WordPress Security Guide.

Key takeaways

Deny by default at the filesystem root. A <Directory "/"> block with Require all denied and AllowOverride None, then explicit grants, is the single control that defeated the exploited 2021 traversal bugs where it was kept.
Patch on the project's cadence. Subscribe to the Apache announcements list and track the 2.4 vulnerabilities page; exploited flaws have been fixed in point releases within days of disclosure.
Basic authentication needs TLS and strong hashes. Apache states Basic sends passwords unencrypted and that Digest is no longer more secure; use TLS, bcrypt in htpasswd files, or an external identity provider.
Root owns the server, the server user owns nothing. If a non-root user can write to the binary, configuration or log directory, they can escalate to root.
Secrets behind the web root leak through the web root. Block dotfiles such as .env and .git, keep password files and private keys outside the URI space, and treat proxy and backend credentials as non-human identities.

How identity and access work in Apache httpd

httpd 2.4 separates authentication (who are you) from authorisation (what may you reach), with core modules mod_authn_core and mod_authz_core tying them together.

Layer	Modules	Use	Security notes
Authentication type	`mod_auth_basic` (`AuthType Basic`), `mod_auth_digest`	Browser or client challenge	Basic sends the password in clear: only over TLS. Apache says Digest is no longer more secure than Basic over TLS
Authentication providers	`mod_authn_file`, `mod_authn_dbm`, `mod_authn_dbd`, `mod_authnz_ldap`, `mod_authn_socache`	Where credentials are checked	Providers are tried in order listed in `AuthBasicProvider`; caching reduces load on databases and directories
Authorisation	`mod_authz_user`, `mod_authz_groupfile`, `mod_authz_host`, `mod_authz_dbd`, `mod_authnz_ldap`	`Require user`, `Require group`, `Require ip`, `Require ldap-group`	Multiple `Require` lines act as `<RequireAny>` by default; use `<RequireAll>` when every condition must hold
Client certificates	`mod_ssl` (`SSLVerifyClient`, `SSLCACertificateFile`)	Mutual TLS for APIs and admin paths	The CA file is read at startup and needs a restart to change. See the mTLS Guide
Legacy	`mod_access_compat` (`Order`, `Allow`, `Deny`)	2.2-era configuration	Deprecated; mixing with `Require` causes surprising merge results. Migrate

Decision guidance for authentication

Small internal tool: Basic over TLS with a bcrypt htpasswd file (htpasswd -B -C 12) and an IP restriction is acceptable. The htpasswd default is Apache MD5; SHA-1 and crypt() are described by Apache as insecure by today's standards.
Corporate users: authenticate at an identity provider (OpenID Connect or SAML module, or a reverse proxy that does SSO) rather than storing passwords on the web server. Use LDAP binds only over LDAPS or StartTLS.
Machine clients and APIs: prefer mutual TLS or tokens validated by the application or gateway; avoid shared Basic credentials embedded in scripts.

Always keep password files outside the document root: the htpasswd manual states they should not be within the server's URI space. Never use htpasswd -b in scripts, because the password appears on the command line.

Admin roles and privileged access

Ownership model: httpd starts as root and switches to the account set in User and Group. The Apache security tips require that files executed by root, and their parent directories, are writable only by root; the example sets the httpd binary to mode 511. Content directories may be writable by publishers because root never executes from them.
Log directory: if the logs directory or log files are writable by a non-root user, that user can replace a log with a symlink and gain root. Keep logs owned by root.
Who edits configuration: configuration changes are privileged changes. Manage httpd.conf and virtual host files through configuration management with review, restrict shell access to web administrators, and use sudo rules limited to apachectl or service restarts. See the sudo and sudoers Security Guide.
Per-directory overrides: AllowOverride None (the default since 2.3.9) stops content owners using .htaccess to undo your controls. Where a CMS needs overrides, allow only the specific classes required, for example AllowOverride FileInfo, on that directory.
Server status and info pages: /server-status shows the hosts and requests currently being processed, and ExtendedStatus is on by default once mod_status is loaded. Restrict it with Require ip to monitoring hosts, or unload it. The same applies to mod_info's /server-info, which reveals the full configuration.
Dynamic code privileges: CGI scripts and embedded engines such as mod_php run as the server user and can reach anything that user can. Use suEXEC or separate PHP-FPM pools per site with their own accounts to isolate applications.

Integrations, API tokens and service accounts

httpd is often the front door to applications, and the credentials it holds or exposes are non-human identities.

Credential or identity	Where it lives	Risk	Control
TLS private keys	Paths in `SSLCertificateKeyFile`	Theft allows impersonation of the site	Root-owned, mode 600, outside web root; automate renewal. See the TLS Server Configuration Baseline Guide
Backend credentials for reverse proxy	`RequestHeader set Authorization` lines, client certificates for `SSLProxyMachineCertificateFile`	Anyone reading the config holds the backend key	Prefer mTLS to backends; restrict config file permissions; rotate
LDAP bind account	`AuthLDAPBindDN` and `AuthLDAPBindPassword`	Static directory credential in clear in the config	Read-only account scoped to the search base; LDAPS; rotate; consider external password retrieval
Application secrets	`.env` files, config files, `.git` directories under the document root	Downloadable if not denied	Deny dotfiles; deploy builds without repository metadata; keep secrets in a vault. See the Secrets Management Guide
Server user account	`User`, typically `apache` or `www-data`	Compromise of any application gives this identity	No login shell, no write access to code, separate users per application where possible

Reverse proxy and forward proxy rules

Never run an open proxy: Apache warns not to enable ProxyRequests until the server is secured, and that open proxies are dangerous to your network and the internet. Keep ProxyRequests Off when using ProxyPass.
Access control on proxies: <Proxy> matching does not canonicalise hostnames or IP addresses, so deny by default and allow expected hosts, rather than denying a list of bad forms.
Path mapping to Java backends: when authorisation is enforced in <Location> blocks for paths proxied to Tomcat or other servlet containers, use mapping=servlet so path parameters cannot bypass the rules. Avoid nocanon unless required. See the Apache Tomcat Hardening Guide.
Forwarded headers: backends must not trust X-Forwarded-For blindly; Apache notes these headers can contain several values if the client already sent one. Use mod_remoteip with a defined list of trusted proxies.

Hardening baseline

Area	Directive or action	Recommended setting
Default deny	`<Directory "/">`	`AllowOverride None` and `Require all denied`, then grant only document roots
Location overrides	`<Location "/">`	Avoid broad `Location` grants that reopen what `Directory` denied
Dotfiles	`<FilesMatch "^\.(?!well-known)">`	`Require all denied` (blocks `.env`, `.git`, `.htpasswd`, keeps ACME challenges working)
User directories	`UserDir`	Disable, or at least `UserDir disabled root`
Options	`Options`	Remove `Indexes` and `ExecCGI` where not needed; prefer `SymLinksIfOwnerMatch` to `FollowSymLinks` on shared content
Server-side includes	`Options IncludesNOEXEC`	Only on a distinct extension such as `.shtml`, never on `.html`
CGI	`ScriptAlias`	CGI only in administrator-controlled directories; suEXEC for per-user execution
Information disclosure	`ServerTokens`, `ServerSignature`	`ServerTokens Prod`, `ServerSignature Off`
HTTP methods and parsing	`TraceEnable`, `HttpProtocolOptions`	`TraceEnable Off`; keep `Strict` parsing (the default) and consider `Require1.0`
TLS	`SSLProtocol`, `SSLCipherSuite`, `SSLCompression`, `SSLInsecureRenegotiation`	TLS 1.2 and 1.3 only, modern AEAD ciphers, compression off and insecure renegotiation off (both defaults); HSTS through `mod_headers`
Resource limits	`RequestReadTimeout`, `TimeOut`, `KeepAliveTimeout`, `LimitRequestBody`, `LimitRequestFields`, `MaxRequestWorkers`	Tune to the application; the `LimitRequestBody` default became 1 GiB after 2.4.53 (previously unlimited)
Modules	`LoadModule`	Unload what you do not use (`mod_status`, `mod_info`, `mod_userdir`, `mod_autoindex`, `mod_dav`, proxy modules) to reduce attack surface
Filesystem	Ownership	Binary, configuration and log directories owned by root; content not writable by the server user

CIS publishes an Apache HTTP Server 2.4 benchmark covering similar ground; use it if your configuration standard is CIS-based. See the CIS Benchmarks Guide.

Rolling out changes safely

Inventory every httpd instance and version, including those embedded in appliances and vendor products, and compare with the 2.4 vulnerabilities page.
Upgrade to the current 2.4 release first. Hardening an unpatched server is wasted effort while known exploited flaws remain.
Capture the effective configuration (apachectl -S for virtual hosts, apachectl -M for loaded modules) and keep it in version control.
Apply baseline changes in a staging copy and run apachectl configtest before every reload. Apache warns that configuration merging is complex and directive-specific, so test access rules with real requests, including encoded and double-slash paths.
Deploy to one node behind the load balancer, watch error rates and the error log, then roll forward. Roll back by redeploying the previous configuration commit and reloading.
After CVE-2024-38475 was fixed in 2.4.60, some unsafe RewriteRule patterns stopped working. Rewrite them rather than reaching for the UnsafePrefixStat flag, which Apache allows only after confirming the substitution is constrained.

Logging and detection

Access logs: use a LogFormat that includes client address (after mod_remoteip), authenticated user, request line, status, bytes, referer, user agent, virtual host and request duration. Forward to your SIEM.
Error log: keep LogLevel at the default warn or raise specific modules (for example LogLevel warn authz_core:info) to capture denials. Apache's tips suggest searching for client denied entries and for traversal patterns.
Sensitive file probes: a 200 response for .env, .git/config or backup files is a misconfiguration; a stream of 403 responses is scanning. Both are worth alerts.
Exploitation signals: requests containing encoded traversal sequences to CGI paths, unexpected POST requests to static paths, and new executable files in content directories can indicate exploitation of public-facing software (T1190 Exploit Public-Facing Application) or a web shell (T1505.003 Web Shell).
File integrity: monitor the configuration directory, module directory and document roots for changes outside deployments.

Metric	Healthy signal
Instances on the current 2.4 release	100 percent within your patch window; KEV-listed fixes within CISA due dates
Instances passing the baseline check (default deny, dotfiles, tokens, TLS)	All internet-facing instances
Successful responses to sensitive file paths	Zero
Status and info pages reachable from untrusted networks	Zero
Static credentials in httpd configuration (bind passwords, header tokens)	Inventoried, owned and rotated; falling count

Framework mapping

Framework	Reference	httpd control
NIST SP 800-53 Rev. 5	CM-6 Configuration Settings; CM-7 Least Functionality	Baseline directives; unloading unused modules
NIST SP 800-53 Rev. 5	AC-3 Access Enforcement; SC-8 Transmission Confidentiality and Integrity	Default deny and `Require` rules; TLS configuration
NIST SP 800-53 Rev. 5	AU-2 Event Logging; AU-12 Audit Record Generation; SI-2 Flaw Remediation	Access and error logging; tracking the 2.4 vulnerabilities page
CIS Controls v8.1	Control 4 Secure Configuration; Control 7 Continuous Vulnerability Management	Hardened configuration and patching. See the CIS Control 7 Continuous Vulnerability Management Guide
MITRE ATT&CK v20	T1190; T1505.003; T1552.001 Credentials In Files	Patching and default deny; integrity monitoring; dotfile blocking and secret removal
CISA KEV	CVE-2021-41773, CVE-2021-42013, CVE-2024-38475, CVE-2019-0211	Prioritise these releases on any remaining instance

Common misconfigurations

Removing the root deny: the default <Directory "/"> deny was replaced with a grant during troubleshooting, which is exactly the condition under which CVE-2021-41773 (2.4.49 only) and CVE-2021-42013 (2.4.49 and 2.4.50) exposed files and, with CGI enabled, allowed code execution.
Repository and environment files in the web root: deployments copy .git directories and .env files into served paths. In the Indian government breach, exposed .git directories and 23 .env files gave researchers API keys and database credentials.
Public server-status: /server-status left reachable shows internal client addresses and full request URLs, sometimes with tokens in query strings.
Accidental open proxy: ProxyRequests On enabled for testing turns the server into a relay for abuse and for requests into internal networks.
Writable code and logs: the server user or a deployment account can write to code, modules or log directories, so one application bug becomes persistence or root.
Weak htpasswd hashes: files created with SHA-1 or crypt(), or with the MD5 default, protect admin areas that are then exposed without TLS.

Practitioner checklist

Inventory every httpd instance and version, and upgrade to the current 2.4 release; subscribe to the Apache announcements list.
Keep <Directory "/"> with AllowOverride None and Require all denied, and grant only document roots.
Deny dotfiles while allowing .well-known, and remove .git and .env from build artefacts.
Set ServerTokens Prod, ServerSignature Off and TraceEnable Off; unload unused modules.
Restrict TLS to 1.2 and 1.3 with modern ciphers, and protect private keys as root-only files.
Use TLS for any Basic authentication, bcrypt for htpasswd files, and an identity provider for corporate users.
Restrict /server-status and /server-info to monitoring addresses or remove them.
Keep ProxyRequests Off, use mapping=servlet for servlet backends, and configure mod_remoteip with trusted proxies only.
Inventory and rotate credentials in httpd configuration (LDAP bind, backend tokens, proxy certificates).
Ship access and error logs to the SIEM and alert on successful sensitive file requests and configuration changes.

Apache HTTP Server Hardening Guide: Access Control, TLS, Logging and Safe Configuration