Forem: Victor Yrazusta Ibarra

Introducing Firebomb: Open Source Firebase Penetration Testing

Victor Yrazusta Ibarra — Sat, 10 Jan 2026 15:45:50 +0000

We're releasing Firebomb, our open source penetration testing tool for Firebase applications. It's the same tool powering our automated Firebase security scanning at ModernPentest.

The Firebase Security Problem

Firebase makes it incredibly easy to build applications. Point your client SDK at Google's infrastructure, write some security rules, and you have a scalable backend in minutes.

But that ease of development has created an epidemic of insecure applications:

916 Firebase websites exposed 125 million user records in 2024
31% of Firebase apps have exploitable security rules
Most developers deploy with test mode rules and never update them

Generic security scanners don't understand Firebase's unique architecture—Firestore rules, RTDB permissions, Cloud Storage ACLs, the relationship between client SDKs and security rules. They miss the vulnerabilities that actually matter.

Firebomb changes that.

What Firebomb Does

Firebomb is a comprehensive security testing framework specifically for Firebase. It automates the complete penetration testing workflow:

1. Configuration Discovery

Firebomb automatically extracts Firebase credentials from web applications—no manual copying needed:

# Discover from a live application
uv run firebomb discover --url https://target-app.com

# Deep recursive crawl (follows all JS files)
uv run firebomb discover --url https://target-app.com --recursive

# Validate discovered configs against Firebase APIs
uv run firebomb discover --url https://target-app.com --recursive --validate

# Parse from local files
uv run firebomb discover --file bundle.js
uv run firebomb discover --har traffic.har

It finds credentials hidden in:

Inline JavaScript and HTML
Bundled and minified scripts (webpack, Vite, esbuild)
Code-split chunks and lazy-loaded modules
Next.js/React/Vue/Angular build artifacts
Source maps (extracts original source code)
Environment variables (NEXT_PUBLIC_FIREBASE_*, VITE_FIREBASE_*, etc.)

2. Proactive Discovery (No Credentials Needed)

Firebomb can discover Firebase projects without extracting credentials first:

# Probe by project ID
uv run firebomb probe --project-id suspected-project

# Generate and probe from company name
uv run firebomb probe --name "Acme Corp"

# Discover from domain
uv run firebomb probe --domain acme.com

This uses DNS enumeration and direct API probing to find Firebase projects and check for misconfigurations—useful when you suspect Firebase usage but can't find the config.

3. Resource Enumeration

Once configured, Firebomb discovers all accessible Firebase resources:

uv run firebomb enum --output enumeration.json

This reveals:

Firestore: Collections, document counts, accessible fields
Realtime Database: Paths, data structure, accessible nodes
Cloud Storage: Buckets, file listings, ACL configurations
Cloud Functions: Endpoints, authentication requirements
Authentication: Enabled providers, configuration settings

4. Security Testing

The core of Firebomb—automated vulnerability testing across all Firebase services:

uv run firebomb test --output findings.json

Firestore Testing:

Public read/write access detection
Missing authentication checks
Cross-user data access vulnerabilities
Document-level permission gaps

Realtime Database Testing:

Public path vulnerabilities
Wildcard permission issues
Root-level database exposure
Path traversal risks

Cloud Storage Testing:

Publicly readable/writable buckets
ACL misconfigurations
Unauthorized file operations

Cloud Functions Testing:

Unauthenticated function access
CORS misconfigurations
Missing input validation

Authentication Testing:

Anonymous authentication enabled
Email verification requirements
Password policy strength

Sample Output:

┌─────────────────────────────────────────────────────────────────┐
│ Security Testing Results                                        │
├─────────────────────────────────────────────────────────────────┤
│ Firestore: users                                                │
│   ✗ Collection publicly readable without authentication         │
│   Documents exposed: 1,847                                      │
│   Severity: CRITICAL                                            │
├─────────────────────────────────────────────────────────────────┤
│ Firestore: posts                                                │
│   ✓ Proper authentication required                              │
│   ✓ User-scoped access enforced                                 │
├─────────────────────────────────────────────────────────────────┤
│ Cloud Storage: user-uploads                                     │
│   ✗ Bucket publicly writable                                    │
│   Risk: Arbitrary file upload/malware hosting                   │
│   Severity: CRITICAL                                            │
├─────────────────────────────────────────────────────────────────┤
│ Authentication                                                  │
│   ⚠ Anonymous authentication enabled                            │
│   Risk: Unlimited account creation, resource abuse              │
│   Severity: MEDIUM                                              │
└─────────────────────────────────────────────────────────────────┘

5. Authenticated Testing

Test how permissions differ between anonymous and authenticated users:

# Auto-generate email with verification (recommended)
uv run firebomb signup --verify-email

# Or use manual email/password
uv run firebomb signup --email tester@example.com --password SecurePass123!

# Run tests with authentication
uv run firebomb test --auth
uv run firebomb enum --auth

This reveals privilege escalation vulnerabilities—resources that should require authentication but don't, or resources accessible to any authenticated user instead of just the owner.

6. Data Extraction

