Platform-Specific Agents
Specialized agents for Supabase, Firebase, and other backend platforms
Platform-Specific Agents
Our platform agents provide specialized security testing for Backend-as-a-Service (BaaS) platforms like Supabase, Firebase, and Convex. These agents understand platform-specific security models and test for common misconfigurations.
Zero Configuration Required - Platform agents activate automatically. You don't need to configure your application as "Supabase" or "Firebase." Our AI agents detect these platforms during testing and run specialized checks automatically.
Why Platform-Specific Testing?
BaaS platforms have unique security considerations that general scanners miss:
| Platform Challenge | Why It's Different |
|---|---|
| Row Level Security | Database-level permissions unlike traditional apps |
| Security Rules | Custom DSLs for access control |
| Client-Side Keys | Exposed by design, security depends on rules |
| Real-time Sync | Data flows differently than REST APIs |
The Problem
In 2024, security researchers found:
- 916 websites exposed 125 million records via Firebase misconfigurations
- Supabase RLS complexity leads to frequent authorization gaps
- Most issues stem from default configurations and misunderstood security models
Our platform agents catch these issues before attackers do.
Supabase Agent
Specialized testing for Supabase-powered applications.
What It Tests
| Check | Description |
|---|---|
| RLS Policy Gaps | Missing or weak Row Level Security |
| Cross-Org BOLA | Accessing other organizations' data |
| Storage Buckets | Public access to private files |
| Edge Functions | Authentication bypass |
| Anonymous Access | What unauthenticated users can access |
Row Level Security Testing
The Supabase Agent analyzes your RLS policies:
Enumerate Tables and Policies
Discover all tables and their associated RLS policies.
Test Authenticated Access
- User A accessing own data
- User A attempting to access User B's data
Test Anonymous Access
What data is accessible without authentication?
Test Policy Bypass
Edge cases in policy logic that could allow unauthorized access.
Report Gaps
Document all findings with remediation guidance.
Common Findings
Missing RLS Policy
❌ Critical: No RLS policy on users table
Table: public.users
Issue: RLS is enabled but no policies defined
Result: All authenticated users can read/write all rows
Impact: Complete data exposure to any authenticated userWeak RLS Policy
⚠️ High: RLS policy allows horizontal access
Table: public.orders
Policy: SELECT where auth.uid() IS NOT NULL
Issue: Any authenticated user can view all orders
Expected: SELECT where auth.uid() = user_idStorage Bucket Testing
| Test | Description |
|---|---|
| Public buckets | Unintended public access |
| Policy gaps | Missing download/upload restrictions |
| Path traversal | Accessing files outside intended scope |
Edge Function Security
| Test | Description |
|---|---|
| JWT verification | Are functions checking auth? |
| Authorization | Are permissions validated? |
| Input validation | Injection vulnerabilities |
Firebase Agent
Specialized testing for Firebase-powered applications.
What It Tests
| Check | Description |
|---|---|
| Firestore Rules | Document/collection access control |
| RTDB Permissions | Realtime Database security |
| Storage Rules | Cloud Storage access |
| Authentication | Auth configuration issues |
Security Rules Testing
Firebase security rules are tested systematically:
Read Security Rules
Analyze current security rules if publicly accessible.
Test Common Misconfigurations
allow read, write: truepatterns- Overly permissive wildcards
Test Authenticated Scenarios
- Cross-user data access
- Role bypass attempts
Test Anonymous Scenarios
Check for public data exposure without authentication.
Report Findings
Document issues with Firebase-specific fix guidance.
Common Findings
Public Database Access
❌ Critical: Firestore allows public read/write
Rule: match /{document=**} { allow read, write: true; }
Issue: Anyone can read and modify any document
Impact: Complete data breach, data manipulation possibleMissing Authentication Check
⚠️ High: Storage allows unauthenticated downloads
Rule: allow read: if true;
Bucket: gs://project.appspot.com/user-uploads
Issue: Private user files accessible without authentication
Impact: Exposure of private user documentsWhat We Check
| Category | Specific Tests |
|---|---|
| Firestore | Document permissions, collection rules, wildcards |
| RTDB | Read/write rules, user isolation |
| Storage | Bucket policies, file permissions |
| Auth | Self-signup, email verification, password policies |
Convex Agent
Specialized testing for Convex-powered applications.
What It Tests
| Check | Description |
|---|---|
| Function Permissions | Public vs internal function exposure |
| Database Access | Query and mutation authorization |
| Authentication | Auth integration and validation |
| Input Validation | Argument validation in functions |
Common Findings
Exposed Internal Functions
❌ Critical: Internal function accessible publicly
Function: internalMutation:deleteAllUsers
Issue: Function marked as internal but accessible via public API
Result: Unauthorized users can invoke admin functions
Impact: Complete data manipulation possibleMissing Authorization
⚠️ High: Query returns data without authorization check
Function: query:getUserData
Issue: No auth check before returning sensitive data
Result: Any authenticated user can access any user's data
Expected: Verify ctx.auth.userId matches requested userVercel/Next.js Coverage
While not a dedicated agent, our web agents include Vercel-specific checks:
| Check | Description |
|---|---|
| Environment Variables | NEXT_PUBLIC_ exposure |
| API Routes | Missing authentication |
| Edge Functions | Authorization bypass |
| Middleware | Security header configuration |
Common Findings
⚠️ Medium: Sensitive data in NEXT_PUBLIC_ variable
File: Client-side bundle
Variable: NEXT_PUBLIC_DATABASE_URL
Issue: Database connection string exposed to client
Impact: Database credentials visible to anyonePlatform Detection
Our agents automatically detect platform usage during each pentest—no configuration required:
| Platform | Detection Method | Triggers |
|---|---|---|
| Supabase | URL patterns, SDK usage, config objects | supabase.co URLs, @supabase/supabase-js imports |
| Firebase | Config object, SDK imports | firebase.google.com, firebaseConfig objects |
| Vercel/Next.js | Headers, deployment patterns | x-vercel-* headers, /_next/ paths |
| Convex | Client configuration, function patterns | convex.cloud URLs, Convex client setup |
Dynamic Adaptation
Platform detection happens at runtime, not configuration time:
- Automatic discovery - Add Supabase to your project next month, and we'll detect and test it automatically
- No reconfiguration needed - Switch from Firebase to Supabase? We adapt without any changes on your part
- Always current - We detect what's actually deployed, not what you configured months ago
This means your security testing stays accurate even as your technology stack evolves.
Security Best Practices
Supabase
- Always enable RLS - On every table with user data
- Test policies - Verify with different user contexts
- Minimize anonymous access - Require auth when possible
- Protect storage - Apply policies to buckets
- Secure edge functions - Verify JWTs
Firebase
- Never use open rules - Remove
allow read, write: true - Validate ownership - Check
request.auth.uid == resource.data.userId - Limit write access - Validate data being written
- Secure storage - Match rules to application needs
- Enable email verification - For user registration
Convex
- Use internal functions - Mark admin functions as
internalMutation/internalQuery - Validate authorization - Check
ctx.authin every function handling user data - Validate arguments - Use Convex validators for all function arguments
- Limit public exposure - Only expose necessary functions as public
- Audit function access - Review which functions are publicly callable
Next Steps
- Add your application - Platform detection is automatic
- Learn about Web Agents
- Learn about API Agents
- Understand the application model
Last updated: December 8, 2025