Concepts

The single front door to a self-hosted environment: what it inspects, what it terminates, and what it refuses to pass.

This book is a working reference for putting a web application firewall (WAF) in front of every public-facing service in a self-hosted environment. It opens with the case for a single inspecting edge, then walks through standing up the reverse proxy, adding application-layer inspection with open-appsec, authenticating inward to the backends, and operating the whole thing day to day. The specific stack is nginx with open-appsec, but the pattern, one hardened front door that every request must cross, applies regardless of the tools.

Why a single inspecting edge

A reverse proxy solves routing. It takes a request for app.example.org and forwards it to the right backend. That alone is worth doing, because it means backends never face the internet directly. But routing is not inspection. A plain proxy forwards a malicious request just as faithfully as a legitimate one. It looks at where a request is going, not at what the request contains.

A WAF adds the missing half. It sits at the same place the proxy does, the one point every inbound request must cross, and it examines the content of each request against the shape of known attacks; injection attempts, cross-site scripting, path traversal, malformed methods, etc. The whole catalog of things that target the application layer rather than the network. Requests that match potential malicous activity patterns are refused before they ever reach a backend. The edge stops being a pass-through and becomes a filter.

Three distinct jobs happen at this one host, and it is worth keeping them separate in your head because the rest of the book configures them one at a time:

• Reverse proxy. Route each hostname to its backend. Nothing public-facing exists anywhere else.
• TLS termination. Public certificates live here and here only. This is where encryption to the browser begins and ends; what happens inward is separate.
• Application-layer inspection. Examine every request and refuse the malicious ones. This is the true WAF functionality.

Why this matters more at small scale

One person may struggle to harden every application individually. Each app has its own request handling, its own vulnerabilities, its own patch cadence, and keeping all of them individually defended against web attacks is not realistic for a solo operator. A single inspecting edge changes the equation. Harden one front door well, and every service behind it inherits that protection. Not that you shouldn't harden your applications and services, and the hosts running them. A WAF is another security layer that aligns with the Defense-in-Depth model.

The WAF enables consistent enforcement across all applications and services; one place to update rules, one place to review what is being blocked, one place that sees every request and can make decisions about it.

The honest limits

A WAF is only one layer in the Defense-in-Depth model, and may represent a false sense of security if it is your only means of protection.

• It reduces exposure; it does not eliminate it. A WAF blocks known attack patterns and anomalous requests. It is not a guarantee that nothing malicious gets through, and a novel or carefully crafted attack can evade it. It buys you a great deal, but it is not a reason to stop patching or to relax authentication.
• It is not a substitute for the other layers. Defense-in-Depth means the WAF sits alongside host, application, and data layer protections. One still needs other technical, operational, and administrative controls to further secure the environment.
• A single edge is a single point of failure. In my environment there is only one WAF host, and if it is down, every public service is unreachable. For a small ecosystem serving a small number of people, that is an acceptable availability tradeoff.. In any larger or genuinely critical environment it would not be. A production deployment would run the WAF as a high-availability pair behind a load balancer, so that one host failing does not take the whole environment offline, and so that the edge itself can be patched and updated without downtime. The single-host model in this book is right-sized for a small ecosystem and explicitly wrong for a large one.

None of this undermines the case for a WAF; it reinforces it. The WAF a valuable single control at the edge, because it is the one point everything crosses, and that same property is why it must not be the only control and why, at scale, it must not be a single host.

What the following pages cover

• Why this design: a single edge host running open-appsec on nginx, and the tradeoffs of that choice.
• How it fits the architecture: where the edge sits, what terminates here, and where internal trust takes over.
• Standing up the edge: the reverse proxy, public TLS, and the per-site pattern every new service follows.
• Adding inspection: installing open-appsec and the learn, then prevent lifecycle that keeps it from blocking legitimate traffic.
• The internal handoff: authenticating from the WAF to each backend, where this book intersects with the mTLS book.
• Operating it: logs, alerts, and telling a real attack from a false positive.
• What I'd tell someone starting out: the lessons, including the ones about running a single edge.