Security hardening: auth, CSRF, CI, and threat model

[jameswnl]

Summary

Addresses all findings from security_analysis.md:

• Per-launch auth token — random secrets.token_urlsafe(32) generated at startup, required on all API endpoints via Authorization: Bearer header. Token is embedded in the HTML page served to the browser.
• Host header validation — rejects requests with non-localhost Host headers (DNS rebinding protection)
• Origin validation on POSTs — CSRF protection for side-effecting endpoints
• Session validation on /api/resume — verifies session_id and dirname exist in the current dataset before launching a terminal
• CI hardened — all GitHub Actions pinned to full commit SHAs, default permissions reduced to contents: read, badge generation isolated to a separate job with minimal contents: write
• Menu bar fix — removed generic lsof/kill fallback that could kill unrelated processes on the same port
• README — added Security section documenting the local threat model and all measures

Test plan

• All 110 tests pass
• New tests: auth rejection (missing token, wrong token), session validation rejection, HTML embeds token
• Existing tests updated to include auth headers
• Manual: start server, verify token printed, verify API rejects curl without token
• Manual: verify dashboard still works end-to-end in browser

🤖 Generated with Claude Code

[jameswnl]

Security review follow-up:

1. Medium: the new bearer token is still disclosed to any unauthenticated local client because / serves HTML that embeds the live AUTH_TOKEN. That means any local process that can reach 127.0.0.1:8420 can fetch /, extract the token, and then call /api/data or /api/resume. This is a meaningful improvement for hostile web origins, but it does not fully address the broader localhost-client threat model from security_analysis.md.

2. Low: the new Host and Origin protections are not covered by tests. I could not find regression tests that send an invalid Host header or hostile Origin, so the controls that most directly address the DNS-rebinding / CSRF findings can regress silently.

AI models used for this review:

• GPT-5.4 for the primary security analysis and PR review
• a faster helper model for initial repository mapping and context gathering

[jameswnl]

Addressed both review items in commit 4796fda:

1. Token disclosure on / (Medium)

• / now requires authentication — unauthenticated GET / returns 401
• Auth flow uses cookies: browser opens /?token=<secret>, server sets HttpOnly; SameSite=Strict cookie and redirects to /
• Subsequent browser requests (including JS fetch) automatically include the cookie
• Startup URL printed as http://localhost:8420/?token=<token> and opened in browser
• A local process blindly fetching / can no longer extract the token

2. Missing Host/Origin validation tests (Low)
Added 4 regression tests:

• test_rejects_invalid_host_header — verifies 403 for non-localhost Host (DNS rebinding)
• test_rejects_invalid_origin_on_post — verifies 403 for hostile Origin (CSRF)
• test_allows_localhost_origin_on_post — verifies legitimate Origin passes
• test_allows_no_origin_on_post — verifies non-browser clients without Origin work

Plus 2 tests for the new auth-on-HTML behavior:

• test_html_page_requires_auth — verifies unauthenticated / gets 401
• test_html_page_token_url_sets_cookie — verifies cookie flow (302 + Set-Cookie)

All 115 tests pass.

[jameswnl]

Security review outcome: approved in principle.

The previously identified blocking findings are addressed, including:

• authenticated HTML bootstrap instead of exposing the token to unauthenticated local clients
• regression coverage for Host and Origin validation

One non-blocking nit:

• test_html_page_token_url_sets_cookie would be a little stronger if it validated the query-token bootstrap path without also sending an Authorization header, so the test proves the /?token=... flow on its own.

I couldn't submit a formal GitHub approval because the authenticated account is the PR author, and GitHub does not allow approving your own pull request.