Skip to content

docs(security): §8.3 — backend tokens are now bounded (30d) + revocable (#302)#338

Open
LukasWodka wants to merge 1 commit into
developfrom
docs/302-security-md-token-ttl
Open

docs(security): §8.3 — backend tokens are now bounded (30d) + revocable (#302)#338
LukasWodka wants to merge 1 commit into
developfrom
docs/302-security-md-token-ttl

Conversation

@LukasWodka

@LukasWodka LukasWodka commented Jul 12, 2026

Copy link
Copy Markdown
Contributor

Summary

docs/SECURITY.md §8.3 still claimed backend tokens never expire ("no TTL... valid forever until manually deleted") with a stale mitigation plan. The tracked backend work has landed, so this rewords §8.3 (heading + body) to the current reality, per the issue's 3-point scope:

  1. Data-scientist web sessions — mitigated: bounded, revocable 30-day ClientAccessToken (revocation via /auth/revoke, /logout/, password change, and a Django-admin bulk-revoke action; deliberately no refresh token). tracebloc/backend#933, tracebloc/frontend-app#575.
  2. Edge devices / bots — by design: non-interactive service credentials keep the legacy non-expiring DRF Token, stated explicitly as intentional.
  3. Residual risk: token in JS-readable browser storage stays tracked backend-side (SEC-06 residual follow-up to tracebloc/backend#590).

Also a 1-line polish of §9 step 3 (the incident-response edge-token line now points at §8.3), and a document-history entry. Verified no summary/gaps table elsewhere in the doc references §8.3 (the G-table only references §8 generally).

Related

Closes #302 · Refs tracebloc/backend#590, tracebloc/backend#933, tracebloc/frontend-app#575

Type of change

  • Feature
  • Bug fix
  • Tech-debt / refactor
  • Docs
  • Security / hardening
  • Breaking change

Test plan

Docs-only. Grepped the doc for 8.3 / token / expiry mentions — the only §8.3 references are the section itself and the (updated) §9 step 3 line. scripts/manifest.sha256 untouched (docs are not on the signed-manifest surface).

Checklist

  • Tests added / updated and passing locally — N/A (docs-only)
  • Docs updated if behavior or config changed
  • No secrets / credentials in the diff
  • For security-sensitive paths: appropriate reviewer requested

🤖 Generated with Claude Code


Note

Low Risk
Documentation-only update to docs/SECURITY.md; no runtime, config, or credential handling changes in this repo.

Overview
§8.3 no longer states that all backend tokens never expire. It now distinguishes web sessions (30-day revocable ClientAccessToken, with revocation paths and no refresh token) from edge/bot credentials (legacy non-expiring DRF tokens, documented as intentional), and notes the XSS / JS-readable storage residual tracked backend-side.

§9 step 3 now tells operators to have the tracebloc team revoke leaked edge tokens because they do not expire on their own, with a pointer to §8.3.

§11 adds a 2026-07 history entry for this §8.3 refresh.

Reviewed by Cursor Bugbot for commit e282e88. Bugbot is set up for automated code reviews on this repo. Configure here.

…le (#302)

SECURITY.md §8.3 still claimed backend tokens never expire with a stale
mitigation plan. The tracked work landed (tracebloc/backend#590 via #933 +
tracebloc/frontend-app#575), so reword the section to the current reality:

- Data-scientist web sessions: bounded, revocable 30-day ClientAccessToken
  (revoke via /auth/revoke, /logout/, password change, admin bulk-revoke;
  no refresh token by design) — finding mitigated.
- Edge devices / bots: keep the legacy non-expiring DRF Token by design
  (non-interactive service credentials; expiry would take an edge offline).
- Residual JS-readable-storage risk stays tracked backend-side (SEC-06
  follow-up to backend#590).

Also aligns §9 step 3 (edge-token revocation wording) and adds a document
history entry. No other section references §8.3, verified. Docs-only — no
manifest impact.

Closes #302

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@LukasWodka

Copy link
Copy Markdown
Contributor Author

👋 Heads-up — Code review queue is at 42 / 30

Above the WIP limit. The team convention is to review existing PRs before opening new work.

Open PRs currently in Code review (oldest first):

Pull from review before opening new work. (This is a nudge from the kanban WIP check, not a block.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants