How to report a vulnerability

If you believe you have found a security issue in Routescore — the app, the public API, the @routescore/mcp server, a scanner, or any public methodology — email [email protected]. We acknowledge reports within 24 hours and aim to send a triage decision (accepted, duplicate, out-of-scope, or need-more-info) within 5 business days.

Please include: a clear description, the affected URL or endpoint, reproduction steps or a proof-of-concept, the impact you believe it has, and any accounts or wallet addresses you used (use throwaway test accounts where possible — see Safe-harbor below).

Scope — in scope

Findings against the following assets are eligible for coordinated disclosure:

routescore.io and www.routescore.io (production app)
The public REST API under /api/public/v1 (authentication, rate-limit, and authorization surfaces)
The @routescore/mcp server and any MCP tool that proxies the public API
Account, session, billing/entitlement, and data-export (journal / report) surfaces

We are especially interested in: authentication / session bypass, broken authorization (IDOR / tenant isolation), tier / entitlement escalation, API-key or MCP abuse, rate-limit bypass, data exfiltration via export endpoints, server-side request forgery, injection, and any path that lets one user read or mutate another user's data.

Scope — out of scope

Findings against third-party services we depend on (Vercel, Cloudflare, Neon, Stripe, PostHog, Sentry, RPC/DEX providers, etc.) — report those to the vendor
Social-engineering attacks against our team, contractors, or users
Physical attacks or attacks requiring physical access
Volumetric / denial-of-service attacks (DDoS) and any test that degrades availability for other users
Automated-scanner output submitted without a working proof-of-concept and impact analysis
Missing security headers, cookie flags, or TLS configuration without a demonstrated exploit
Self-XSS, clickjacking on pages with no sensitive actions, and best-practice / hardening suggestions with no security impact
Reports that Routescore output is “wrong” — scores are modeled, point-in-time, and explicitly not investment advice (this is a product question, not a vulnerability)

Rules of engagement

Only test against accounts and wallets you own. Never access, modify, or delete data that is not yours.
Use your own test accounts where possible instead of production.
Do not run automated scanners at a rate that affects availability for other users.
Stop at the first proof of a vulnerability — do not pivot, escalate, or exfiltrate beyond what is needed to demonstrate impact.
Keep findings confidential until we have remediated and agreed on a disclosure timeline.

Safe-harbor

We will not pursue or support legal action against, and we authorize good-faith security research by, researchers who:

follow this policy and the rules of engagement above, and report to us before disclosing;
make a good-faith effort to avoid privacy violations, data destruction, and service degradation;
do not access, modify, exfiltrate, or destroy data beyond the minimum needed to demonstrate the issue; and
give us a reasonable time to remediate before any public disclosure (default 90 days, sooner by mutual agreement).

Activity conducted consistently with this policy is considered authorized, and we will not consider it a violation of our Terms of Service. If legal action is initiated by a third party against you for activity that complied with this policy, we will make this authorization known. This safe-harbor does not extend to actions taken in bad faith, against out-of-scope assets, or against other users' data.

Rewards & recognition

Routescore does not yet operate a formal, paid bug-bounty program. Until a bounty launches, we handle reports as coordinated disclosure: we triage on the timeline above, fix on a severity-weighted schedule, and — with your consent — credit you in a public acknowledgements list. We may offer discretionary rewards (swag, account credit, or a cash thank-you) for high- and critical-severity findings that materially improve user safety.

When a formal bounty does launch, its scope, severity rubric, and reward tiers will be published on this page and at /.well-known/security.txt, and this paragraph will be replaced with the live program terms.

Acknowledgements

We publicly thank researchers (with their consent) who have responsibly disclosed valid issues. This list is currently empty — be the first.

Encrypted reports (PGP)

For sensitive reports you can encrypt to our security mailbox. The published public key lives at /.well-known/security-pgp.asc and is referenced from /.well-known/security.txt via the RFC 9116 Encryption field.

Verify the fingerprint before trusting the key: 4226 398D EE6A 90CE 950C ABBD BFF6 77F2 AE7A 1F75 (ed25519, expires 2028-06-25).

If your client can't fetch the key, email [email protected] and we'll arrange a secure handoff before you send any sensitive detail.

How we handle incidents

When an issue affects users, we follow a written incident process: detect, contain, eradicate, recover, and publish a blameless post-incident review. Our incident and post-mortem template is public — see INCIDENT_TEMPLATE.md. For a plain-language overview of our security posture, see the security explainer in the help center.

See also /.well-known/security.txt (RFC 9116).