Security audit for authentication and logic bugs

Audit trackslash for authentication and authorisation flaws, and for logic bugs that let someone see or do more than their role allows. The preview at trackslash.com is public, open to sign-up and accepts public issue creation, so these matter now rather than only at a stable release.

This project is public. Do not put exploitable details in this issue, its comments or a public PR description before a fix ships. Report confirmed vulnerabilities as SECURITY.md describes ([email protected]). Once a fix is merged, a follow-up issue can say what was fixed.

Authentication

• Password login, sign-up and sessions: cookie flags, session renewal, expiry, logout and password-change invalidation, and the auth rate limits (auth_rate_limit.go).
• Passkeys: challenge binding and expiry, origin and RP ID checks, and credential ownership on removal. Check that removing the last sign-in method cannot lock an account out or leave it open.
• API tokens (auth_tokens): revocation takes effect straight away, and one user cannot mint or revoke another user's tokens. OAUTH.md notes that the bearer middleware accepts any token kind, so confirm this is intended for every kind that exists.
• OAuth 2.1 and MCP bearer auth: PKCE is enforced, redirect URIs match exactly, codes and refresh tokens are single-use with replay revocation, client secrets are verified, consent is per user, and revoking a connector cuts off every approval. Also check the MCP auth challenge.
• CSRF and redirects: CSRF on every state-changing UI form (ui_csrf.go), and open redirects through ?redirect= or the OAuth return paths.
• Realtime: realtime_auth.go authorises every topic subscription, and access is re-checked after membership is revoked.
• GitHub credentials and integrations: encryption at rest, and who can use or read a stored credential.

Authorisation and logic

• The three surfaces agree: the REST API, the UI handlers and the MCP tools apply the same permission check for each action (access, write, create issue, manage members, delete), with none missing.
• Roles: owner, member, read-only, public viewer, public issue creator and blocked user. Look for role escalation, self-promotion, demoting or removing the owner, and blocked users still reaching the project.
• Cross-project references (IDOR): attachments, object-N and storage objects, contexts, whiteboard pages, sprint attachments, comments (editing or deleting someone else's), issue links and sub-issues that cross into a private project, tags, and deleted issues and restore.
• Public views: public project pages, public refs (public_refs.go), the changelog, insights and stats must not leak private data such as member emails, private linked issues or deleted content.
• User and token admin tools: check who can call the MCP tools that create, delete or list users and tokens (track_create_user, track_delete_user, track_create_user_token, track_list_users).
• Content: XSS in rendered Markdown (descriptions, comments, context, whiteboard), and the content types used to serve attachments inline.
• Notifications: check that push notifications stop revealing a private project's issue titles once the recipient loses access.
• Abuse: limits on public issue creation and on sign-up.

Done when

Each area above has been reviewed. Every confirmed bug is fixed with a regression test that goes through the public API, as the coverage policy in AGENTS.md asks. Anything accepted as a trade-off is written down, in OAUTH.md or a new SECURITY_MODEL.md, instead of being left implicit.