Report a vulnerability privately through GitHub's Report a vulnerability
button on the Security tab, or by email to the address in
packages/core/src/brand.ts. Please do not open a
public issue for anything exploitable.
Include what you did, what happened, and what you expected. A proof of concept helps. You will get an acknowledgement, and I will tell you when it is fixed.
This product handles people's disputes with institutions that have more lawyers than they do, so the sensitive parts are narrow and specific:
- The encrypted tracker backup.
apps/web/src/lib/vault.tsseals the payload in the browser with AES-256-GCM under a PBKDF2-derived key, andapps/web/src/app/api/vault/route.tsonly ever stores the ciphertext, keyed by the session subject. Anything that lets the server read a backup, or lets one account address another's key, is the most serious class of bug here. - The Content-Security-Policy in
apps/web/next.config.ts.connect-srcis'self'and the only non-self host in the entire policy is Google's sign-in endpoint. That policy is the auditable form of the promise that claim details never have to leave the device. Anything that widens it, or any injection that gets around it, breaks that promise. - The lookup layer.
apps/web/src/lib/lookup/calls third-party flight APIs from the server so the browser never has to. It must send only a flight number and a date.tests/api/lookup-privacy.test.tsasserts that a claimant's name, address, booking reference and contact details never appear in an outbound request; a way to make them appear is a vulnerability. - Session handling. Sessions are stateless JWTs and there is no user table. Anything that forges or fixates one is in scope.
- A wrong legal figure. That is a serious bug and I want to hear about it — see CONTRIBUTING.md — but report it as a normal issue with the primary source, not privately.
- Rate limits being reachable. They are per-IP and deliberately generous; the API is meant to be used.
- The absence of an account system. That is the design.