IPWhiteList Middleware vs ForwardAuth for Restricting Public Backend Access

When deploying internal services via Traefik Proxy v2.x, preventing accidental public exposure of backend routers is a primary security requirement. While EntryPoints define the listening ports, routers determine which traffic reaches the service based on matching rules.

There is a design trade-off between implementing network-level restrictions and identity-level restrictions to secure these routes:

• IPWhiteList Middleware: Restricts access to specific CIDR ranges, effectively isolating the service to a trusted network.
• ForwardAuth Middleware: Redirects requests to an external authentication service to verify identity before granting access to the backend.

The decision depends on whether the constraint is based on the physical origin of the request or the identity of the user, especially when Traefik is positioned behind an external load balancer that may obscure client source IPs.

Technical Uncertainties

Which approach provides a more resilient safeguard against accidental public exposure when the infrastructure involves multiple layers of proxying? In scenarios where source IP preservation is inconsistent, does ForwardAuth offer a more reliable security boundary than IPWhiteList?