Supabase Security Audit
WarnAudited by ClawScan on May 16, 2026.
Overview
The skill’s security-audit purpose is coherent, but its script handles powerful Supabase database credentials unsafely and should be reviewed before use.
Review and patch the audit script before using production Supabase credentials. In particular, do not use arbitrary --pooler hosts, re-enable TLS certificate verification, validate UIDs, and require explicit approval before applying the SQL hotfix.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A mistaken or malicious pooler value, or a network attacker, could capture the Supabase database password or tamper with audit results.
The database host can be supplied via --pooler, the script sends the Supabase DB password to that host, and TLS certificate verification is disabled.
const pooler = args.pooler || 'aws-1-eu-central-1.pooler.supabase.com:6543'; ... password: cred.SUPABASE_DB_PASSWORD, ... ssl: { rejectUnauthorized: false },Only allow known Supabase pooler hosts, keep TLS verification enabled or pin Supabase’s CA, and avoid running this script with production credentials until fixed.
If an agent or user passes a crafted probe UID, it could execute unintended SQL using the privileged database connection.
A CLI-supplied UID is interpolated directly into SQL rather than validated as a UUID or passed as a parameter.
const probeUid = args['probe-uid']; ... await pg.query(`set local request.jwt.claims to '{"sub":"${probeUid}","role":"authenticated"}'`);Validate probe and target IDs strictly as UUIDs and set JWT claims with parameterized SQL, for example using `set_config` with a JSON-encoded parameter.
Installing or running the skill gives its script access to credentials powerful enough to read or change production Supabase data.
The skill requires service-role and direct database credentials, which can bypass normal application/RLS boundaries; registry metadata still lists no primary credential or required config path.
SUPABASE_SERVICE_ROLE_KEY=... SUPABASE_DB_PASSWORD=...
Use temporary or rotated audit credentials where possible, run in a trusted environment, and update the skill metadata to clearly declare the required credential file and privilege level.
The audit depends on whatever pg package is installed in that temporary location, which is a normal but review-worthy supply-chain dependency.
The setup uses an unpinned npm install in /tmp for a package the script dynamically loads.
mkdir -p /tmp/sb-tools && (cd /tmp/sb-tools && npm i pg)
Install a pinned pg version from a trusted lockfile or controlled project dependency location.
The hotfix is purpose-aligned, but applying it to production can change user access behavior or break application flows if the table/columns do not match.
The optional hotfix is a real database migration that changes RLS policy and installs a trigger.
drop policy if exists profiles_self_update on public.profiles; ... create trigger trg_profile_role_lock
Review and test the SQL in staging, back up the database, and require explicit user approval before applying the migration.
Security findings or environment details may be retained and reused in future agent context.
The workflow asks the agent to persist audit results into project memory or logs.
Append a one-paragraph summary to your project's memory or change-log file under a dated heading
Do not include secrets in the summary, and review any persistent memory/change-log entry before saving it.