TRUSTED_PROXIES ships empty/disabled by default — full admin-impersonation risk if not explicitly configured #94

Open
opened 2026-09-01 00:13:36 -04:00 by jared · 0 comments
Owner

Severity: High (secure-by-configuration, insecure-by-default)

middleware/AuthMiddleware.php::enforceTrustedProxy() (~lines 152-170) correctly rejects (403) any request whose REMOTE_ADDR isn't in the TRUSTED_PROXIES allowlist — when that variable is set. But .env.example (~line 46) ships TRUSTED_PROXIES= (empty), and the code's own comment confirms "Empty = enforcement OFF."

Impact: A fresh deployment that doesn't explicitly set TRUSTED_PROXIES has NO verification that Remote-User/Remote-Name/Remote-Email/Remote-Groups headers actually came from the trusted Authelia reverse proxy. Anyone who can reach the app directly — a misconfigured firewall rule, a container network accidentally exposing the PHP-FPM/webserver port, or SSRF from another internal service — can set Remote-User: admin / Remote-Groups: admin,employee themselves and fully impersonate any user, including an admin, with zero authentication. This isn't a code defect (the enforcement logic itself is correct and fails closed once configured) — it's a dangerous default that's easy to silently skip during setup.

Fix: At minimum, make this far more prominent in .env.example and the README's setup instructions (a loud warning, not just an inline comment) as a REQUIRED production setting. Better: have the app refuse to start (or log a persistent startup warning) if TRUSTED_PROXIES is empty and APP_ENV/equivalent indicates production, so this can't be silently forgotten.

**Severity:** High (secure-by-configuration, insecure-by-default) `middleware/AuthMiddleware.php::enforceTrustedProxy()` (~lines 152-170) correctly rejects (403) any request whose `REMOTE_ADDR` isn't in the `TRUSTED_PROXIES` allowlist — **when that variable is set**. But `.env.example` (~line 46) ships `TRUSTED_PROXIES=` (empty), and the code's own comment confirms "Empty = enforcement OFF." **Impact:** A fresh deployment that doesn't explicitly set `TRUSTED_PROXIES` has NO verification that `Remote-User`/`Remote-Name`/`Remote-Email`/`Remote-Groups` headers actually came from the trusted Authelia reverse proxy. Anyone who can reach the app directly — a misconfigured firewall rule, a container network accidentally exposing the PHP-FPM/webserver port, or SSRF from another internal service — can set `Remote-User: admin` / `Remote-Groups: admin,employee` themselves and fully impersonate any user, including an admin, with zero authentication. This isn't a code defect (the enforcement logic itself is correct and fails closed once configured) — it's a dangerous default that's easy to silently skip during setup. **Fix:** At minimum, make this far more prominent in `.env.example` and the README's setup instructions (a loud warning, not just an inline comment) as a REQUIRED production setting. Better: have the app refuse to start (or log a persistent startup warning) if `TRUSTED_PROXIES` is empty and `APP_ENV`/equivalent indicates production, so this can't be silently forgotten.
jared added the configpriority/highsecurity labels 2026-09-08 10:15:49 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: LotusGuild/tinker_tickets#94