Data & security

TrackCDC has no password of its own. Signing in is delegated to Google or GitHub, so there is nothing here for us to leak, and nothing for you to reuse from another site.

• We never see your password. It is entered on the provider's own site and never reaches us.
• Every address on file is provider-verified. An account is only created once Google or GitHub confirms you control the address — Google via its email_verified claim, GitHub via its verified-addresses endpoint.
• Two providers can share one account, but only safely. Signing in with GitHub joins an existing Google account only when GitHub confirms the same address is verified. An unverified address is refused outright, which is what stops someone adding your email to their own account to reach your workspace.
• Sign-in is protected against forged requests with a single-use state value and, for Google, PKCE.

One disclosure worth naming: if you try to sign in with a provider that is not linked to an address that already has an account, we tell you which provider that account uses. That is only visible to someone who already controls a verified copy of the address.

• Your session is a signed httpOnly cookie. JavaScript cannot read it, so a scripting bug on the page could not steal it.
• It is signed with a server-side secret. Editing the account id inside it invalidates the signature, so a session cannot be forged into someone else's.
• Sessions expire after 30 days, and are sent only over HTTPS in production.

Both workspace endpoints identify you from the session cookie, never from anything the page sends. A request cannot name another account's workspace to read or overwrite it.

Saves are shape-checked before they are written, so a malformed request cannot replace a good workspace with something unreadable. Database credentials exist only on the server and are never part of the JavaScript sent to your browser.

• Edge-level Rate Limiting. All requests are monitored by a sliding-window rate limiter at the routing level. IP addresses are limited to 20 requests/min for authentication, 30 requests/min for workspace updates, and 60 requests/min for read-only pages to prevent DDoS and automated scrapers.
• Hardened Security Headers. Every server response contains explicit security headers denying iframing (X-Frame-Options: DENY to prevent clickjacking), disabling camera/mic permissions, forcing HTTPS via HSTS, and blocking content-type sniffing.
• Document Vault Sandboxing. Files uploaded to the Document Vault are checked against a strict content-type allowlist (PDF, standard Office formats, plain text, CSV, ZIP/RAR, and standard images). Dangerous files like raw HTML or SVGs are blocked at URL generation to prevent stored cross-site scripting (XSS).

Stated plainly, because a reassuring summary would be worse:

• Account recovery depends on your provider. If you lose access to the Google or GitHub account you signed up with, we cannot restore your workspace.
• No two-factor authentication of our own — though whatever you have enabled on Google or GitHub applies.
• Data is not encrypted field-by-field at rest. It is protected by database access control and encrypted in transit, but anyone with database access could read it.

The demo tour has no account and never writes to the database. It runs on sample data in your browser, so nothing you do there is stored anywhere by us.

To protect staging builds, the site automatically toggles a preview passcode screen on test environments (like test.trackcdc.me or Vercel preview branches). The production build on the main domain (trackcdc.me) bypasses this curtain. This check is a casual-access barrier for development, not a cryptographically secure boundary.

If you find a vulnerability, please report it through the developer page rather than demonstrating it against other people's accounts.