Query specific collections or paths:

# Query specific Firestore collection
uv run firebomb query --collection users --output users.json

# Query RTDB path
uv run firebomb query --path /messages --output messages.json

# Export with limits
uv run firebomb query --collection orders --limit 100 --output sample.json

7. Bulk Data Dump

Export all accessible data for evidence collection:

# Dump all accessible Firebase data
uv run firebomb dump --output evidence.json

# Dump with authentication
uv run firebomb dump --auth --output auth-evidence.json

# Dump specific collections only
uv run firebomb dump --firestore-only --collections users,orders --output data.json

# Limit documents per collection
uv run firebomb dump --limit 500 --output sample.json

The dump command fetches actual document contents from Firestore, full data trees from RTDB, and file listings from Cloud Storage.

8. Professional Reports

Generate stakeholder-ready security assessments:

# HTML report for executives
uv run firebomb report --format html --output assessment.html

# JSON report for developers
uv run firebomb report --format json --output findings.json

Reports include:

Executive summary with risk assessment
Detailed findings with severity classification
CWE and OWASP mapping
Remediation guidance with code examples
Evidence and proof of concept

Key Features

Smart Credential & Session Management

Firebomb caches discovered configurations and authentication sessions:

# Discover and cache (default behavior)
uv run firebomb discover --url https://app.com

# Later: credentials auto-loaded
uv run firebomb enum
uv run firebomb test

# View cached configurations
uv run firebomb cached

# View cached sessions
uv run firebomb cached --sessions

# Remove specific project
uv run firebomb cached --remove my-project

# Clear all cached data
uv run firebomb cached --clear

Comprehensive Service Coverage

Unlike generic scanners, Firebomb understands all Firebase services:

Service	What Firebomb Tests
Firestore	Rules, collection access, cross-user data leakage
RTDB	Permissions, path traversal, wildcard rules
Storage	Bucket ACLs, file type restrictions, public access
Functions	Authentication, CORS, input validation
Auth	Provider config, anonymous auth, MFA settings
Discovery	DNS probing, API probing, framework detection

Severity Classification

Findings are categorized by actual risk:

CRITICAL: Complete data exposure, write access to all data
HIGH: Significant data leakage, unauthorized access
MEDIUM: Configuration weaknesses, potential abuse vectors
LOW: Best practice violations, minor issues
INFO: Documentation, recommendations

Remediation Guidance

Every finding includes specific fix instructions:

┌─────────────────────────────────────────────────────────────────┐
│ Finding: Firestore collection 'users' publicly readable         │
├─────────────────────────────────────────────────────────────────┤
│ Severity: CRITICAL                                              │
│ CWE: CWE-284 (Improper Access Control)                          │
│ OWASP: A01:2021 - Broken Access Control                         │
├─────────────────────────────────────────────────────────────────┤
│ Current Rules:                                                  │
│   match /users/{userId} {                                       │
│     allow read: if true;                                        │
│   }                                                             │
├─────────────────────────────────────────────────────────────────┤
│ Recommended Fix:                                                │
│   match /users/{userId} {                                       │
│     allow read: if request.auth != null                         │
│       && request.auth.uid == userId;                            │
│   }                                                             │
└─────────────────────────────────────────────────────────────────┘

Advanced Capabilities

Framework Auto-Detection

Firebomb automatically detects and optimizes for modern frameworks:

Next.js: Parses _buildManifest.js, follows chunk patterns
React: Handles Create React App and custom builds
Vue/Nuxt: Detects Vue-specific bundle patterns
Vite: Extracts from Vite build outputs
Angular: Supports Angular CLI builds

Deep JavaScript Analysis

Recursive crawling with configurable depth and file limits
Webpack chunk extraction and following
Source map parsing for original source code
Environment variable pattern detection (NEXT_PUBLIC_*, VITE_*, etc.)
Minified code correlation for scattered config values

Installation

Firebomb requires Python 3.11+ and uses uv for dependency management:

# Clone the repository
git clone https://github.com/ModernPentest/firebomb.git
cd firebomb

# Run with uv (handles dependencies automatically)
uv run firebomb --help

Example Workflow

Here's a complete security assessment workflow:

# 1. Discover Firebase configuration with validation
uv run firebomb discover --url https://target-app.com --recursive --validate

# 2. Or probe by company name if config not found
uv run firebomb probe --name "Target Company"

# 3. Enumerate all resources
uv run firebomb enum --output enum.json

# 4. Run security tests
uv run firebomb test --output findings.json

# 5. Create test user with auto-verification
uv run firebomb signup --verify-email

# 6. Test with authentication
uv run firebomb test --auth --output auth-findings.json

# 7. Dump evidence from vulnerable resources
uv run firebomb dump --limit 100 --output evidence.json

# 8. Generate professional report
uv run firebomb report --format html --output security-assessment.html

Responsible Use

Firebomb is designed for authorized security testing only. Always ensure you have:

Written authorization from the Firebase project owner
Permission to test the specific project
Understanding of applicable laws

Never use this tool against applications you don't own or have explicit permission to test.

