If an app behind Caddy and Authentik trusts the X-Authentik-Username header, then every other container that can reach that app's port can send the header itself and become any user, admin included. It needs no password and no session, and Authentik never sees the request.

This is the most common way people wire up “SSO for apps that don't do SSO”, and it is in a lot of tutorials. I found it on my own server, about 80 containers, in four apps at once. One of them was an admin panel where a forged X-Authentik-Groups: authentik Admins header could approve or delete user sign-ups.

Why SSO doesn't cover it

Forward auth protects the front door. A request comes in to Caddy, Caddy asks Authentik “is this person logged in?”, and if so it copies the username into a header and passes the request to the app. The app trusts that header.

The app's port is a side door, and it is open to:

• every container on the same Docker network, by name (http://myapp:8080);
• every container on the host, if you published the port as 127.0.0.1:8080. Containers reach it through host.docker.internal. Binding to localhost hides the port from your LAN, not from your other containers.

So one compromised image, whether a scraper with an RCE, a typosquatted package or a hijacked upstream, only has to do this:

curl -H 'X-Authentik-Username: admin' \
     -H 'X-Authentik-Groups: admins' \
     http://myapp:8080/admin/

Reproducing it

I built a small compose lab: Caddy, a stand-in for the Authentik outpost, a naive backend that trusts the header, a hardened one, and an “attacker” container that's just another service on the network. From the attacker:

== NAIVE: other container hits backend directly ==
{"user":"admin","groups":"admins"}
== HARDENED: other container hits backend directly ==
{"detail":"forbidden"}

The quirk: forging headers through Caddy

There's a second, subtler hole. forward_auth … copy_headers copies headers from Authentik's response onto the request. What happens when Authentik's response doesn't include one of those headers, but the client sent it? I tested a logged-in, non-admin user adding X-Authentik-Groups: admins to their own request:

If you're on 2.10 or older and your app reads a header that Authentik doesn't always send, a user can grant themselves whatever that header says. Upgrade, and strip client identity headers anyway, since it costs one line.

The fix, in two layers

1. In Caddy: strip client-supplied identity headers before forward auth, and attach a secret that only Caddy knows, one secret per backend:

(authentik_gate) {
	request_header -X-Authentik-*
	request_header -Remote-User
	reverse_proxy /outpost.goauthentik.io/* http://authentik-outpost:9000
	forward_auth http://authentik-outpost:9000 {
		uri /outpost.goauthentik.io/auth/caddy
		copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email
	}
}

myapp.example.com {
	route {
		import authentik_gate
		reverse_proxy myapp:8080 {
			header_up X-Proxy-Secret {env.MYAPP_PROXY_SECRET}
		}
	}
}

2. In the app: reject any request that doesn't carry the secret. Compare in constant time, and refuse to start without a secret:

import hmac
from starlette.middleware.base import BaseHTTPMiddleware
from starlette.responses import JSONResponse

class ProxySecretGuard(BaseHTTPMiddleware):
    def __init__(self, app, secret: str):
        super().__init__(app)
        if not secret or len(secret) < 32:
            raise ValueError("proxy secret missing or too short")
        self._secret = secret.encode()

    async def dispatch(self, request, call_next):
        sent = request.headers.get("X-Proxy-Secret", "").encode()
        if not hmac.compare_digest(sent, self._secret):
            return JSONResponse({"detail": "forbidden"}, status_code=403)
        return await call_next(request)

A tip if you have many backends: Caddy can read a secret from a file with {file./secrets/myapp}. Adding a backend then means dropping in a file and reloading, instead of recreating the Caddy container to add an env var.

Apps whose code you can't change

• The app has a “trusted reverse proxy” setting (Navidrome and many others): give Caddy a fixed IP on the Docker network and trust exactly that one address. Trusting the whole subnet is the hole you're trying to close.
• The app has its own login (the *arr apps, SABnzbd, qBittorrent): turn it on, and don't use “disabled for local addresses”, because every container counts as local. For HTTP Basic, Caddy can inject the credentials after Authentik, so users still see a single login.
• Neither (log viewers, dashboards): move it onto a private Docker network shared only with Caddy, and remove its host port.

Check your own server in one line

From a throwaway container on the same network as each app that reads identity headers:

docker run --rm --network <net> curlimages/curl -s \
  -H 'X-Authentik-Username: admin' http://<app>:<port>/

Anything other than a 401 or 403 means you have a side door.

*Written from a real fix on a production homelab. The lab, the Express version of the middleware, and four other modules for failures that never raise an error (silent backup gaps, Docker Desktop on Windows dying quietly, ports that never bind) are in the Hardened Self-Hosting Kit.*

#selfhosting #security