sami7777/dashcaddy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

[glm-grade=A] fix(csrf): tag browser auto-retry as [CSRF-debug], keep [CSRF] for real probes (DC-058)

Browse Source 
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.

GLM-5.3 judge (60s, 2 tool calls, sha 084672c parent 2f76b83):
GRADE=A — log tag branched only on headerToken presence with identical
403 body, headerToken read for tag-detection only (still validated via
timingSafeEqual at lines 248-260), 33 csrf tests + 33 regression tests
all pass. SHIP.
This commit is contained in:
DashCaddy Loop
2026-08-18 04:17:50 -07:00
parent 2f76b83565
commit 8105bed3fb
2 changed files with 101 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
dashcaddy-api/src/security/csrf-protection.js
+18 -2
View File
@@ -214,14 +214,30 @@ function csrfValidationMiddleware(req, res, next) {
return next();
}
// Validate both values exist
// DC-058: differentiate "browser auto-retry" from "real probe" using the
// X-CSRF-Token header as a signal. The dashboard JS in status/js/globals.js
// secureFetch() pre-fetches /api/v1/csrf-token (which sets the CSRF cookie
// via csrfCookieMiddleware) before posting; if the GET raced with container
// restart OR the user cleared cookies mid-session, the POST can arrive with
// a header but no cookie. secureFetch catches the 403 and auto-retries
// with a fresh token (lines 225-238 of globals.js). For these "has header
// but no cookie" misses, tag the log line [CSRF-debug] — operators can
// grep them out as expected noise. A request with NEITHER cookie NOR
// header (curl probe, exploit scanner, broken client) keeps the louder
// [CSRF] tag.
if (!cookieNonce) {
process.stderr.write(`[CSRF] Missing CSRF cookie: ${method} ${req.path} from ${req.ip}\n`);
const isLikelyBrowserAutoRetry = !!headerToken;
const tag = isLikelyBrowserAutoRetry ? '[CSRF-debug]' : '[CSRF]';
process.stderr.write(`${tag} Missing CSRF cookie: ${method} ${req.path} from ${req.ip}` +
(isLikelyBrowserAutoRetry ? ' (browser auto-retry — header present, expect self-heal)' : '') + '\n');
return errorResponse(res, 403, '[DC-100] CSRF token missing', {
message: 'CSRF cookie not found. Please refresh the page (Ctrl+Shift+R) and try again.'
});
}
// Cookie present but no header — a real browser POST always sends both, so
// header-less is suspicious (curl probe with manual cookie, misconfigured
// client). Keep WARN level.
if (!headerToken) {
process.stderr.write(`[CSRF] Missing CSRF header: ${method} ${req.path} from ${req.ip}\n`);
return errorResponse(res, 403, '[DC-100] CSRF token missing', {