Supabase Pentest Skills - Setup Guide¶

Source: yoanbernabeu/supabase-pentest-skills via skills.sh - 13.1K combined installs across 25 indexed listings; first seen 2026-11-01 (morning sweep)

GitHub: yoanbernabeu/supabase-pentest-skills - 73 stars, MIT, branch main, last pushed 2026-01-31; 24 SKILL.md files, one per directory, grouped into ten category folders under skills/ (audit-api, audit-auth, audit-functions, audit-realtime, audit-storage, detection, evidence, extraction, orchestration, report), plus a templates/ folder with a CLAUDE.md agent template

Category: Security auditing for Supabase applications: detection, key extraction, API and RLS testing, storage, auth, realtime, functions, evidence collection and reporting

Quality Tier: 🟡 Yellow - every sampled listing carries a Snyk Warn with code W011, and supabase-pentest also returns Warn on Socket, while all Gen Agent Trust Hub verdicts are Pass

The premise of this pack is a property of Supabase itself. A Supabase application ships its database API to the browser with a public anon key, and Row Level Security is then the only thing standing between that key and the rows. When RLS is wrong, the data is not merely reachable by a determined attacker: it is reachable with a curl request that any client already knows how to make. Twenty-four skills exist here because the failure modes are numerous and mechanical: missing RLS, permissive policies, SECURITY DEFINER functions that ignore the caller, public storage buckets, Realtime channels that stream changes to anyone subscribed, and edge functions with broken access control.

The pack is organised as a pipeline with an orchestrator on top. Detect that the target is Supabase, extract the URL and keys, list and read tables, test RLS and RPC, then storage, auth, realtime and functions, and finish with a report that assigns P0, P1 and P2 severities. supabase-pentest walks the whole sequence with checkpoints and an ownership confirmation, supabase-help is a reference for all 24 skills and their commands, and supabase-report-compare diffs two reports so a team can see whether the remediation actually landed.

One convention runs through almost every skill and is worth knowing before you install: the audit is written to be resumable. Each skill is instructed to write findings to .sb-pentest-context.json as it goes, log every action to .sb-pentest-audit.log before and after, and save evidence and reproducible curl commands into a numbered directory per phase. The stated reason is that an interrupted audit should not lose its findings, and the practical effect is that the working directory fills up with files during a run.

Installation¶

The README documents a one-line install through the skills CLI:

npx skills add yoanbernabeu/supabase-pentest-skills

The documented variants cover the usual cases: --skill supabase-detect for a single skill, -g for a user-level install, --list to see the 24 names without installing, and --all -y for a non-interactive install suited to CI. For a Hermes profile the plain form above is the one to use, since the skills genuinely do reference each other and a partial install breaks the pipeline.

The README's recommended setup for a real audit is worth following because it is not obvious from the skills alone. Create a fresh directory per audit rather than running in a repository you care about, download the agent template into it, then launch the orchestrator:

mkdir my-security-audit
cd my-security-audit
curl -o CLAUDE.md https://raw.githubusercontent.com/yoanbernabeu/supabase-pentest-skills/main/templates/CLAUDE.md

/supabase-pentest

The template is a checklist plus logging rules rather than code, and the README is explicit that it is optimised for Claude Code. The slash command form is a Claude Code convention; on another host the equivalent is to invoke supabase-pentest by name and give it the target URL, which is what the orchestrator expects either way. The README also suggests Plan Mode where the host supports it, so that the audit plan is reviewable before any request is sent.

What It Provides¶

Skill	Installs	Use For
supabase-audit-rls	1,159	Testing row level security against unauthenticated access, cross-user access, filter bypass, join exploitation and RPC bypass.
supabase-audit-functions	962	Discovering edge functions and testing their authentication requirement, input validation and error disclosure.
supabase-pentest	712	Orchestrating the full audit phase by phase, with ownership confirmation and checkpoints between phases.
supabase-audit-auth-config	564	Reading GoTrue settings: providers, signup state, email confirmation, password policy, rate limits and CORS origins.
supabase-audit-rpc	538	Enumerating exposed Postgres functions and flagging `SECURITY DEFINER` paths that ignore the caller and bypass RLS.
supabase-audit-realtime	534	Testing Realtime channels for unauthorised subscriptions and change streams that leak rows.
supabase-help	516	Reference for all 24 skills: commands, severity levels and the common audit workflows.
supabase-report	506	Generating the Markdown report: executive summary, security score, severity sections and remediation plan.
supabase-audit-tables-read	501	Verifying actual row access on exposed tables in quick, sample or count-only mode.
supabase-audit-buckets-public	498	Finding public storage buckets and judging whether their contents belong in public storage.
supabase-audit-auth-users	496	Testing signup, login, recovery and OTP endpoints for user enumeration, including timing differences.
supabase-audit-tables-list	494	Enumerating tables exposed through PostgREST and classifying them by likely risk.
supabase-extract-anon-key	492	Pulling the public anon key out of client code and validating its decoded claims.
supabase-detect	491	Establishing whether a site uses Supabase at all, from client code and endpoint patterns.
supabase-extract-service-key	491	Checking client code for a leaked service_role key, which is a P0 finding on its own.
supabase-extract-db-string	490	Looking for exposed Postgres connection strings, which imply direct database access.
supabase-audit-buckets-list	488	Listing storage buckets and their configuration as the storage attack surface.
supabase-audit-buckets-read	486	Attempting to list and read bucket objects to confirm whether access control holds.
supabase-audit-auth-signup	485	Testing whether signup is open and what abuse vectors an open registration flow creates.
supabase-report-compare	481	Diffing two audit reports to show what was fixed and what is new.

