Security, in plain English.

Hosting region and how long results are kept will be in our privacy policy before launch.

A bug in a check must never change your data. So the database itself enforces the promise, not just our code. Around every single check query, SafeFix sends this:

BEGIN TRANSACTION READ ONLY;
SET LOCAL statement_timeout = 15000;
SET LOCAL row_security = off;
-- one check query: exactly one statement
ROLLBACK;

A READ ONLY transaction

Each query runs in its own read-only transaction. Postgres refuses any write, and the transaction is rolled back at the end.

One statement at a time

Queries use a mode that accepts exactly one statement, so nothing can sneak in a “commit” and escape the transaction.

row_security off

If your rules would hide rows from SafeFix, Postgres stops with an error instead. A check never says “all clear” from half the data.

When SafeFix finds a key, it shows just enough to tell which key it is, never enough to use it.

In the CLI, a long key also keeps its first 4 characters, which are usually a public prefix like sk_l or eyJh. Short values are hidden completely.

• SafeFix never runs a fix. Each fix is shown as text, so you can read it, copy it and run it yourself, or skip it.
• Every built-in SQL fix is tested by automated tests before it ships: applied to a test database, checked, then rolled back.
• When a safe fix cannot be written for you, the report says so and explains the steps instead.

• The CLI scans the folder you run it in, and the database you give it a login for.
• The browser version scans only projects you connect yourself, with read-only access you can remove at any time.
• SafeFix does not scan websites or databases that you have not connected.

SafeFix runs 30 checks across database rules, storage, secrets, app settings, Docker and GitHub Actions. Each check has a stable id (like db.rls-disabled), clear rules for how serious a finding is, a plain-English explanation, and a fix when one can be written safely.

We test the checks against a test database full of deliberate mistakes, plus “decoys”: correct setups that must not be reported. That is how we keep false alarms down. And we count honestly: a key that is public by design is never reported as a leak.

See a sample report

• Firebase, MongoDB, MySQL and Terraform are not checked yet. Every report lists the parts of your stack that SafeFix does not cover.
• Caller checks in database functions are a heuristic. SafeFix looks for code that really uses the caller’s id in a decision. When unsure, it reports the function. It is a careful guess, not a proof.
• The public Supabase anon key is not treated as a leak. It is meant to be in your website code, and your Row Level Security rules protect the data. SafeFix reports the service_role and secret keys, which must stay private.
• SafeFix does not test your live website (headers, TLS, cookies) or the logic of your own app code.

SafeFix is a small, early product. We will not show badges for audits we have not done. What we do today is on this page: read-only scans, masked secrets, fixes you approve, and honest limits.

Security contact coming soon.

We are setting up a private address for security reports. Until it is here, please do not share details of a problem in public.