How It Powers ModernPentest

Firebomb is the foundation of our Firebase security scanning at ModernPentest. Our AI agents use Firebomb as their primary tool for:

Automated Firestore rules analysis
RTDB permission auditing
Cloud Storage ACL testing
Continuous monitoring for configuration drift

ModernPentest adds:

AI-powered analysis - Agents interpret findings and prioritize by actual business risk
Continuous scanning - Automated weekly/daily scans catch regressions
SOC 2 reports - Auditor-ready documentation generated automatically
Remediation guidance - Specific fix recommendations tailored to your codebase

For manual control, use Firebomb directly. For automated, continuous security with compliance reporting, try ModernPentest.

Get Started

The code is available on GitHub:

github.com/ModernPentest/firebomb

Star the repo, try it on your Firebase projects, and let us know what you find. We welcome contributions, bug reports, and feature requests.

For a deep dive into Firebase security best practices, check out our guide: Securing Firebase in Production.

Firebomb is part of our commitment to open source security tooling. Follow us for more tools and guides on securing modern web applications.

Introducing Supabomb: Open Source Supabase Penetration Testing

Victor Yrazusta Ibarra — Mon, 08 Dec 2025 19:20:36 +0000

We're excited to announce the open source release of Supabomb, our specialized penetration testing tool for Supabase applications. It's the same tool that powers our automated Supabase security scanning at ModernPentest.

Why We Built Supabomb

Supabase has become the go-to backend for modern web applications. Its PostgreSQL foundation, real-time capabilities, and developer-friendly APIs make it incredibly powerful. But with that power comes security complexity.

After auditing dozens of Supabase applications, we noticed the same patterns repeatedly:

23% of apps have exploitable RLS policies - Missing or misconfigured Row-Level Security is shockingly common
Most security tools miss Supabase-specific issues - Generic scanners don't understand PostgREST or RLS
Manual testing is tedious and incomplete - Checking every table and policy by hand takes hours

We built Supabomb to solve these problems. It's fast, thorough, and specifically designed for Supabase's unique architecture.

What Supabomb Does

Supabomb automates the entire Supabase security assessment workflow:

1. Credential Discovery

No need to manually copy API keys from your frontend code. Supabomb automatically discovers Supabase credentials from:

Web application URLs (parses HTML and JavaScript)
JavaScript bundles (including code-split and lazy-loaded modules)
HAR files from network traffic
Deep crawling with Katana integration

# Discover credentials from a live application
uv run supabomb discover --url https://your-app.com

# Deep discovery with JavaScript execution
uv run supabomb discover --url https://your-app.com --katana

Sample output:

Crawling with Katana: https://demo-saas.example.com/
Max JS files: 50, Timeout: 120s

✓ Supabase instance found!
╭───────────────────┬───────────────────────────────────────────────────────╮
│ Project Reference │ abcdefghijklmnopqrst                                  │
│ URL               │ https://abcdefghijklmnopqrst.supabase.co              │
│ Anon Key          │ eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzd... │
│ Source            │ Katana crawl of https://demo-saas.example.com/        │
│ Edge Functions    │ 4 discovered                                          │
╰───────────────────┴───────────────────────────────────────────────────────╯

