Security

Found something? Please email hello.mintoken@gmail.com with the subject line [Security]. Do not open a public GitHub issue or post about it on social.

What to include:

• A short description of the issue and its impact.
• A minimal reproduction (request / response, repro steps, or a proof-of-concept curl).
• Whether you want public credit when we publish the fix.

What you get back: acknowledgement within 48 hours, a fix timeline within 7 days, and credit in the changelog if you want it. We don't run a paid bug bounty yet, but we will absolutely send you a thank-you + Mintoken credits for any valid report.

The single most sensitive piece of data flowing through Mintoken is your upstream provider key (OpenAI, Anthropic, Google, etc.). We designed the proxy so we never need to keep it.

• Your X-Provider-Key header is read in memory, forwarded to the upstream provider, and dropped at the end of the request. Never written to disk, never logged, never put in a database.
• Request prompts and model responses are never persisted. We count tokens, that's it.
• Rotating your provider key in OpenAI / Anthropic / whatever automatically locks Mintoken out too — we have no copy.

• HTTPS only. All traffic to api.mintoken.dev and mintoken.dev is TLS 1.2+. HTTP redirects to HTTPS at the edge.
• Hashed API keys. Your mt_live_… keys are hashed with a strong one-way function before storage. The plaintext is shown to you exactly once at creation. If you lose it, you rotate it — we cannot recover the original.
• Row-level security.The database enforces RLS so one user's queries can never return another user's rows. Service-role access is scoped to the backend only.
• Encrypted secrets. Env vars (Supabase service key, Razorpay secret, etc.) are encrypted at rest in the deployment platform.

• Authentication, session, or API-key handling on api.mintoken.dev or mintoken.dev.
• Cross-tenant data leaks (one user reading another's data).
• RCE, SSRF, or any path that lets an attacker exfiltrate provider keys, even momentarily.
• Anything in the open-source repos at github.com/JuliusBrussee/mintoken or github.com/vijayPrajapatii/mintoken that creates a user-impacting vulnerability.

• DoS / volumetric attacks — please don't. We rate-limit per key already; flooding us is just being mean.
• Self-XSS that requires the victim to paste attacker-controlled code into devtools.
• Missing security headers on static marketing pages with no user data.
• Outdated library versions without a working exploit path.
• Social engineering of Mintoken staff or customers.

We will not pursue legal action against researchers who:

• Make a good-faith effort to avoid privacy violations, destruction of data, and interruption of service.
• Only access the minimum data necessary to demonstrate the issue.
• Give us reasonable time (at least 7 days) to fix before public disclosure.