TLS, WAF, and Backend: A Layered Architecture

TL;DR

A robust security layered architecture distributes protection tasks across different levels: TLS secures the transport connection, the WAF evaluates HTTP requests, and the backend remains responsible for authorization, validation, and data protection. The critical points are the handover points between these layers. Each decryption, forwarding, and protocol conversion creates its own trust and operational requirements.

Introduction

TLS, WAF, and backend are often treated as a cohesive protection mechanism in practice. This leads to a problematic assumption: if TLS is active and a WAF is in place, the application is automatically sufficiently secured. In reality, the three components fulfill different tasks and each sees only part of the traffic. TLS primarily protects the transport path, the WAF analyzes application requests, and the backend must secure business logic, identities, and data itself. A security layered architecture is therefore mainly a question of clearly defined responsibilities, handover points, and remaining risks.

1. TLS Termination Defines the First Trust Boundary

TLS protects the confidentiality and integrity of a connection between a client and a TLS endpoint. With TLS termination at the edge, this connection does not end at the backend but at the edge platform. There, the encrypted HTTP traffic is decrypted and can be evaluated for downstream security functions.

This architecture is technically necessary if a WAF is to examine HTTP methods, headers, cookies, or request bodies. A WAF cannot meaningfully evaluate encrypted content without decryption. At the same time, a new trust boundary is created at the edge: the decrypted traffic is available in plaintext and must be processed and forwarded accordingly within the platform.

For the backend, this results in a clear duty to verify. Securing the client-to-edge connection says nothing about the connection from the edge to the backend. This path requires its own transport and trust decision. TLS termination does not automatically reduce every backend risk; it shifts part of the security responsibility to a defined handover point.

2. The WAF Operates at the Application Layer

A WAF protects HTTP and HTTPS services by evaluating requests based on application layer properties. These include methods, paths, headers, parameters, or typical attack patterns. Its strength lies where network and transport protection are insufficient: with exploitable requests, unexpected inputs, and known attack patterns against web applications.

However, the WAF is not a substitute for TLS and not a complete protection of the backend. It can only examine data that it actually reaches and can interpret. Protocol deviations, unclear header forwarding, or faulty TLS configurations can therefore affect the analysis. Likewise, technical errors remain possible if a request appears technically correct but violates business logic.

In the ayedo Edge Cloud, the WAF is positioned in front of the actual backends and can be connected with TLS termination at the edge. This creates a central checkpoint before the compute infrastructure. Nevertheless, the application remains responsible for authentication, authorization, input validation, and secure processing.

3. Backend Security Begins Behind the WAF

The backend must not be viewed as a passive recipient of already verified requests. It must validate its own security assumptions: identities and permissions need to be checked, inputs must be contextually validated, and sensitive operations require server-side controls. A WAF can recognize attack indicators but cannot replace business authorization.

Particularly relevant is the question of which headers and source information are passed to the backend. If client IP, host, or protocol information is used for logging, rate limits, or security decisions, their origin must be clear. The Proxy Protocol mechanism can structurally transfer such connection information to downstream systems. However, the backend must correctly support this protocol and not treat unvalidated headers as trustworthy.

Additionally, the backend should not be directly publicly accessible if all external traffic is to be routed through the edge. Backend cloaking reduces this attack surface by ensuring internal targets do not serve as a public entry point. Health checks and failover assist in operations but do not replace access controls or securing the backend connection.

4. Handover Points Determine Remaining Risks

Each layer can only evaluate its own view of the traffic. Between the client, edge, and backend, handover points arise where protocols are terminated, information is added, or security decisions are passed on. It is precisely here that hard-to-detect misconfigurations often occur.

A typical example is the different interpretation of URL paths or headers at the edge, WAF, and application. If the WAF normalizes a request differently than the backend, a request may appear inconspicuous at the protection layer but have a different meaning in the backend. Similar risks arise from inconsistent TLS, host, or proxy protocol assumptions.

A robust security layered architecture therefore documents for each path: Who terminates TLS? Which instance sees the plaintext? What information is passed on? Which source is considered trustworthy? And what verification occurs only in the backend? In the ayedo Edge Cloud, public routing, protection, and forwarding functions can be centrally bundled before workloads. However, the specific security quality depends on the consistent configuration of all involved layers.

Practical and Operational Scenario

A company operates an API on its own Kubernetes cluster with a cloud provider. The public DNS entry points to the ayedo Edge Cloud. There, TLS ends, the WAF checks the HTTP requests, and the traffic is then forwarded to the backend. The backend is not directly publicly exposed and only accepts the intended forwarding path.

For operations, several points must now be monitored separately: certificate status and TLS errors at the edge, blocked or suspicious requests in the WAF, and authentication and authorization errors in the API. If a backend fails, health checks can influence the forwarding. However, they do not indicate whether the application is functioning correctly or securely. Only separate consideration makes the cause of an error visible.

FAQ

Does TLS Termination Also Protect the Connection to the Backend?

No. TLS termination protects the connection to the TLS endpoint at the edge. The path between the edge and the backend must be evaluated separately and secured according to the application’s protection requirements.

Does a WAF Replace Validation in the Backend?

No. A WAF recognizes certain HTTP-based attack patterns. Business authorization, input validation, business logic, and the protection of sensitive data remain the application’s responsibilities.

Why Are Handover Points Security-Relevant?

At handover points, connections are terminated, information is passed on, or protocols are interpreted. Divergent assumptions between edge, WAF, and backend can render protection mechanisms ineffective.

Conclusion

A security layered architecture is not a single product feature but a clear distribution of security tasks. TLS protects the transport up to the defined termination, the WAF evaluates HTTP requests, and the backend bears responsibility for identity, business logic, and data. The ayedo Edge Cloud can centrally bundle these upstream functions and connect backends independently of providers. It remains crucial to explicitly design the handover points and assign each remaining risk to a specific layer.