CSRF origin mismatch on every Save (regression in v0.8.5.1)

[kadeschs]

Description
Sortarr was working normally for me until today. When I opened the UI, I was redirected to the Setup page and cannot get past it. Every attempt to save the Setup form fails with: {"error":"CSRF origin mismatch."}. This happens even when all required fields are filled (Basic Auth, session secret key, proxy mode, Sonarr/Radarr URLs, etc.). I cannot complete Setup and cannot access the app.

Steps to Reproduce
Start Sortarr v0.8.5.1 (fresh container or existing one that forces Setup)
Open the UI (reverse proxy URL or direct NAS IP)
Fill out:
Basic Auth username/password
Generate permanent session secret key
Proxy mode (Single proxy or Direct)
Sonarr/Radarr URLs + API keys
Click Save and continue
Sortarr responds with: {"error":"CSRF origin mismatch."}
Setup never completes.

Expected Behavior
Setup should save successfully and allow access to the main Sortarr UI.

Actual Behavior
Setup always fails with a CSRF error.
The app remains stuck on the Setup screen and cannot be used.

Environment
Sortarr version: v0.8.5.1
Deployment: Docker on Synology NAS
Access method: Reverse proxy (HTTPS) and direct NAS IP (HTTP)
Browser: Chrome + Firefox (same result)
Fresh container restart does not resolve it
Clearing cookies/cache does not resolve it
Happens even with:
Direct IP access
Proxy mode set to Direct
Fresh session secret
Fresh Basic Auth credentials

Additional Notes
This setup worked previously; the issue began suddenly today.
The error occurs before any connection tests run, so the failure is happening in the CSRF middleware during Setup.
It seems the CSRF cookie is not being set or accepted during the Setup flow, causing every POST to /setup to fail.

Request
Can you confirm whether this is a known regression in the v0.8.4+ CSRF/session rewrite?
And is there a recommended workaround (e.g., disabling secure cookies, forcing HTTP-only mode, or bypassing Setup)?

[Jaredharper1]

Thank you so much for the detailed bug report!

0.8.6 is now released, and it should fix this regression from 0.8.5.1.

The root cause turned out to be in the server/proxy handling layer: trusted X-Forwarded-* headers were not surviving the Waitress path correctly in affected proxied HTTPS setups, which caused CSRF origin mismatch on every Save.

0.8.6 includes the fix for that path. Please retest on 0.8.6 and let me know if Save now works normally.

If it still fails, please reply with:

• your proxy topology
• /api/diagnostics/csrf
• /api/diagnostics/security-self-check
• the latest CSRF request rejected ... log line

[kadeschs]

The CSRF failures seem to be happening during the initial setup flow when Sortarr is behind Synology DSM’s reverse proxy. DSM may be stripping all forwarded headers and rewriting the request as plain HTTP, which caused Sortarr to see scheme=http, is_secure=false, and all X‑Forwarded-* headers empty.

Sortarr reported host_url = http://sortarr.xxx.xxx.xxx/, which is not a valid URL in my deployment (Sortarr only listens on http://:8787). I assumed this happened because DSM forwarded the setup POST to the container as plain HTTP with no forwarded headers, so Sortarr had no way to reconstruct the original HTTPS URL and fell back to the raw request scheme/host.

To complete setup, I accessed Sortarr directly using the NAS LAN IP and the setup POST succeeded immediately. After setup was complete, the reverse proxy URL started working normally so I'm guessing Sortarr is receiving the correct forwarded headers.

(I replaced some of the information below with "xxx" for security purposes.)

Reverse‑proxy headers configured in DSM:
These were the exact headers set on the DSM reverse‑proxy rule:
X‑Forwarded‑Proto: https
X‑Forwarded‑Host: sortarr.xxx.xxx.xxx
X‑Forwarded‑Port: 443
X‑Forwarded‑For: $remote_addr (also tried $proxy_add_x_forwarded_for)
DSM was expected to forward these to the container, but during the setup POST it forwarded none of them. Questioning whether setting any these in DSM actually does anything.

Proxy topology
Environment: Synology DSM reverse proxy → Docker container
Reverse proxy rule: HTTPS → HTTP (localhost:8787)
No additional proxy layers (Cloudflare, Traefik, etc.)
Internal DNS resolves the hostname to the NAS LAN IP (split‑horizon)
Browser → DSM reverse proxy → container

/api/diagnostics/csrf
During the failing setup POST, Sortarr reported:
scheme = http
is_secure = false
X‑Forwarded‑Proto = ""
X‑Forwarded‑Host = ""
X‑Forwarded‑Port = ""
remote_addr = xxx.xxx.xxx.xxx (Docker bridge)
host_url = http://sortarr.xxx.xxx.xxx/
csrf_valid = true but reason = "origin"
This matched the CSRF rejection logs.

/api/diagnostics/security-self-check:
Before setup was completed, the self‑check showed:
Session secret: ephemeral (expected before config is saved)
CSRF middleware: active
Proxy fix: all zeros
No trusted origins configured (expected during setup)

Latest CSRF rejection log line:
CSRF request rejected: {
"extra": {"csrf_valid": true},
"headers": {
"Host": "sortarr.xxx.xxx.xxx.xxx",
"Origin": "https://sortarr.xxx.xxx.xxx.xxx",
"Referer": "https://sortarr.xxx.xxx.xxx.xxx/setup",
"X-Forwarded-For": "",
"X-Forwarded-Host": "",
"X-Forwarded-Port": "",
"X-Forwarded-Prefix": "",
"X-Forwarded-Proto": ""
},
"host_url": "http://sortarr.xxx.xxx.xxx.xxx/",
"is_secure": false,
"scheme": "http",
"remote_addr": "xxx.xxx.xxx.xxx",
"reason": "origin"
}

[Jaredharper1]

Hi there, I am sorry for the delayed response! I believe this issue could now be resolved in the latest release, and was related to other CSRF/security regressions in the 0.8.X branch. Can you please test things out on 0.8.7 and let me know if the issue is resolved?

[kadeschs]

I haven’t experienced any problems since passing setup. It’s still loading fine. I did note a couple things in the logs I thought I’d mention:

2026-03-22 22:12:19,950 WARNING sortarr: Deprecated config key in use: SORTARR_PROXY_HOPS. Prefer SORTARR_PROXY_MODE (or keep hops only for custom mode).
2026-03-22 22:12:19,952 WARNING sortarr: Deprecated config key in use: TAUTULLI_METADATA_LOOKUP_LIMIT. Prefer internal enforced default (remove user override).
2026-03-22 22:12:19,952 WARNING sortarr: Deprecated config key in use: TAUTULLI_METADATA_LOOKUP_SECONDS. Prefer internal enforced default (remove user override).