Reporting a vulnerability
If you believe you have found a security issue in BoltToCart, please report it through GitHub's private Security Advisories flow. GHSA reserves a CVE, keeps the report confidential until we ship a fix, and gives you a direct channel to the maintainers without any public-issue disclosure risk.
Report a vulnerability on GitHub (opens in new tab)
Automated scanners, bug-bounty triage tools, and browser extensions that follow RFC 9116 can also find the machine-readable contact at /.well-known/security.txt. Both paths lead to the same GitHub Security Advisories flow.
In scope
BoltToCart is a publicly-developed reference implementation. The source is open and the catalog data on the demo tenant is fake (designers, SKUs, prices, and bolt counts are all seeded demo content). Reports most valuable to us are issues in the code itself — tenant-isolation escapes, authentication or authorization bugs, injection, SSRF, unsafe deserialization, and cross-site scripting or cross-site request forgery that would affect a real deploy.
Out of scope
Because this is a reference project without a bug-bounty program or production customer data, the following are out of scope for disclosure reports:
- Issues that only affect third-party hosting providers (Vercel, Clerk, Postgres providers) — please report those to the vendor directly.
- Missing security headers or cookie flags that do not lead to a concrete exploit (we welcome pull requests to tighten headers via the normal contribution flow).
- Self-XSS, clickjacking without a sensitive action, and denial-of-service.
- Reports generated by automated scanners without a concrete proof-of-concept.
What to expect
We triage advisories on a best-effort basis, typically within a few business days. We will acknowledge receipt, confirm or refute the issue, and — if confirmed — coordinate a fix and a public advisory with you. There is no monetary bounty; a CVE credit and a mention in the advisory are the acknowledgement we can offer.
Please do not disclose the issue publicly until we have had a chance to coordinate a patch. Testing on the public demo tenant is fine as long as it respects other users and does not attempt to degrade or deface the service.