🛡️ Database Sentinel

A Claude Skill that audits your database backends for security vulnerabilities.

Drop it into Claude Code, Cursor, or any Claude-powered environment. Say "audit my database" and get a comprehensive security report with exact fix code — in minutes, not days.

170+ Lovable apps were breached. 20.1M rows were exposed across YC startups. ~87,000 MongoDB instances were left vulnerable to MongoBleed (CVE-2025-14847, CISA KEV). 1.8M Firebase passwords leaked in a single 2025 incident. 45% of AI-generated code introduces OWASP Top 10 vulnerabilities. Database Sentinel tests whether your security configuration actually works — not just whether it's present.

What it does

Database Sentinel performs a 7-step security audit on whichever backend(s) your project uses:

Detects which backends you're using (Supabase, Firebase, MongoDB, self-hosted Postgres / MySQL)
Scans your codebase for exposed credentials, hardcoded keys, secrets in git
Introspects each backend — schema, policies, rules, users, roles, configuration
Matches findings against backend-specific anti-pattern catalogs sourced from CVEs, breach reports, CIS benchmarks, and 2025–2026 vibe-coding research
Dynamically probes with safe primitives (tx=rollback, canary collections, opt-in MongoBleed detector)
Generates a scored security report with plain-English explanations and concrete attacker scenarios
Produces exact fix code — SQL DDL, rule files, config diffs, Terraform — copy, paste, done

Cross-backend reasoning catches issues that single-backend scanners miss (e.g., a Firebase Auth UID trusted by a Postgres API without JWT verification).

Status

Phase	Backend	Status
1	Supabase	✅ shipped
2	MongoDB (self-hosted + Atlas)	✅ shipped
3	Firebase (Firestore / RTDB / Storage / Functions / Remote Config)	🚧 planned
4	PostgreSQL (self-hosted, including pgBouncer)	🚧 planned
5	MySQL (self-hosted)	🚧 planned
6	Cross-backend interaction analysis	🚧 planned
7	Distribution + polish	🚧 planned

Database Sentinel was previously Supabase Sentinel (single-backend). The rename happened during Phase 1 of the multi-backend expansion. A backwards-compat shim at compat/supabase-sentinel/ preserves the old skill name through at least the next minor release — existing users see no regression.

Quick start

Option 1: Claude Code / Cursor

Clone the skill into your project's skills directory, or a central one:

git clone https://github.com/Farenhytee/database-sentinel.git ~/claude-skills/database-sentinel

Then ask Claude:

Audit my database

Database Sentinel will detect which backend(s) your project uses, run the relevant audits, and produce a unified report. If multiple backends are present (Firebase Auth + Postgres data, etc.), the report includes a cross-backend interactions section once Phase 6 lands.

Option 2: Single-backend invocation

If you only want to audit a specific backend, ask explicitly:

Audit my Supabase project
Audit my MongoDB instance

The dispatcher narrows the scope.

Option 3: Manual (any AI assistant)

Copy the contents of SKILL.md plus the relevant backends/<name>/workflow.md into your system prompt. Walk through the 7 steps with your credentials.

What it catches

Supabase (Phase 1) — 27 patterns

Severity	Pattern	What
🔴 CRITICAL	`SB-001` `RLS_DISABLED`	Tables without Row-Level Security — fully exposed to the internet
🔴 CRITICAL	`SB-002` `SERVICE_ROLE_EXPOSED`	service_role key in frontend code — bypasses ALL security
🔴 CRITICAL	`SB-003` `POLICIES_BUT_NO_RLS`	Policies written but RLS never enabled — false security
🔴 CRITICAL	`SB-005` `WRITE_USING_TRUE`	INSERT/UPDATE/DELETE with `USING(true)` — anyone can modify
🟠 HIGH	`SB-006` `USING_TRUE_SELECT`	All rows readable by anonymous users on sensitive tables
🟠 HIGH	`SB-007` `VIEW_NO_SECURITY_INVOKER`	Views bypass RLS, run as superuser
🟠 HIGH	`SB-008` `SECURITY_DEFINER_EXPOSED`	Functions in public schema bypass RLS, callable via API
🟠 HIGH	`SB-009` `USER_METADATA_IN_POLICY`	Policies reference user-modifiable metadata — privilege escalation
🟠 HIGH	`SB-010` `UPDATE_NO_WITHCHECK`	UPDATE policies without WITH CHECK — mass assignment risk
🟠 HIGH	`SB-011` `GHOST_AUTH`	Unconfirmed email signups grant authenticated sessions
🟠 HIGH	`SB-012` `STORAGE_NO_RLS`	Storage bucket missing access control policies
🟠 HIGH	`SB-013` `JWT_SECRET_EXPOSED`	JWT signing secret leaked — can forge any user's token
🟡 MEDIUM	+ 15 more patterns	See `backends/supabase/anti-patterns.md`

