Using VIfix

Database audits

Database audits inspect a live database through a read-only connection and turn gaps into findings with ready-to-run fixes.

Supported databases#

PostgreSQL and Supabase, MySQL and MariaDB, and MongoDB. Each audit counts as one scan.

Connect a database#

Open Database Audits and click Add connection. Paste a connection string or fill in host, port, user and database. SSL is on by default (verify-full); turning it off is only allowed for localhost. Passwords are stored in your OS keychain.

Recommended audit role#

Use a dedicated read-only user rather than your owner account. For Postgres or Supabase:

sql

create role vifix_audit login password '…';
grant pg_read_all_data, pg_read_all_settings to vifix_audit;
grant usage on schema auth to vifix_audit;  -- Supabase only

The connection dialog shows the matching commands for MySQL and MongoDB.

What gets checked#

Check	Postgres / Supabase	MySQL	MongoDB
Tables / collections inventory	✓	✓	✓
RLS disabled on exposed tables	✓	—	—
RLS with no policies, `using (true)`, `user_metadata` in policies	✓	—	—
Unindexed foreign keys / reference fields	✓	✓	✓
SECURITY DEFINER without `search_path`, views bypassing RLS	✓
Empty passwords, remote root, wildcard hosts, TLS not required		✓
No authentication, admin roles, missing validators			✓

See every database rule in Security rules.

Applying fixes#

Dry run rehearses transactional fixes with BEGIN … ROLLBACK.
Execute asks for confirmation and needs an owner account. Postgres fixes run in one transaction.
Save as migration writes supabase/migrations/<timestamp>_vifix_security_fixes.sql so you can review and deploy it yourself.

Safety model#

Audits never write

Audits run only read queries inside read-only transactions and always roll back. Fix SQL is generated from the database catalog, checked against a strict allowlist, and never typed or sent by the interface.