Apache HTTP Server still powers over 30% of the web — especially on cPanel/WHM servers and OVH dedicated hosting. Its default configuration exposes your server version, allows directory browsing, and sends no security headers. This guide fixes every issue.
A default Apache installation broadcasts detailed version information, lists the contents of directories without index files, loads modules you never use, and sends zero security headers. This tells attackers exactly what you are running and where to probe. Most successful attacks exploit default configurations, not zero-day vulnerabilities.
An unhardened Apache server is a gift to automated scanners. They detect the version, look up matching CVEs, and start exploiting within seconds. For WAF protection without the complexity of compiling ModSecurity, Defensia reads Apache access logs and detects attacks automatically. Each section below targets a specific risk with a concrete fix.
By default, Apache sends a Server: Apache/2.4.57 (Ubuntu) OpenSSL/3.0.13 header with every response. This reveals your exact version, operating system, and linked libraries. Two directives fix this.
# Only show "Apache" — no version, no OS, no modules
ServerTokens Prod
# Remove version from error pages
ServerSignature Off
ServerTokens Prod reduces the Server header to just Apache. ServerSignature Off removes the version line from error pages (403, 404, 500). Both must be set in the main server config, not in .htaccess. Restart Apache with apachectl -t && systemctl restart apache2.
When a directory has no index file, Apache shows a browsable file listing by default. Attackers use this to find configuration files, backup archives, and database dumps that were never meant to be public.
<Directory /var/www/html>
Options -Indexes
</Directory>
The -Indexes option disables auto-generated directory listings. Without it, anyone can browse /uploads/, /backups/, or any directory missing an index.html. Apply this to your document root and any other served directories. You can also add Options -Indexes in a .htaccess file for per-directory control.
Apache requires mod_headers (enabled by default on most distributions) to set security headers. Add these directives to httpd.conf, a virtual host, or .htaccess.
# Prevent clickjacking
Header always set X-Frame-Options "SAMEORIGIN"
# Prevent MIME-type sniffing
Header always set X-Content-Type-Options "nosniff"
# Enable XSS protection in older browsers
Header always set X-XSS-Protection "1; mode=block"
# Force HTTPS for 1 year
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# Restrict resource loading to same origin
Header always set Content-Security-Policy "default-src 'self'"
# Disable unused browser features
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
# Control referrer information
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Ensure mod_headers is enabled: a2enmod headers && systemctl restart apache2. The always keyword ensures headers are sent even on error responses (403, 404, 500), not just successful ones.
Every loaded module increases your attack surface. Apache ships with many modules enabled by default that most servers never use. Disable what you don't need.
# Server status page — exposes detailed server info
a2dismod status
# Auto-generated directory listings (already blocked by -Indexes)
a2dismod autoindex
# CGI scripts — if you don't use them
a2dismod cgi
a2dismod cgid
# User home directories — if you don't serve ~/public_html
a2dismod userdir
# Server-side includes — rarely used, potential for code injection
a2dismod include
# Restart after disabling
systemctl restart apache2
mod_status is especially dangerous: it exposes active connections, request rates, worker status, and client IPs at /server-status. If you must keep it, restrict access to localhost with Require local. List currently loaded modules with apachectl -M.
ModSecurity is an open-source Web Application Firewall that runs as an Apache module. Combined with the OWASP Core Rule Set (CRS), it detects SQL injection, XSS, path traversal, and other OWASP Top 10 attacks inline.
| Aspect | mod_security + CRS | Defensia WAF |
|---|---|---|
| Installation | apt install libapache2-mod-security2 | curl | bash (60 seconds) |
| Configuration | OWASP CRS (~200 rule files) | Zero config |
| Apache changes | Yes (LoadModule, SecRuleEngine) | None |
| Performance | Inline (adds latency per request) | Reads logs async (zero overhead) |
| Attack types | 15+ (OWASP CRS) | 15+ (same OWASP types) |
| False positives | Manual rule exclusions | Scoring engine (auto-threshold) |
| Blocking | Rejects HTTP request inline | iptables (blocks all traffic from IP) |
| Dashboard | None (audit.log files) | Real-time web dashboard |
| Price | Free (open source) | Free (1 server), Pro EUR 9/mo |
ModSecurity is powerful but complex. It inspects every request inline, which adds latency. The OWASP CRS contains over 200 rule files that require tuning to avoid blocking legitimate traffic. Defensia takes a different approach: it reads your Apache access logs asynchronously, detects the same OWASP attack patterns, and blocks offending IPs via iptables. No Apache module installation, no rule tuning, no performance overhead. Learn more about Defensia WAF →
Apache's mod_ssl handles TLS termination. A modern configuration disables legacy protocols, uses forward-secrecy ciphers, and enables OCSP stapling.
# Disable SSLv3, TLS 1.0, TLS 1.1 — only allow 1.2 and 1.3
SSLProtocol -all +TLSv1.2 +TLSv1.3
# Strong cipher suite with forward secrecy
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
# Use server's cipher preference
SSLHonorCipherOrder on
# Enable OCSP stapling
SSLUseStapling on
SSLStaplingCache shmcb:/var/run/apache2/stapling_cache(128000)
# HSTS header (force HTTPS)
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Test your TLS configuration with SSL Labs (ssllabs.com/ssltest/). Aim for an A+ rating. The configuration above achieves this. Remember to enable mod_ssl and mod_headers: a2enmod ssl headers && systemctl restart apache2.
Automated scanners probe every Apache server for exposed credentials, version control directories, and admin panels. Block these paths explicitly to reduce your attack surface.
# Block access to hidden files (.env, .git, .htpasswd)
<FilesMatch "^\.">
Require all denied
</FilesMatch>
# Block .git directory
<DirectoryMatch "\.git">
Require all denied
</DirectoryMatch>
# Block WordPress probing on non-WP servers
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/(wp-login|wp-admin|xmlrpc)\.php [NC]
RewriteRule .* - [F,L]
# Block common scanner targets
RewriteCond %{REQUEST_URI} ^/(phpmyadmin|myadmin|pma|dbadmin) [NC]
RewriteRule .* - [F,L]
Important: If you use Let's Encrypt, add an exception for .well-known/acme-challenge before the hidden files block. The [F] flag returns a 403 Forbidden. These rules can go in .htaccess (per-directory) or httpd.conf (server-wide, better performance since Apache doesn't scan for .htaccess on every request).
Apache supports configuration in two places: the main server config (httpd.conf / apache2.conf) and per-directory .htaccess files. Each has trade-offs for security.
| Aspect | httpd.conf | .htaccess |
|---|---|---|
| Performance | Faster (read once at startup) | Slower (scanned on every request) |
| Scope | Server-wide | Per-directory |
| Requires restart | Yes | No (immediate) |
| Access needed | Root / sudo | File owner only |
| Available on shared hosting | Usually not | Yes |
| Can be disabled | No | Yes (AllowOverride None) |
Recommendation: Use httpd.conf for security directives whenever possible. If you are on shared hosting and cannot modify httpd.conf, .htaccess is your only option. On dedicated servers, you can disable .htaccess entirely with AllowOverride None for a small performance gain and tighter control.
Check response headers with curl -I https://your-domain.com. Verify that the Server header does not show a version number, security headers are present, and directory listing is disabled. Use SSL Labs (ssllabs.com/ssltest/) to grade your TLS configuration. For active monitoring, Defensia analyzes your Apache access logs and alerts on attack patterns automatically.
ModSecurity is an open-source Web Application Firewall (WAF) that runs as an Apache module. It inspects HTTP requests inline and can block SQL injection, XSS, path traversal, and other attacks. It requires the OWASP Core Rule Set (CRS) for detection patterns. The main trade-offs are complexity (200+ rule files to configure) and performance overhead (inspects every request).
Use httpd.conf whenever you have server access. It is faster (read once at startup vs. scanned on every request), cannot be accidentally overridden by application code, and supports all directives. Use .htaccess only on shared hosting where you cannot modify the main server configuration.
Yes. Defensia auto-detects Apache access logs (including cPanel domlogs and custom log paths). It reads these logs in real time, detects 15+ OWASP attack types, and blocks offending IPs via iptables. No Apache module installation or configuration changes required.
ModSecurity blocks attacks inline by inspecting each HTTP request, which adds latency and requires rule tuning. Defensia reads Apache access logs asynchronously, detects the same OWASP attack patterns, and blocks offending IPs at the firewall level. The trade-off: ModSecurity can block the very first malicious request; Defensia blocks the IP after the first request is logged. For automated attacks (99% of real-world threats), the difference is negligible.
OWASP attack detection from server logs.
Complete server hardening guide.
Protect cPanel/WHM servers with Defensia.
Hardening guide for nginx servers.
Web Application Firewall explained.
15 detection patterns, ipset blocking.
Defensia reads your Apache logs and blocks attackers automatically. One command. Under 30 seconds.
No credit card required. Free for one server.