Apache still runs a large share of public websites because it is flexible, mature, and available on almost every Linux hosting stack. That same popularity makes weak Apache configurations attractive targets. A default install can serve a site, but it should not be treated as production-ready until modules, headers, TLS, permissions, logging, and update practices are checked.
This Apache web server security best practices guide is written for small hosting teams, site owners with a VPS, and agencies that manage client WordPress or PHP sites. It avoids theory where a direct setting is better. The goal is a hardened Apache setup that is boring to operate, easy to audit, and less likely to turn one vulnerable site into a server-wide incident.
Definition: Apache hardening
Apache hardening means reducing the web server’s attack surface and limiting damage if a site, plugin, script, password, or dependency fails. It includes patching, module control, TLS settings, request limits, filesystem permissions, security headers, logging, and isolation between sites.
“A secure Apache build is not one magic directive. It is a stack of small controls that make common attacks harder and recovery faster.”
Start with the operating system and package source
Apache security starts before the first virtual host. Use supported operating system releases and install Apache from trusted package repositories unless you have a clear reason to compile from source. Ubuntu LTS, Debian stable, AlmaLinux, Rocky Linux, and commercial control panel distributions all provide security updates through their package managers.
For most small teams, the best patch benchmark is simple: apply critical Apache, OpenSSL, PHP, and kernel security updates within 7 days, and sooner for actively exploited issues. If you cannot patch quickly, document why and add a temporary control such as firewall rules, WAF rules, or disabling a vulnerable module.
Use staging before production where possible. A basic Apache test can include apachectl configtest, a local curl check, one HTTPS request, and a quick application smoke test. That small routine prevents many avoidable outages.
Disable modules you do not use
Apache’s module system is useful, but every enabled module is another behavior to understand and maintain. Shared hosting stacks often enable more than a single site needs. Review loaded modules and remove anything that is not required by the workload.
- Keep: modules needed for TLS, rewrite rules, compression, HTTP/2 if used, proxying if used, and PHP integration where relevant.
- Review: proxy modules, status pages, directory indexing, CGI, WebDAV, user directories, and autoindex.
- Disable: any legacy or convenience module that no application depends on.
On Debian and Ubuntu systems, a2dismod and a2enmod make this manageable. On RHEL-family systems, module loading is usually controlled through configuration files under Apache’s module configuration directory. After every change, run a config test before restart.
Use tight virtual host boundaries
Virtual hosts should be explicit. Avoid broad defaults that accidentally serve content from the wrong directory. Each site should have a clear ServerName, optional ServerAlias, dedicated document root, separate logs, and a matching HTTPS virtual host.
For multi-site servers, avoid placing unrelated client sites under the same writable ownership model. One compromised WordPress plugin should not be able to edit another client’s files. When possible, pair Apache with PHP-FPM pools that run under different Unix users. That single design choice limits cross-site damage.
Filesystem permissions that hold up
Permissions should let Apache read what it must serve and write only where the application truly needs writes. A practical baseline is directories at 750 or 755, files at 640 or 644, and writable upload or cache directories handled separately. Avoid 777. It is a shortcut that turns a small mistake into a broad write problem.
For WordPress, the web server usually needs write access to uploads and sometimes cache directories. It should not need write access to every PHP file during normal operation. Updates can be handled through controlled maintenance windows or deployment tooling instead of permanent wide-open permissions.
TLS and HTTPS settings
Use HTTPS everywhere. Let’s Encrypt certificates are free, and paid certificates are rarely needed for ordinary websites. The security work is in renewal automation and protocol settings, not in buying the most expensive certificate.
A reasonable 2026 TLS baseline is TLS 1.2 and TLS 1.3 enabled, older protocols disabled, automatic renewal tested, and HTTP redirected to HTTPS. Use an SSL Labs grade of A or A+ as a practical external check. For sites with logins, payments, or admin dashboards, add HSTS after verifying every subdomain is ready for HTTPS.
Security headers worth setting
Headers do not fix vulnerable code, but they reduce browser-side risk. Start with a small set that rarely breaks normal sites, then add stricter controls where the application supports them.
| Header | Purpose | Practical starting value |
|---|---|---|
| Strict-Transport-Security | Forces HTTPS after first visit | max-age=31536000 after testing |
| X-Content-Type-Options | Stops MIME sniffing | nosniff |
| Referrer-Policy | Controls referrer sharing | strict-origin-when-cross-origin |
| Content-Security-Policy | Limits script and asset sources | Start in report-only mode |
| Permissions-Policy | Limits browser features | Disable unused features |
Content Security Policy is powerful but can break sites that rely on third-party scripts, analytics, ad tags, and inline JavaScript. Use report-only mode first, review violations, then enforce once the rule is stable.
Hide server details, but do not rely on hiding
Set Apache to reveal less version information with directives such as ServerTokens Prod and ServerSignature Off. This keeps error pages and headers from advertising exact versions. It is useful hygiene, not a real defense. Attackers can still test behavior directly, so patching and access control matter far more.
Request limits and abuse controls
Small sites often fail under boring abuse: oversized requests, repeated login attempts, bad bots, or slow clients. Apache can set limits that reduce this pressure before the application has to respond.
- Limit request body size for endpoints that do not need large uploads.
- Set timeouts so slow clients cannot hold connections forever.
- Use rate controls through a WAF, reverse proxy, CDN, or modules such as mod_evasive where appropriate.
- Protect admin paths with IP allowlists, VPN access, extra authentication, or stricter WAF rules.
Cloudflare’s free plan, a paid CDN plan, or a host-provided WAF can absorb common bot noise. ModSecurity with the OWASP Core Rule Set can also help, but it needs monitoring because false positives can block real users.
Directory listing, uploads, and script execution
Turn off directory listing unless a site needs it. Public file indexes often reveal backups, old assets, exports, or plugin directories. Also prevent script execution in upload directories. A common attack path is uploading a PHP file through a weak form and then executing it from the uploads path.
For applications that allow user uploads, treat uploads as untrusted content. Store them outside the executable code path when possible, validate file types, rename files on upload, and serve them with safe content headers.
Logs and monitoring
Apache access and error logs are not just for debugging. They are security evidence. Keep separate logs per site, rotate them, and retain enough history to investigate incidents. Thirty days is a practical minimum for small sites, while businesses with compliance needs may keep much longer retention.
Watch for repeated 404s against admin paths, spikes in POST requests, unusual user agents, authentication failures, and outbound traffic changes. Tools such as GoAccess, fail2ban, hosting control panel alerts, and SIEM integrations can all help depending on the budget.
Backups and restore tests
Security planning is incomplete without recovery. Keep automated backups of site files, databases, Apache configuration, TLS renewal settings, and deployment scripts. Store at least one copy away from the web server account. A backup that a compromised web user can delete is weaker than it looks.
Run a restore test at least quarterly for business sites. The test does not need to be elaborate. Restoring to a staging domain and confirming the homepage, login, and one form can reveal missing database dumps, broken permissions, and incomplete configuration backups.
Apache hardening checklist
- Run a supported operating system and trusted Apache package source.
- Patch critical Apache, OpenSSL, PHP, and kernel issues within 7 days.
- Disable unused Apache modules.
- Use explicit virtual hosts with separate logs and document roots.
- Keep files and directories under least-privilege permissions.
- Use HTTPS with TLS 1.2 and TLS 1.3, plus tested renewal automation.
- Add practical security headers and test CSP before enforcement.
- Turn off directory indexes and block script execution in upload paths.
- Apply request limits, bot controls, and admin-path protection.
- Retain logs and test restores on a schedule.
Q&A
Is Apache less secure than Nginx?
No. Apache and Nginx can both be operated securely or poorly. Apache’s risk usually comes from old modules, loose per-directory overrides, weak PHP handling, and poor permissions rather than the server name itself.
Should I use .htaccess files?
Use them only when you need per-directory configuration, such as on shared hosting where you cannot edit the main virtual host. On a VPS, main Apache config is usually faster, clearer, and easier to audit.
Is ModSecurity required?
It is not required for every site, but it is useful for public WordPress, PHP, ecommerce, and form-heavy sites. Start with monitored rules, review false positives, and tune before relying on it for blocking.
What is the fastest Apache security win?
Patch the system, disable directory listing, use HTTPS, remove unused modules, and fix write permissions. Those five changes reduce many common risks quickly.
How often should I audit Apache settings?
Review settings after major application changes and at least quarterly for business sites. Also audit after server migrations, control panel updates, new plugins, or security incidents.
Final recommendation
Apache security works best when it becomes routine. Keep the server patched, run only the modules you need, isolate sites, protect TLS, set sane request limits, and test backups. None of these steps is exotic, but together they create a web server that is much harder to misuse and much easier to recover.