Security

TrackOut takes the security of our users' data seriously. If you believe you've found a vulnerability in TrackOut, we want to hear about it -- and we want to make it easy and safe for you to tell us.

This page covers how to report security issues, how to report regular bugs, what's in scope, and the commitments we make to researchers acting in good faith.

Reporting a security vulnerability

If you believe you've found a security vulnerability, please report it privately by emailing TODO:security-email rather than opening a public GitHub issue or posting in a community channel.

A good report includes:

• A clear description of the issue and its potential impact
• Steps to reproduce, ideally with a proof-of-concept
• The affected URL, page, or component (and the version or commit if known)
• Your name or handle if you'd like public credit for the disclosure

What to expect

• Acknowledgment within TODO:response-sla-ack of your initial report
• A status update as we triage and reproduce the issue
• A target resolution timeline of TODO:response-sla-fix for confirmed issues, depending on severity
• A follow-up once the fix is shipped, and public credit (with your permission) in our changelog

Reporting a non-security bug

For non-security bugs, regressions, and feature requests, please use the public GitHub Issues tracker. Include:

• What you expected to happen
• What actually happened
• Steps to reproduce
• Your browser, OS, and (if relevant) the car or session you were working with

Bug bounty

TrackOut does not currently operate a formal bug bounty program. We deeply appreciate responsible disclosure and will publicly credit researchers (with permission) for valid reports in our changelog.

If this changes in the future, we'll update this page and announce it in the Changelog.

Scope

The following hosts and assets are in scope for security reports:

• trackout.app and www.trackout.app -- production web app
• beta.trackout.app -- beta / staging deployment
• docs.trackout.app -- this documentation site
• The TrackOut backend Convex deployment that powers the above

The following are out of scope -- please do not test or report on these:

• Denial-of-service (DoS) attacks, volumetric attacks, or anything that degrades the service for other users
• Social engineering of TrackOut staff, users, or contractors
• Physical security attacks
• Findings on third-party services we depend on (Stripe, Google OAuth, Convex, Vercel, PostHog) -- please report those directly to the affected vendor
• Reports based solely on automated scanner output without a demonstrated impact
• Missing security headers, cookie flags, or TLS configuration without a demonstrated exploit
• Self-XSS, clickjacking on pages with no sensitive actions, or rate-limit issues without an account-takeover or data-exposure path
• Vulnerabilities in software versions older than the current production release

Safe harbor

We consider security research conducted under this policy to be authorized, and we will not pursue legal action against researchers who:

• Make a good-faith effort to avoid privacy violations, data destruction, and service disruption
• Only interact with accounts they own or have explicit permission to test
• Report the issue privately as described above and give us a reasonable opportunity to fix it before any public disclosure
• Do not exfiltrate more data than is necessary to demonstrate the vulnerability, and securely delete any incidentally accessed data after reporting

If in doubt about whether your testing is authorized, email TODO:security-email before you start and we'll work it out with you.

Past disclosures

Security fixes are noted in the Changelog. Researchers are credited there with their permission.