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 one layer,layer andin treatingthe itDefense-in-Depth asmodel, morecoverning thanthe thatnetwork is how people get hurt.layer.

• 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 depthDefense-in-Depth means the WAF sits alongside authentication, internal certificate-based trust, network segmentation, and timely updates, not instead of any of them. An application behind a WAF still needs to be secure onin its own terms.right.
• A single edge is a single point of failure. ThisIn is the sharpest tradeoff, and it deserves a clear statement: in thismy environment there is exactlyonly one WAF host, and if it is down, every public service is unreachable. For a householdsmall ecosystem serving a handfulsmall number of people, that is an acceptable availability tradeoff, made deliberately. 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 theone front doorhost 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 sharpens it: the WAF is the most valuable single control at the edge, precisely 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 meets the mutual-TLS 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.