Security policy

Email support@racerecords.run with a description of the issue, steps to reproduce, and (if you have one) a proof of concept. Use the subject line prefix [security] so it routes correctly.

Acknowledgement target: within 72 hours.

Please do not file public bug reports for suspected security problems.

In scope:

• Authentication and session handling (Supabase Auth, cookie handling, OAuth state on the Strava integration).
• Authorization and RLS bypass (data accessible to a user other than its owner).
• Server-side injection (SQL, command, SSRF, XSS persisted in user-visible surfaces).
• Strava OAuth-token disclosure or any leak of user_integrations data.
• Account-takeover paths through the public profile or handle URL.

Out of scope:

• Self-XSS.
• Rate-limit complaints on non-credential endpoints.
• Missing security headers without a concrete exploit.
• Denial-of-service against the public profile route.
• Vulnerabilities in third-party services (Supabase, Vercel, Strava) themselves.

Strava-data breach definition: any unauthorized access, disclosure, loss, or alteration of OAuth tokens stored in user_integrations, or of Strava API response data fetched via those tokens. The 24-hour clock starts at the moment the breach is confirmed, not the moment it is first suspected.

If a leak is suspected:

1. Rotate STRAVA_CLIENT_SECRET in the Strava API settings dashboard; update the Vercel production env immediately. Existing access tokens remain valid until expiry; they were issued against the old secret but are still bearer credentials.
2. Force-expire every stored Strava access token to require a refresh:

   update public.user_integrations
     set expires_at = now() - interval '1 hour'
     where provider = 'strava';

   The next sync per user triggers a refresh through the new secret.
3. If the leak includes refresh tokens, the only safe recovery is to drop every Strava integration and require users to reconnect:

   delete from public.user_integrations where provider = 'strava';
   delete from public.races where is_draft = true;

   Then notify affected users and Strava per the SLAs above.
4. Rotate STRAVA_STATE_SECRET so any in-flight OAuth state tokens signed before the incident are invalidated.
5. Open a post-incident note (date, scope, root cause, remediation, notification status) for the audit trail.

The SUPABASE_SERVICE_ROLE_KEY bypasses RLS. Treat any disclosure as a full-database breach.

1. Rotate the key in Supabase dashboard, Project Settings, API, service_role, Reset.
2. Update the Vercel production env and any other deployments.
3. Redeploy so the Strava deauthorization webhook picks up the new key.
4. Assess whether the leaked key was used: Supabase project logs, filter by API key, review write events outside expected paths.
5. Notify users and Strava per the SLAs above if data was accessed or exfiltrated.

• Production runtime deps are pinned via package-lock.json.
• Renovate / Dependabot updates handled on the main branch.
• npm audit reviewed on every release cut.

Email support@racerecords.run with subject line prefix [security].