Discovered Edge Functions:
╭─────┬─────────────────────────┬─────────────────────────────────────────────┬─────────────────────────────────────────────────────────────────╮
│ #   │ Function Name           │ Arguments                                   │ Example                                                         │
├─────┼─────────────────────────┼─────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────┤
│ 1   │ create-checkout-session │ plan=d, billing_period=m, additional_use... │ functions.invoke("create-checkout-session",{body:{plan:d,bil... │
│ 2   │ get-invoices            │ customerId=a, limit=20                      │ functions.invoke("get-invoices",{body:{customerId:a.stripe_c... │
│ 3   │ send-notification       │ userId=u, message=m, channel=c              │ functions.invoke("send-notification",{body:{userId:u,message... │
│ 4   │ generate-report         │ reportType=t, startDate=s, endDate=e        │ functions.invoke("generate-report",{body:{reportType:t,start... │
╰─────┴─────────────────────────┴─────────────────────────────────────────────┴─────────────────────────────────────────────────────────────────╯

💾 Credentials saved to .supabomb.json

2. Resource Enumeration

Once credentials are discovered, Supabomb enumerates everything accessible:

uv run supabomb enum

Sample output:


📋 Using cached credentials for abcdefghijklmnopqrst

Enumerating Supabase instance: abcdefghijklmnopqrst
✓ Connection successful

Tables:
╭─────────────────────┬──────┬─────────┬───────────╮
│ Name                │ Read │ Columns │ Anon Rows │
├─────────────────────┼──────┼─────────┼───────────┤
│ users               │ ✓    │ 12      │ 1,847     │
│ profiles            │ ✓    │ 8       │ 1,847     │
│ organizations       │ ✓    │ 6       │ 423       │
│ projects            │ ✓    │ 14      │ 2,156     │
│ tasks               │ ✓    │ 18      │ 15,432    │
│ comments            │ ✓    │ 7       │ 48,291    │
│ attachments         │ ✓    │ 9       │ 8,734     │
│ notifications       │ ✗    │ 11      │ N/A       │
│ api_keys            │ ✗    │ 8       │ N/A       │
│ audit_logs          │ ✗    │ 15      │ N/A       │
│ billing_info        │ ✓    │ 10      │ 423       │
│ subscriptions       │ ✓    │ 12      │ 398       │
│ invitations         │ ✓    │ 7       │ 156       │
│ webhooks            │ ✗    │ 9       │ N/A       │
│ settings            │ ✓    │ 5       │ 423       │
╰─────────────────────┴──────┴─────────┴───────────╯

RPC Functions:
╭─────────────────────────────┬────────────┬────────────╮
│ Name                        │ Accessible │ Parameters │
├─────────────────────────────┼────────────┼────────────┤
│ get_user_projects           │ ✓          │ args       │
│ get_org_members             │ ✓          │ args       │
│ admin_list_users            │ ✓          │ args       │
│ admin_delete_user           │ ✗          │ args       │
│ get_current_user_role       │ ✓          │ args       │
│ is_admin                    │ ✓          │ args       │
│ update_user_permissions     │ ✗          │ args       │
│ generate_api_key            │ ✗          │ args       │
│ validate_invitation         │ ✗          │ args       │
│ cleanup_expired_sessions    │ ✓          │ args       │
╰─────────────────────────────┴────────────┴────────────╯

This reveals:

All accessible database tables with column information
RPC (Remote Procedure Call) functions
Storage buckets
Row counts (anonymous vs. authenticated comparison)

3. Security Testing

The core of Supabomb - automated security testing that covers:

uv run supabomb test

What it tests:

RLS policy effectiveness on every table
Authentication configuration (is anonymous signup enabled?)
RPC function access control
Storage bucket permissions
Edge function JWT requirements

Sample output:


📋 Using cached credentials for abcdefghijklmnopqrst

Testing Supabase instance: abcdefghijklmnopqrst
✓ Connection successful

╭──────────────────────────────────────────────────────── Security Test Summary ────────────────────────────────────────────────────────────╮
│ Total Findings: 5                                                                                                                         │
│ Risk Score: 24                                                                                                                            │
│                                                                                                                                           │
│ Critical: 1                                                                                                                               │
│ High: 1                                                                                                                                   │
│ Medium: 2                                                                                                                                 │
│ Low: 1                                                                                                                                    │
│ Info: 0                                                                                                                                   │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Findings:

╭────────────────────────────────────────── 1. Table 'users' accessible without authentication ─────────────────────────────────────────────╮
│ Severity: CRITICAL                                                                                                                        │
│ Affected: Table: users (1,847 rows exposed)                                                                                               │
│                                                                                                                                           │
│ Description:                                                                                                                              │
│ The 'users' table can be read by unauthenticated users using the anonymous API key. This exposes sensitive user data including emails,    │
│ names, and profile information.                                                                                                           │
│                                                                                                                                           │
│ Recommendation:                                                                                                                           │
│ Add RLS policies to restrict access:                                                                                                      │
│ - CREATE POLICY "Users can view own profile" ON users FOR SELECT USING (auth.uid() = id);                                                 │
│ - Ensure RLS is enabled: ALTER TABLE users ENABLE ROW LEVEL SECURITY;                                                                     │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

╭───────────────────────────────────── 2. RPC function 'admin_list_users' accessible with anonymous key ────────────────────────────────────╮
│ Severity: HIGH                                                                                                                            │
│ Affected: RPC: admin_list_users                                                                                                           │
│                                                                                                                                           │
│ Description:                                                                                                                              │
│ The RPC function 'admin_list_users' can be called with the anonymous API key. This admin function returns user data and should require    │
│ authentication and admin role verification.                                                                                               │
│                                                                                                                                           │
│ Recommendation:                                                                                                                           │
│ Add authentication check at the start of the function:                                                                                    │
│ - IF auth.uid() IS NULL THEN RAISE EXCEPTION 'Not authenticated';                                                                         │
│ - Verify admin role before returning data                                                                                                 │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

╭─────────────────────────────────────────────── 3. Anonymous signup is enabled ────────────────────────────────────────────────────────────╮
│ Severity: MEDIUM                                                                                                                          │
│ Affected: Auth API                                                                                                                        │
│                                                                                                                                           │
│ Description:                                                                                                                              │
│ The Supabase instance allows anonymous users to create accounts. This may be intentional, but could lead to abuse if not properly         │
│ configured with email confirmation and rate limiting.                                                                                     │
│                                                                                                                                           │
│ Recommendation:                                                                                                                           │
│ Review signup configuration. Consider:                                                                                                    │
│ - Enabling email confirmation                                                                                                             │
│ - Implementing rate limiting                                                                                                              │
│ - Adding CAPTCHA protection                                                                                                               │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

╭────────────────────────────────────────── 4. RPC function 'is_admin' accessible with anonymous key ───────────────────────────────────────╮
│ Severity: MEDIUM                                                                                                                          │
│ Affected: RPC: is_admin                                                                                                                   │
│                                                                                                                                           │
│ Description:                                                                                                                              │
│ The RPC function 'is_admin' can be called with the anonymous API key. While it only returns a boolean, it could be used to enumerate      │
│ admin users by testing different user IDs.                                                                                                │
│                                                                                                                                           │
│ Recommendation:                                                                                                                           │
│ Review the function's logic and ensure it only checks the current authenticated user's role.                                              │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

╭─────────────────────────────────────────────── 5. Storage bucket 'avatars' is public ─────────────────────────────────────────────────────╮
│ Severity: LOW                                                                                                                             │
│ Affected: Storage: avatars                                                                                                                │
│                                                                                                                                           │
│ Description:                                                                                                                              │
│ The 'avatars' storage bucket allows public read access. This is common for profile pictures but verify no sensitive files are stored.     │
│                                                                                                                                           │
│ Recommendation:                                                                                                                           │
│ Confirm this is intentional and implement upload restrictions to prevent abuse.                                                           │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

4. Write Permission Testing

Beyond read access, Supabomb tests if data can be modified:

uv run supabomb test-write

Sample output:

📋 Using cached credentials for abcdefghijklmnopqrst

Testing write permissions: abcdefghijklmnopqrst
✓ Connection successful
Mode: anonymous

✓ Testing 15 table(s)

                                          Write Permission Test Results
╭───────────────────┬────────┬────────┬────────┬──────────────────────────────────────────────────────────────────╮
│ Table             │ INSERT │ UPDATE │ DELETE │ Details                                                          │
├───────────────────┼────────┼────────┼────────┼──────────────────────────────────────────────────────────────────┤
│ users             │ ✗      │ -      │ -      │ Insert denied by RLS: new row violates row-level security policy │
│ profiles          │ ✗      │ -      │ -      │ Insert denied by RLS: new row violates row-level security policy │
│ organizations     │ ✗      │ -      │ -      │ Insert denied by RLS: new row violates row-level security policy │
│ projects          │ ✗      │ -      │ -      │ Insert denied by RLS: new row violates row-level security policy │
│ tasks             │ ✓      │ ✓      │ ✗      │ INSERT and UPDATE allowed! Row created with id: 847291           │
│ comments          │ ✓      │ ✗      │ ✗      │ INSERT allowed! Row created with id: 159372                      │
│ attachments       │ ✗      │ -      │ -      │ Insert denied by RLS: new row violates row-level security policy │
│ notifications     │ ✗      │ -      │ -      │ Insert denied by RLS: permission denied for table notifications  │
│ api_keys          │ ✗      │ -      │ -      │ Insert denied by RLS: permission denied for table api_keys       │
│ audit_logs        │ ✗      │ -      │ -      │ Insert denied by RLS: permission denied for table audit_logs     │
│ billing_info      │ ✗      │ -      │ -      │ Insert denied by RLS: new row violates row-level security policy │
│ subscriptions     │ ✗      │ -      │ -      │ Insert denied by RLS: new row violates row-level security policy │
│ invitations       │ ⚠      │ -      │ -      │ Insert possible but needs crafted data: missing org_id reference │
│ webhooks          │ ✗      │ -      │ -      │ Insert denied by RLS: permission denied for table webhooks       │
│ settings          │ ✗      │ -      │ -      │ Insert denied by RLS: new row violates row-level security policy │
╰───────────────────┴────────┴────────┴────────┴──────────────────────────────────────────────────────────────────╯

Legend: ✓ = Allowed, ✗ = Denied (RLS), ⚠ = Possible with crafted data, - = Not tested

This intelligently:

Generates test data based on actual table schema
Respects referential integrity when testing
Distinguishes between RLS denials and validation errors
Automatically cleans up test data after testing

5. Authenticated Testing

Test how RLS policies differ between anonymous and authenticated users:

# Register a test user (with automatic email verification)
uv run supabomb signup --verify-email

# Subsequent commands automatically use cached auth session
uv run supabomb test
uv run supabomb query -t users

# Force anonymous access with --use-anon flag
uv run supabomb query -t users --use-anon

6. Data Export

Export accessible data for evidence collection:

# Query specific table to JSON
uv run supabomb query -t users -o users.json

# Export to CSV
uv run supabomb query -t users -o users.csv -f csv

# Dump all accessible tables
uv run supabomb dump -o ./evidence/

7. All-in-One Assessment

Run the complete workflow with a single command:

uv run supabomb all --url https://your-app.com -o report.json

This executes: discovery → registration → enumeration → data dump, generating a comprehensive JSON report.

Additional options:

# Include write permission testing
uv run supabomb all --url https://your-app.com -o report.json --test-write

# Use Katana for deep JavaScript crawling
uv run supabomb all --url https://your-app.com -o report.json --katana

Key Features That Set Supabomb Apart

Intelligent Credential Caching

Supabomb caches discovered credentials in ~/.supabomb.json. Once you've scanned an app, subsequent commands automatically use the cached credentials:

# First time: discover and cache
uv run supabomb discover --url https://app.com

# Later: just run commands (credentials auto-loaded)
uv run supabomb enum
uv run supabomb test

Manage cached credentials:

# List all cached credentials
uv run supabomb cached

# Remove a specific project
uv run supabomb cached --remove abcdefghij

# Clear all cached credentials
uv run supabomb cached --clear

Deep JavaScript Analysis

Many tools only scan inline scripts. Supabomb analyzes up to 50+ JavaScript files per scan, including:

Directly linked scripts
Dynamically imported modules
Code-split chunks
Lazy-loaded bundles
Next.js/React/Vue bundle formats

This catches credentials hidden in complex frontend builds.

Automatic Email Verification

When testing requires a verified account, Supabomb integrates with temporary email services:

uv run supabomb signup --verify-email

Sample output:

✓ Email verification required - using temporary email service
Created temporary email: xyz123@mail.tm

Registering user...
⏳ Account created, waiting for verification email...
✓ Verification email received!
✓ Email verified successfully!
✓ Login successful!

┌──────────────┬──────────────────────────────────────────┐
│ Property     │ Value                                    │
├──────────────┼──────────────────────────────────────────┤
│ User ID      │ 550e8400-e29b-41d4-a716-446655440000     │
│ Email        │ xyz123@mail.tm                           │
│ Role         │ authenticated                            │
└──────────────┴──────────────────────────────────────────┘

💾 Session saved to .supabomb.json

This automatically:

Creates a temporary email address
Registers with your Supabase project
Waits for the verification email
Clicks the verification link
Caches the authenticated session

No manual intervention needed.

Side-by-Side Access Comparison

Instantly see what's exposed to anonymous vs. authenticated users:

┌────────────────┬───────────┬───────────────┐
│ Table          │ Anon Rows │ Auth Rows     │
├────────────────┼───────────┼───────────────┤
│ public_posts   │ 150       │ 150           │
│ user_profiles  │ 1,234     │ 1,234  ⚠️     │
│ private_data   │ 0         │ 42            │
│ admin_logs     │ 0         │ 0             │
└────────────────┴───────────┴───────────────┘
⚠️ Warning: user_profiles accessible without auth

Edge Function Discovery

Unique to Supabomb: it extracts edge function invocations directly from JavaScript code and tests them:

uv run supabomb check-jwt -e send_email -e get_posts

Sample output:

Checking edge functions: abcdefghijklmnopqrst

┌─────────────────────────┬──────────────────┬──────────────────────────┬──────────────┐
│ Function Name           │ Requires JWT     │ Accessible with Anon Key │ Status Code  │
├─────────────────────────┼──────────────────┼──────────────────────────┼──────────────┤
│ create-checkout-session │ Yes              │ No                       │ 401          │
│ get-invoices            │ Yes              │ No                       │ 401          │
│ send-notification       │ No               │ Yes                      │ 200          │
│ generate-report         │ No               │ Yes                      │ 200          │
└─────────────────────────┴──────────────────┴──────────────────────────┴──────────────┘

This reveals which edge functions require JWT authentication and which are publicly accessible.

Installation

Supabomb requires Python 3.13+ and uses uv for dependency management:

# Clone the repository
git clone https://github.com/Victoratus/supabomb.git
cd supabomb

# Run with uv (handles dependencies automatically)
uv run supabomb --help

For deep crawling features, install Katana:

go install github.com/projectdiscovery/katana/cmd/katana@latest

Example Workflow

Here's a typical security assessment workflow:

# 1. Discover credentials from the target application
uv run supabomb discover --url https://target-app.com --katana

# 2. See what resources are accessible (anonymous)
uv run supabomb enum

# 3. Run security tests
uv run supabomb test

# 4. If issues found, test write permissions
uv run supabomb test-write

# 5. Register for authenticated testing
uv run supabomb signup --verify-email

# 6. Re-run tests with authenticated session (automatic)
uv run supabomb enum
uv run supabomb test

# 7. Export evidence
uv run supabomb dump -o ./evidence/

Responsible Use

Supabomb is designed for authorized security assessments only. Always ensure you have:

Written authorization from the application owner
Permission to test the specific Supabase project
Understanding of applicable laws in your jurisdiction

Never use this tool against applications you don't own or have explicit permission to test.

How It Powers ModernPentest

Supabomb is the foundation of our Supabase security scanning at ModernPentest. Our AI agents use Supabomb as their primary tool for:

Automated RLS policy analysis
Storage bucket permission auditing
PostgREST API security testing
Continuous monitoring for configuration drift

The difference? ModernPentest adds:

AI-powered analysis - Our agents interpret findings and prioritize by actual risk
Continuous scanning - Automated weekly/daily scans catch regressions
SOC 2 reports - Auditor-ready documentation generated automatically
Remediation guidance - Specific fix recommendations for each finding

If you want manual control, use Supabomb directly. If you want automated, continuous security with compliance reporting, try ModernPentest.

Get Started

The code is available on GitHub:

github.com/Victoratus/supabomb

Star the repo, try it on your projects, and let us know what you find. We welcome contributions, bug reports, and feature requests.

For comprehensive coverage of common Supabase security issues, check out our guide: 10 Common Supabase Security Misconfigurations.

Supabomb is part of our commitment to open source security tooling. Follow us for more tools and guides on securing modern web applications.

10 Common Supabase Security Misconfigurations (and How to Fix Them)

Victor Yrazusta Ibarra — Mon, 08 Dec 2025 19:14:41 +0000

Supabase has become one of the most popular backend-as-a-service platforms for modern web applications. Its PostgreSQL foundation, real-time capabilities, and developer-friendly APIs make it an excellent choice for startups and established companies alike.

However, with great power comes great responsibility. Supabase's flexibility means there are many ways to misconfigure your security settings, potentially exposing sensitive user data. In this guide, we'll cover the 10 most common Supabase security misconfigurations we've seen in production applications.

1. Missing Row-Level Security (RLS)

Severity: Critical

The most dangerous misconfiguration is having no Row-Level Security (RLS) enabled at all. When RLS is disabled, anyone with your Supabase URL and anon key (which is public) can read, update, or delete all data in your tables.

The Problem

-- This table has NO RLS - anyone can access all data
create table user_profiles (
  id uuid references auth.users primary key,
  email text,
  full_name text,
  credit_card_last_four text
);

The Fix

Always enable RLS and create appropriate policies:

-- Enable RLS
alter table user_profiles enable row level security;

-- Allow users to read only their own profile
create policy "Users can read own profile"
  on user_profiles for select
  using (auth.uid() = id);

-- Allow users to update only their own profile
create policy "Users can update own profile"
  on user_profiles for update
  using (auth.uid() = id);

2. Overly Permissive RLS Policies

Severity: High

Even with RLS enabled, policies that are too broad can expose data. A common mistake is using true or weak conditions.

The Problem

-- This policy allows ANY authenticated user to read ALL profiles
create policy "Authenticated users can read profiles"
  on user_profiles for select
  using (auth.role() = 'authenticated');

The Fix

Be specific about what data each user can access:

-- Only allow reading your own profile OR public profiles
create policy "Users can read own or public profiles"
  on user_profiles for select
  using (
    auth.uid() = id
    OR is_public = true
  );

3. Service Role Key Exposure

Severity: Critical

The service_role key bypasses all RLS policies and should NEVER be exposed to the client. We've seen this key hardcoded in frontend applications, environment variables leaked in client bundles, and even committed to public repositories.

The Problem

// NEVER do this - service_role key in frontend code
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY // DANGER!
);

The Fix

Only use the anon key in client-side code:

// Correct - using anon key which respects RLS
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
);

Keep service_role key only in server-side code (API routes, server actions, edge functions).

4. Insecure Storage Bucket Policies

Severity: High

Supabase Storage uses similar RLS-style policies, but many developers forget to configure them, leaving files publicly accessible.

The Problem

-- Default policy allows public access to all files
create policy "Public access"
  on storage.objects for select
  using (bucket_id = 'avatars');

The Fix

Restrict access based on ownership:

-- Users can only access their own files
create policy "User can access own files"
  on storage.objects for select
  using (
    bucket_id = 'user-files'
    AND auth.uid()::text = (storage.foldername(name))[1]
  );

-- Users can upload to their own folder
create policy "User can upload own files"
  on storage.objects for insert
  with check (
    bucket_id = 'user-files'
    AND auth.uid()::text = (storage.foldername(name))[1]
  );

5. Missing Email Verification

Severity: Medium

By default, Supabase allows users to sign up and immediately access the application without verifying their email. This enables account enumeration and fake account creation.

The Problem

// User can sign up and immediately access protected resources
const { data, error } = await supabase.auth.signUp({
  email: 'user@example.com',
  password: 'password123'
});
// data.user exists and can be used immediately

The Fix

Enable email confirmation in Supabase Dashboard under Authentication > Settings
Check email confirmation status in your RLS policies:

create policy "Only verified users can access data"
  on sensitive_data for select
  using (
    auth.uid() = user_id
    AND auth.jwt()->>'email_confirmed_at' is not null
  );

6. Direct Table Access via PostgREST

Severity: Medium

Supabase exposes your database through PostgREST, which means any table can be queried directly if not properly secured. Developers sometimes create tables without RLS, thinking they're "internal only."

The Problem

# Anyone can query this table directly via the REST API
curl 'https://your-project.supabase.co/rest/v1/internal_logs' \
  -H "apikey: YOUR_ANON_KEY"

The Fix

Always enable RLS on all tables, even "internal" ones:

-- Secure internal tables by denying all access via RLS
alter table internal_logs enable row level security;

-- No policies = no access via PostgREST
-- Access only through server-side code with service_role

7. Exposed Database Functions

Severity: High

PostgreSQL functions created with SECURITY DEFINER run with the privileges of the function creator, not the calling user. If exposed via PostgREST without proper checks, they can bypass RLS.

The Problem

-- This function runs with elevated privileges
create or replace function delete_user(target_id uuid)
returns void
language sql
security definer
as $$
  delete from user_profiles where id = target_id;
$$;

The Fix

Add authorization checks inside the function:

create or replace function delete_user(target_id uuid)
returns void
language plpgsql
security definer
as $$
begin
  -- Check if the calling user is authorized
  if auth.uid() != target_id then
    raise exception 'Not authorized';
  end if;

  delete from user_profiles where id = target_id;
end;
$$;

8. Weak Password Requirements

Severity: Medium

Supabase's default minimum password length is 6 characters, which is quite weak by modern standards.

The Fix

Configure stronger password requirements in your Supabase Dashboard under Authentication > Settings:

Minimum length: 12 characters
Require uppercase, lowercase, numbers, and symbols

Additionally, implement client-side validation:

const passwordSchema = z.string()
  .min(12, 'Password must be at least 12 characters')
  .regex(/[A-Z]/, 'Password must contain uppercase letter')
  .regex(/[a-z]/, 'Password must contain lowercase letter')
  .regex(/[0-9]/, 'Password must contain a number')
  .regex(/[^A-Za-z0-9]/, 'Password must contain special character');

9. Missing Rate Limiting

Severity: Medium

Supabase doesn't have built-in rate limiting for authentication endpoints, making your app vulnerable to brute force attacks.

The Fix

Implement rate limiting at the application level:

// Using Upstash Redis for rate limiting
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, '1 m'), // 5 attempts per minute
});

export async function signIn(email: string, password: string) {
  const { success } = await ratelimit.limit(email);

  if (!success) {
    throw new Error('Too many login attempts. Please try again later.');
  }

  return supabase.auth.signInWithPassword({ email, password });
}

10. Misconfigured Edge Functions

Severity: High

Supabase Edge Functions are powerful serverless functions that run on Deno. A common mistake is deploying functions without proper JWT verification, making them accessible to anyone who knows the endpoint URL.

The Problem

// This edge function has NO authentication check
import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'

serve(async (req) => {
  // DANGER: Anyone can call this endpoint!
  const { userId } = await req.json()

  // Performing privileged operations without auth
  const userData = await adminClient
    .from('users')
    .select('*')
    .eq('id', userId)
    .single()

  return new Response(JSON.stringify(userData))
})

The Fix

Always verify the JWT token and extract the user from it:

import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'
import { createClient } from 'https://esm.sh/@supabase/supabase-js@2'

serve(async (req) => {
  // Extract the JWT from the Authorization header
  const authHeader = req.headers.get('Authorization')
  if (!authHeader) {
    return new Response('Missing authorization header', { status: 401 })
  }

  // Create a Supabase client with the user's JWT
  const supabase = createClient(
    Deno.env.get('SUPABASE_URL') ?? '',
    Deno.env.get('SUPABASE_ANON_KEY') ?? '',
    { global: { headers: { Authorization: authHeader } } }
  )

  // Verify the token and get the user
  const { data: { user }, error } = await supabase.auth.getUser()

  if (error || !user) {
    return new Response('Invalid token', { status: 401 })
  }

  // Now safely use user.id instead of trusting client input
  const { data } = await supabase
    .from('users')
    .select('*')
    .eq('id', user.id)
    .single()

  return new Response(JSON.stringify(data))
})

Detecting These Issues Automatically

Manually checking all tables, policies, and configurations is tedious and error-prone. We built Supabomb, an open source CLI tool specifically for Supabase security testing.

# Install and run
git clone https://github.com/Victoratus/supabomb.git
cd supabomb

# Discover credentials from your app
uv run supabomb discover --url https://your-app.com

# Run security tests
uv run supabomb test

Supabomb automatically:

Discovers Supabase credentials from your frontend
Enumerates all accessible tables and storage buckets
Tests RLS policies and identifies misconfigurations
Compares anonymous vs. authenticated access
Generates detailed findings reports

Read more about it in our Introducing Supabomb post.

Conclusion

Securing your Supabase application requires a defense-in-depth approach. Here's a checklist to review:

[ ] RLS is enabled on ALL tables
[ ] RLS policies are specific and well-tested
[ ] Service role key is only used server-side
[ ] Storage bucket policies are configured
[ ] Email verification is required
[ ] All database functions have proper authorization checks
[ ] Password requirements are strong
[ ] Rate limiting is implemented
[ ] Edge Functions verify JWT tokens before processing requests

Automate Your Supabase Security

Want continuous protection instead of manual checks? ModernPentest's Supabase Security Scanning uses AI agents trained specifically on Supabase vulnerabilities to:

Scan in under an hour - Full penetration test + SOC 2 report
Catch RLS bypasses - The same issues covered in this guide, detected automatically
Monitor continuously - Weekly/daily scans catch regressions before attackers do
Generate compliance reports - Auditor-ready documentation for SOC 2, ISO 27001

Our agents use Supabomb under the hood, combined with AI analysis to prioritize findings by actual risk and provide specific remediation guidance.

Start Your Free Security Scan →

This guide is part of our Security Guides series. Follow us for more content on securing modern web applications.