Introduction
This isn’t a comprehensive guide to hardening Apache—plenty of folks more qualified have tackled that. Instead, this is a personal overview of what I did, and why.
The "Server in the Cellar" is a standalone machine dedicated to web hosting. Since 2003, it's been humming along with nothing but server software and site files. It doesn’t even know about my other machines. From day one, the logs have shown bot attempts—trying to break out of directories, probing for CGI scripts, and so on. While I doubt I could fend off a determined attacker, disrupting this little machine would be a mean-spirited act.
Hardening Apache not only protects the site but also its visitors.
Apache's default security has served me well for years. I only set up SSL certificates and HTTPS in October 2022, which kicked off my interest in taking security a little further.
A couple of great resources that helped:
Site Testing
Server – Running my own Apache server means I’ve had to learn to test and tune it. A few of the better tools I've used:
These tools showed improvements as I hardened the setup. A quick timeline:
- Mozilla Observatory: F (Oct 23) → B- (Nov 20) → B (Nov 26)
- Pentest-Tools: Risk score dropped from High to Low
- Detectify: 19 vulnerabilities (score 5.8) → 7 vulnerabilities (score 4.8)
It's unlikely my server has ever faced a serious attack—it’s just not that important—but these tests have been a solid learning experience.
SSL Certificates – I use Let's Encrypt with an ACME client. Testing tools include:
Server and Site Information
Revealing too much server info is a known risk. Early on, I made mod_status publicly available, which reveals things like server uptime, version, and active threads. That’s handy for me, but not ideal from a security standpoint.
Apache directory listings can be considered a vulnerability. I’ve allowed them in a few folders—mostly for convenience. That decision comes down to balancing transparency and risk.
Common Vulnerabilities
After reading the Geekflare guide and Apache’s own tips, I ran more scans. Here’s the shortlist of headers and policies I looked at:
- Content Security Policy (CSP)
- Cookies
- Cross-Site Scripting (XSS)
- Cross-Site Tracing (XST)
- Mixed Content
- Permissions Policy
- Referrer Policy
- Security.txt
- Strict Transport Security (HSTS)
- X-Content Type Options
- X-Frame Options
Content Security Policy (CSP) {#csp}
CSP helps mitigate XSS and data injection attacks.
To enable CSP in Apache, make sure mod_headers is active:
``
#LoadModule headers_module modules/mod_headers.so
`
Uncomment that line in httpd.conf or add it if missing.
In httpd-vhosts.conf (HTTPS sections only), I added:
`
Header set Content-Security-Policy "frame-ancestors 'self'; upgrade-insecure-requests; report-uri /cgi-bin/csp-error.pl"
`
Helpful tools:
[LIST]
[*][URL=https://csp-evaluator.withgoogle.com/]CSP Evaluator[/URL]
[*][URL=https://securityheaders.com/]Security Headers[/URL]
[/LIST]
[HEADING=2]Cookies {#cookies}[/HEADING]
I don’t use cookies directly, but third-party services like Google Analytics and YouTube do. Browser dev tools now warn if cookies lack the SameSite attribute. These warnings are often outside your control unless you're managing the cookie directly.
[HEADING=2]Cross-Site Scripting (XSS) {#xss}[/HEADING]
Mitigation:
[LIST]
[*]Sanitize input
[*]Use a solid CSP
[*]Monitor logs
[/LIST]
The X-XSS-Protection header is now deprecated and not recommended.
[HEADING=2]Cross-Site Tracing (XST) and Trace Requests {#xst}[/HEADING]
TRACE is largely considered safe to ignore nowadays. Apache still supports it by spec, and modern browsers don’t use it. I’ve left it enabled.
[HEADING=2]Mixed Content (HTTPS vs HTTP) {#mix}[/HEADING]
After enabling HTTPS, some old pages had HTTP links. Browsers often auto-upgrade them, but not always. Tools that helped me:
[LIST]
[*][URL=https://www.jitbit.com/sslcheck/]JitBit SSL Check[/URL]
[*][URL=https://www.missingpadlock.com/]Missing Padlock[/URL]
[/LIST]
[HEADING=2]Permissions Policy {#permissions}[/HEADING]
Controls what browser features can run. Helpful in case of an XSS vulnerability—can prevent attackers from leveraging unused browser APIs.
Docs:
[LIST]
[*][URL=https://developer.chrome.com/en/docs/privacy-sandbox/permissions-policy/]Chrome Developers[/URL]
[*][URL=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy]MDN[/URL]
[/LIST]
[HEADING=2]Referrer Policy {#referrer}[/HEADING]
Controls how much info is sent when navigating to another site. In httpd.conf I added:
`
Header always set Referrer-Policy "strict-origin-when-cross-origin"
`
Also: always use rel="noopener noreferrer" with target="_blank".
[HEADING=2]Security.txt File {#sectxt}[/HEADING]
This file allows security researchers to contact you. I’ve skipped it since I already get too many emails, and no one has ever sent a security issue.
[HEADING=2]Strict Transport Security (HSTS) {#hsts}[/HEADING]
For HTTPS connections only, in httpd-vhosts.conf:
`
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
`
[HEADING=2]X-Content Type Options {#xcto}[/HEADING]
Prevents MIME type sniffing. In httpd.conf:
`
Header set X-Content-Type-Options "nosniff"
`
[HEADING=2]X-Frame Options - Iframes and Clickjacking {#xfo}[/HEADING]
To prevent clickjacking while still allowing self-hosted iframes:
`
Header always set X-Frame-Options "sameorigin"
Header set Content-Security-Policy "frame-ancestors 'self'"
`
[HEADING=2]My Security Headers and Policies[/HEADING]
[B]httpd.conf[/B]:
`
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "sameorigin"
`
[B]httpd-vhosts.conf (HTTPS sections only)[/B]:
`
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header set Content-Security-Policy "frame-ancestors 'self'; upgrade-insecure-requests; report-uri /cgi-bin/csp-error.pl"
``