Background: every time dashcaddy-api restarts, the first POST from a
dashboard browser tab hits the missing-CSRF-cookie branch. The
status/js/globals.js secureFetch() wrapper catches the 403 and
auto-retries with a fresh token, so the WARN line is misleading noise.
Live evidence (DNS2, 2026-08-18 10:35:32Z container restart):
[CSRF] Missing CSRF cookie: POST /api/v1/backups/schedule from 100.121.150.22
[CSRF] Missing CSRF cookie: POST /api/v1/backups/schedule from 100.121.150.22
[CSRF] Missing CSRF cookie: POST /api/v1/backups/schedule from 172.17.0.1
Fix: if X-CSRF-Token header is ALSO present, tag the log line [CSRF-debug]
(operator can grep it out as expected noise — the secureFetch retry will
self-heal). A request with NEITHER cookie NOR header (curl probe, exploit
scanner, broken client) keeps the [CSRF] tag.
Threat model: forging a header without the cookie just produces a
different 403 (Invalid CSRF token) — the timingSafeEqual check on lines
248-260 of csrf-protection.js is unchanged. This is a log-only fix.
Tests: 4 new in __tests__/csrf-protection.test.js under
'DC-058: browser-auto-retry vs real-probe log tagging'. Full suite
1982/1982 green on DNS2 worktree.
[self-grade=pending]
