Web servers compared: Nginx, Apache, Caddy and LiteSpeed on security

The web server is the first program on your machine that strangers talk to. Every request from the internet lands there before it reaches WordPress, your shop or your API. That makes the choice of server, and above all its configuration, a security decision. This comparison looks at Nginx, Apache HTTP Server, Caddy and the two LiteSpeed editions through that lens, not through benchmark charts.

What we compare

Raw speed matters less than you might think, because most small sites never get near the limits of any of these servers. Real risk depends on how safe the server is straight after installation, how easy it is to make a dangerous mistake, how much code is exposed and how quickly security fixes reach your machine. We scored six criteria:

• Secure defaults: what the server reveals and allows before you change anything.
• Automatic HTTPS: whether certificates are obtained and renewed without extra tools.
• Low configuration risk: how hard it is to open a hole by accident.
• Small attack surface: how much optional code is loaded and reachable.
• Patch delivery: how fixes reach you, through your distribution or a vendor repository.
• Resilience under load: how well the server copes with floods of slow or idle connections.

Nginx: lean, fast and strict about details

Nginx is event-driven: a few worker processes each handle thousands of connections, which makes it hard to exhaust with idle or slow clients. Its defaults are sensible. Directory listings stay off unless you enable autoindex, and the current documentation lists TLS 1.2 and TLS 1.3 as the default protocols. There is no per-directory override file, so only someone with access to the main configuration can change behaviour.

The weak spots are in the details. By default Nginx shows its version number in the Server header and on error pages. An alias inside a location whose path lacks the trailing slash can let a request step one directory up, and add_header lines in a nested block silently replace those set higher up. HTTPS needs an extra step: an ACME client such as Certbot, or the official ACME module that Nginx now publishes as a separate dynamic module.

# Hide the version number in headers and error pages
server_tokens off;

# Refuse request bodies larger than you need (default 1m)
client_max_body_size 10m;

# Give slow clients less time to hold a connection open
client_header_timeout 10s;
client_body_timeout 10s;

In each server block, also deny requests for paths that start with a dot, so files such as .git or .env can never be served, with an exception for /.well-known/ if you use ACME. Run nginx -t after every change and reload only when it reports success. A typo then costs nothing, because the running server keeps its old configuration.

Apache HTTP Server: flexible, with more to switch off

Apache is the most configurable of the four, with a long list of modules and several processing models called MPMs. The event MPM handles many connections well. The older prefork MPM, still common with mod_php, ties one process to each connection and is easier to tie up with slow clients. Keep mod_reqtimeout loaded, because it limits how long a client may take to send a request.

Out of the box Apache says more than it needs to: ServerTokens defaults to Full, which includes the version and operating system, and TraceEnable is on. The Apache documentation is frank that hiding the version does not make a server secure. It does remove a free hint for automated scanners, so it is worth the two lines.

# Send only "Apache" in the Server header, no version or OS
ServerTokens Prod
ServerSignature Off

# Answer TRACE requests with 405
TraceEnable Off

<Directory /var/www/>
    Options -Indexes
    AllowOverride None
</Directory>

Debian and Ubuntu already ship this file with more talkative values. Change the existing lines rather than adding a second file, because for these directives the last value read wins. On Rocky Linux and AlmaLinux a new file under /etc/httpd/conf.d/ works. Test with apachectl configtest before you reload.

The feature that made Apache popular with shared hosting is also its biggest risk: .htaccess files. They let anyone who can write to a web directory change rewrite rules, access control and sometimes handlers, without touching the main configuration. That is convenient for a CMS that writes its own rules, but it also means a compromised plugin can reconfigure the server for its directory. The default for AllowOverride is None. Keep it there unless an application needs overrides, and then allow only the categories it uses, such as FileInfo.

Caddy: HTTPS by default, fewer knobs

Caddy's headline feature is automatic HTTPS. As soon as a site block names a domain, Caddy obtains a certificate through ACME (from Let's Encrypt, with ZeroSSL as a fallback), renews it and redirects plain HTTP to HTTPS without a single extra line. That removes the most common HTTPS failure in small setups: a certificate that quietly expires because a renewal job stopped working.

Caddy is written in Go, a memory-safe language, which rules out whole classes of bugs such as buffer overflows that have hit servers written in C. Its Caddyfile format is short, so there is less room for mistakes. The trade-offs: plugins are compiled into the binary, so adding one means a custom build, and distribution packages can trail the upstream release, which is why many admins use the project's own package repository. Protect Caddy's data directory like any private key store, because it holds your certificates and keys.

LiteSpeed: two editions with different rules

LiteSpeed Enterprise is a commercial, closed-source replacement for Apache. It reads Apache configuration and most .htaccess directives, which is why many hosting control panels offer it. OpenLiteSpeed is the open-source edition. According to its documentation it supports .htaccess only for rewrite rules, not for other directives, and rule changes take effect after a restart.

Both editions are event-driven and offer per-client connection throttling, which helps under floods. OpenLiteSpeed is managed through a web admin console on its own port; restrict that port to your own addresses or a VPN. Neither edition comes from the standard Debian, Ubuntu or RHEL repositories, so updates arrive through the vendor's repository, and that repository must be part of your update routine.

Track record and patching

All four servers have had serious vulnerabilities, and all four projects fix them. A count of past advisories says little on its own, because widely used software attracts more scrutiny. What matters is how quickly a fix reaches your machine. A well-known case is Apache 2.4.49, released in 2021 with a path traversal flaw that was already being exploited when the fix appeared. The first fix was incomplete and a second release followed within days.

Nginx and Apache are in the official repositories of every major distribution and receive backported security fixes for the life of the release. Caddy is packaged by some distributions, often in an older version. LiteSpeed comes only from the vendor. Whatever you run, make sure its source is covered by automatic or scheduled updates.

The server you patch on time beats the server with the better benchmark.

General information, checked on 31 October 2026. Test changes on one system first and keep a way back. Found something outdated? Tell the editors.