MongoDB (Phase 2) — 20 patterns

Severity	Pattern	What
🔴 CRITICAL	`MG-SH-001` MongoBleed (CVE-2025-14847, CISA KEV)	Pre-auth heap memory disclosure via crafted compressed packet. ~87K instances exposed at disclosure.
🔴 CRITICAL	`MG-SH-002` Auth disabled	mongod running with no authentication — Meow ransomware attack surface
🔴 CRITICAL	`MG-SH-003` Internet-bound mongod	`--bind_ip_all` + 27017 reachable — paired with `MG-SH-002` for total compromise
🔴 CRITICAL	`MG-AT-001` Atlas allowlist `0.0.0.0/0`	Atlas cluster reachable from anywhere on the internet
🟠 HIGH	`MG-SH-004` localhost auth bypass + container exec	`enableLocalhostAuthBypass` true + `docker exec` access
🟠 HIGH	`MG-SH-005` Server-side JS enabled	`$where` / `$function` / `mapReduce` reachable — NoSQL-RCE surface
🟠 HIGH	`MG-SH-006` TLS not required	Plaintext traffic on the wire
🟠 HIGH	`MG-SH-007` Privileged role on app user	App connects as `root` / `dbAdminAnyDatabase` etc.
🟠 HIGH	`MG-SH-008` Self-modifiable role document	`findByIdAndUpdate(id, req.body)` + no validator + role field
🟠 HIGH	`MG-AT-002` Atlas Function as DB pass-through	NoSQL injection over HTTPS — proliferated post-Data-API-deprecation
🟠 HIGH	`MG-AT-003` Atlas Data API still in code	Deprecated Sept 30 2025; broken AND likely rotated to less-audited Functions
🟡 MEDIUM	`MG-SH-009` Mongoose < 8.9.5	CVE-2024-53900 / CVE-2025-23061 — populate-match `$where` injection
🟡 MEDIUM	+ 8 more patterns	See `backends/mongodb/anti-patterns.md`

The MongoBleed network probe (backends/mongodb/mongobleed-probe.md) ships a single-packet detector that confirms exploitability at runtime — verified against mongo:7.0.20 (vulnerable) and mongo:7.0.28 (patched). It's read-only, gated behind two opt-in confirmations, and never extracts content.

Example output

╔════════════════════════════════════════════════════════╗
║                  SENTINEL SECURITY AUDIT               ║
╠════════════════════════════════════════════════════════╣
║  Backends:   supabase, mongodb                         ║
║  Scanned:    2026-04-30 14:30 UTC                      ║
║  Score:      0/100 🔴                                  ║
║  Summary:    2 backends, 8 findings (3C / 4H / 1M)     ║
╚════════════════════════════════════════════════════════╝

─────────────────────────────────────────────────────────
  Supabase                                       35/100 🔴
─────────────────────────────────────────────────────────

🔴 CRITICAL — public.users: RLS Disabled                  [SB-001]

  Risk:     Anyone on the internet can read your entire users table.
  Attack:   Open browser DevTools → copy anon key → curl the API → dump
            all emails, names, and metadata.
  Proof:    curl returns [{"id":"...","email":"[email protected]",...}]
  Source:   CVE-2025-48757 / Splinter 0013_rls_disabled_in_public

  Fix:
  ALTER TABLE public.users ENABLE ROW LEVEL SECURITY;

Most Popular

database-sentinel