The remaining 5 indexed listings range from 1 to 478 installs.

The counts are unusually flat, which is a good sign of a pack installed as a set rather than as individual picks: nineteen skills sit between 481 and 962, and the only outlier above that band is supabase-audit-rls at 1,159, which makes sense as the single most useful skill in the set for anyone whose Supabase exposure is data access. On the index side, the one listing not in the table above is a bare supabase entry at 1 install with no directory in the tree.

Why This Matters for Hermes Agents¶

A Supabase audit is a good fit for an agent and a bad fit for a busy developer. It is long, repetitive, ordered, and every step produces a document, which is precisely the shape of work that gets skipped when a human is doing it under time pressure. Twenty-four skills with an orchestrator turn it into a runbook the agent can execute and, because of the progressive-write convention, one that survives an interruption.

The pack also encodes judgement that is easy to get wrong. supabase-audit-rls does not stop at "is RLS enabled"; it names missing policies, overly permissive policies, missing operations, and inconsistent USING versus WITH CHECK clauses as distinct P0 and P1 cases, because a table with RLS enabled and a permissive select policy looks fine in the dashboard and is wide open in practice. supabase-audit-rpc does the same for SECURITY DEFINER functions, which are the classic Supabase escalation path.

The reporting half is the part that makes the audit useful outside the room. A severity vocabulary of P0, P1 and P2, a security score, a remediation plan and a report-comparison skill means the output is something a team can be held to, rather than a list of interesting responses. For an operator running this quarterly, supabase-report-compare is arguably the most valuable skill in the pack, since it answers the question that matters after the first audit.

The counterweight is that this is an offensive tool with network access. Nothing in it is dangerous against a system you own, and everything in it is dangerous against one you do not. The pack requires ownership confirmation before an audit starts, and that confirmation is the only thing separating a security review from unauthorised testing, so the operator has to enforce it rather than the skill.

Usage¶

You say	What happens
"Does this site use Supabase at all"	`supabase-detect` looks for client code and endpoint patterns, then reports either the project reference or a negative result.
"Audit the RLS policies on my Supabase project"	`supabase-audit-rls` tests unauthenticated access, cross-user access, filter bypass and join exploitation, and reports per-table status with fixes.
"Is the service role key leaked anywhere in the bundle"	`supabase-extract-service-key` scans client code and reports a P0 if the key is present, without printing it.
"Find the public storage buckets and tell me what is in them"	`supabase-audit-buckets-public` lists public buckets, samples their contents, and flags sensitive filenames and backups.
"Can anonymous users stream the users table over Realtime"	`supabase-audit-realtime` checks whether Postgres changes stream with the anon key, which is the Realtime form of an RLS gap.
"Run the whole audit and write me a report"	`supabase-pentest` runs the phases with checkpoints, and `supabase-report` produces the Markdown report with severities and remediation.
"Did we fix the issues from last month"	`supabase-report-compare` diffs the old and new reports and separates resolved findings from new ones.

Verification¶

The raw path for the RLS skill returned HTTP 200 on branch main when this guide was written on 2026-11-01:

curl -sL -o /dev/null -w "%{http_code} supabase-audit-rls\n" \
  https://raw.githubusercontent.com/yoanbernabeu/supabase-pentest-skills/main/skills/audit-api/supabase-audit-rls/SKILL.md

Expect 200. After a shallow clone, confirm that all 24 arrived and that they are grouped rather than flat, since the category folders are how the pack is meant to be read:

git clone --depth 1 https://github.com/yoanbernabeu/supabase-pentest-skills.git /tmp/supabase-pentest-skills
ls /tmp/supabase-pentest-skills/skills
find /tmp/supabase-pentest-skills/skills -name SKILL.md | wc -l

