Security

How we protect your code and your account. To report a vulnerability, use the contact form (choose the topic “Security report”).

Your data

• Anonymous checks are processed in memory and never written to disk or a database.
• Signed-in history lives in a Postgres table protected by row-level security: every read, rename and delete runs with your own sign-in token, so the database itself refuses access to anyone else's rows.
• Saved results are signed by the server; users can't insert or alter a stored result, so a saved or shared report always shows what the detector computed.
• Uploads are processed in memory and never executed. Archives are checked for zip bombs and path tricks.
• Share links are opt-in, unguessable and can be turned off instantly.

Accounts

• Authentication by Supabase Auth: email + password, magic links and (when enabled) Google. Tokens are verified on every request against the project's published signing keys.
• API keys are shown once and stored only as SHA-256 hashes, with per-key rate limits and usage metering.
• Organizations isolate schools and teams; roles (owner, admin, member; instructor, TA) scope who sees what. Org admins see an audit log of exports, sharing, role changes and key creation.

Infrastructure

• Hosted on Amazon Web Services. TLS everywhere, HSTS, a strict Content-Security-Policy with no third-party scripts, and other security headers.
• No advertising or tracking scripts. Fonts and libraries are served from our own domain.

Responsible disclosure

Send details through the contact form (choose the topic “Security report”). We'll acknowledge your report and keep you updated while we fix it. Please don't access other users' data or degrade the service while testing.