Web Server and Reverse-Proxy Security — DedSec Project

Web-server security covers the software and infrastructure that accepts HTTP(S) traffic before or alongside the application: TLS termination, virtual hosts, reverse proxies, static files, process identity, modules, file permissions, logging, and administrative interfaces.

Authorized-use boundary: Test web servers only in scope. Use localhost or an intentionally vulnerable training environment for configuration experiments. Do not brute-force directories or stress public servers.

Learning objectives

• map client, CDN/proxy, web server, application, and backend boundaries;
• review TLS, virtual hosts, methods, headers, and file exposure;
• understand process privilege and filesystem permissions;
• identify dangerous default/demo/admin content;
• review reverse-proxy trust headers;
• collect server-side evidence for findings.

Architecture first

A request may pass through CDN, load balancer, WAF, reverse proxy, web server, application framework, and backend services. Record where TLS terminates, which component authenticates the client, which component decides the original client IP/scheme/host, and which logs contain the request.

TLS and transport

Use HTTPS for sensitive applications and manage certificates, protocol versions, redirect behavior, HSTS policy where appropriate, and private-key access. A valid certificate proves control of a name/key relationship under the certificate ecosystem; it does not prove the application is secure.

Virtual hosts and Host handling

One server can host several applications. Validate which hostnames are expected and what happens to unknown Host values. Reverse proxies and applications should agree on the trusted host/origin context so generated links, redirects, cache keys, and security decisions are not based on untrusted values.

HTTP methods

Enable only methods required by the application. The presence of a method is not automatically a vulnerability; evaluate what action it permits, authentication requirements, and authorization checks.

Static files and document roots

Review document-root boundaries, symlink behavior, directory listings, backup files, editor artifacts, source maps, environment files, and configuration files. Sensitive files should live outside publicly served directories and be protected by OS permissions as well as web configuration.

Process identity

The web server and application should run with only the privileges they require. Writable directories should be narrowly scoped. Avoid running a normal web application as root/administrator.

Reverse-proxy headers

Headers such as X-Forwarded-For, Forwarded, and scheme/host forwarding can be useful only when the application knows which proxy is trusted to set or overwrite them. Never trust client-supplied forwarding headers by default for security decisions.

Administrative interfaces

Management consoles, status pages, metrics, debug endpoints, and health endpoints need explicit exposure decisions. Prefer dedicated management networks or authenticated access rather than relying on obscure paths.

Logging

Record request time, normalized host, method, path, response status, latency, correlation ID, and authenticated identity where appropriate. Avoid logging passwords, authorization headers, session cookies, or sensitive request bodies.

Safe configuration review

For a local Nginx/Apache/Caddy test instance, verify:

• bind addresses;
• document root;
• process identity;
• enabled modules/features;
• TLS configuration if used;
• default virtual host behavior;
• directory listing;
• admin/status endpoints;
• access/error logging;
• reverse-proxy trust settings.

Common mistakes

• Assuming the application sees the original client connection directly.
• Trusting forwarding headers from arbitrary clients.
• Leaving sample or backup files under the document root.
• Running the web process with excessive privilege.
• Logging secrets.
• Treating a server banner as proof of patch state.

Safe lab

Run a local web server bound to 127.0.0.1. Create one public file and one file that should remain outside the document root. Verify only the public file is reachable. Then change one harmless configuration value, reload, and correlate access/error logs with the request.

Knowledge check

1. Why can proxy headers become a trust-boundary issue?
2. Why is server version disclosure not enough to confirm a vulnerability?
3. Which files should never depend only on web-server deny rules?
4. Why should management endpoints be separated from public traffic?
5. What request data should generally not be logged?

Guided study workflow

Use the shared Study Method. Draw the full request path before evaluating any server setting.

Continue with

Recommended next modules: 14, 19, 40, 52, 69.