The count should be 24, and the listing should show the ten group folders: audit-api, audit-auth, audit-functions, audit-realtime, audit-storage, detection, evidence, extraction, orchestration and report. If the skills land flat after installation, delegation between them still works by name, but the phase ordering that supabase-pentest relies on is harder to follow.

Security¶

skills.sh verdicts for sampled skills (verified 2026-11-01) - re-check the security pages on skills.sh before production use:

Skill	Gen Agent Trust Hub	Socket	Snyk
supabase-audit-rls	Pass	Pass	Warn
supabase-audit-functions	Pass	Pass	Warn
supabase-pentest	Pass	Warn	Warn

Start with the obvious: this is a penetration testing toolkit, so every verdict should be read as "does it do what it claims" rather than "is it safe to point at anything". The skills send crafted HTTP requests to a live target, extract JWTs and keys from that target, and write what they find into the working directory. The Snyk Warn with code W011 across all three sampled listings, plus a Socket Warn on the orchestrator, is consistent with a pack whose job is to reach out and probe. None of that is a defect. It is the design.

The real control is authorisation, and the pack knows it. The orchestrator requires an ownership confirmation before the first phase, the README states that the skills are for internal self-assessment by authorised teams, and supabase-audit-tables-read documents itself as read-only. Those are the guardrails to verify are intact before you run anything, because an agent holding these skills and a URL will otherwise be happy to proceed.

Two gaps between the README's security model and the actual skills deserve naming. The README says operations are read-only, but supabase-audit-authenticated creates a test user with explicit permission to compare authenticated and anonymous access, which is a write to the target's auth system and needs to be a deliberate decision rather than a default. And supabase-audit-tables-read runs live SELECT queries that return real rows, which means the evidence directory will contain sampled personal data by construction, and may contain secrets such as webhook keys or a leaked service key. Treat .sb-pentest-evidence/ and .sb-pentest-context.json as sensitive output: do not commit them, do not attach them to a ticket, and delete them when the report is written.

Finally, scope the run to the environment you mean to test. The skills take a URL, and nothing in them distinguishes production from staging, so decide that before the prompt rather than discovering it from the report.

Integration with CorpusIQ¶

CorpusIQ is the connector layer that lets AI assistants read the systems a business already runs on - accounting, payments, CRM, email, files and analytics - and answer with the source named. It is read-only by design: it retrieves data and never writes to, or acts in, a connected system, which is what makes it safe to point at live accounts.

This page is part of the CorpusIQ directory, the reference we maintain for the MCP server and agent-skill ecosystem. Run alongside CorpusIQ, a third-party server like this one can be combined with a company's own business data in a single answer.

See what CorpusIQ connects

Limitations¶

Snapshot data, verified 2026-11-01: 13,050 combined installs across 25 indexed listings; 73 GitHub stars; MIT; last pushed 2026-01-31. Counts drift over time.
The index lists 25 skills and the tree holds 24 directories. The extra listing is a bare supabase entry at 1 install with no counterpart in the tree, so it cannot be installed.
Last pushed 2026-01-31, roughly nine months before this snapshot, and the pack has no dependency or build step that would show up as activity. Age is not evidence of breakage here, but it does mean the Supabase surfaces it tests have moved since.
The instructions are written for Claude Code: Plan Mode via EnterPlanMode, slash commands such as /supabase-pentest, and a CLAUDE.md template. A Hermes operator has to map those onto plain skill invocations and should not expect the template's checklist to be enforced automatically.
The README's read-only claim does not hold for the whole pack. supabase-audit-authenticated creates a test user, and every table-read and bucket-read skill returns real data from the target.
The evidence directory is a liability as well as an asset: it collects sampled PII, request logs and possibly extracted keys, which makes it something to handle and dispose of deliberately.
Test coverage is bounded by the skill list. There is no skill for database migrations, no check for Postgres extensions or network-level exposure, and the report format is Markdown only.

Skills Catalog | Skills Marketplace

Pro Tips¶

Write the ownership confirmation into the prompt, not just the conversation. "I own this project and authorise testing of staging.example.com" in the same message as the target URL is a better control than a confirmation the agent asks for and then accepts from itself.
Run each audit in a fresh directory. The context file, the audit log and the evidence tree are all relative paths, so two audits in one directory will interleave and the report will mix targets.
Start with supabase-detect and supabase-extract-anon-key even on a full run, because the anon key is what every later skill needs and an audit that discovers halfway through that the site uses a different backend has wasted a phase.
Point supabase-audit-rls at the tables that matter rather than all of them. It reports per table, and a focused run on users, orders and anything with a settings or api_keys shape produces a more readable report than a full sweep.
Keep supabase-report-compare in the loop after the first audit. The value of a quarterly audit is the delta, and a report nobody diffs is a report nobody acts on.

← Skills Catalog | Skills Marketplace → Powered by CorpusIQ