Observed Signal · May 3, 2026 · Security Research · Source: DEV Community · Impact: 2/5 · Sentiment: Negative
Supabase Recon: From One Anon Key to Full Schema
A technical walkthrough by RUGERO Tesla (404Saint) demonstrates a four-step reconnaissance methodology applied to a self-owned Supabase project. Starting with only the public project URL and the anon JWT found in a frontend bundle, the author decodes the token, probes the PostgREST API, uses wordlist enumeration and HTTP response codes to discover accessible tables, and applies error-based inference to reconstruct table schemas. The post shows that, on the tested project, multiple tables (profiles, user_roles, assignments, messages, disputes, notifications) were readable using the anon key because Row Level Security (RLS) was not enabled. The author successfully retrieved a sample record from the assignments table. The piece emphasizes starting passive, trying direct probes, inferring from behavior, and mapping schema before reading data.
Demonstrates a common misconfiguration (missing RLS) in Supabase that can expose data via anon frontend keys; important for developers and platform security but not industry-shifting.
Track Supabase Signals & Market Shifts in Real-Time
Polaris7 autonomous intelligence agents track regulatory filings, primary sources, executive changes, and deal flow 24/7. Create your free Explorer workspace to monitor these entities.
Key Takeaways & Evidence Grounding
- Author RUGERO Tesla published a dev.to post on 2026-05-03 documenting reconnaissance against a Supabase project.
- Supabase frontends expose a project URL and an anon API key; the anon key is a JWT with role 'anon' and an expiration set roughly ten years out.
- The PostgREST OpenAPI endpoint requires the service_role API key; using the anon key returns an 'Invalid API key' response.
- Using wordlist enumeration and HTTP response codes the author identified accessible tables: profiles, user_roles, assignments, messages, disputes, notifications.
- Error-based inference confirmed columns (e.g., profiles: id, user_id, nickname, university, department, level, created_at, updated_at) and allowed reading a seeded assignments record including fields like id, student_id, title, subject, deadline (2026-04-09T06:30:00+00:00), budget (2500.0) and status ('open').
Connected Companies & Entities
2 Entities mappedOntology Mapping & Concepts
Related Market Signals & Shifts
Recent verified developments and strategic activity across this market segment.
Prisma and Drizzle bypass Supabase Row-Level Security
Prisma and Drizzle, when pointed at a Supabase project's DATABASE_URL, open direct PostgreSQL connections as the postgres role and therefore bypass Supabase Row-Level Security (RLS). On Supabase the postgres role typically owns migrated tables and has the BYPASSRLS attribute, so policies do not run for ORM queries. The Supabase JS/PostgREST path enforces RLS by running statements as unprivileged anon/authenticated roles. The article explains the mechanism, shows why FORCE ROW LEVEL SECURITY alone won't help if the connection role bypasses RLS, and gives three fixes: use supabase-js for user-facing data, set role and JWT claims inside transaction-scoped statements, or create a dedicated least-privileged login role without BYPASSRLS.
Supabase Authentication and Authorization Patterns
This technical guide explains how to implement authentication and authorization with Supabase for production-ready web applications. It covers Supabase features (email/password, social OAuth, magic links, MFA), session management, JWTs, row-level security (RLS) policies, custom claims and RBAC, Next.js client/server setup, middleware protection for routes, and testing strategies. The article includes concrete code examples and best-practices (never expose service role keys, validate sessions server-side, use RLS) and Next.js-specific patterns for protected routes and session handling.
Scan: 15 Lovable Apps — 40% Expose DB in Browser
A developer scanned 15 public apps built on the Lovable ecosystem and found widespread client-side exposure of databases and missing basic web hardening. The scan found 6 of 15 apps load Supabase directly in the browser (including a public API key in page source) and 14 of 15 apps shipped no Content-Security-Policy. Two real-world audits (performed with owners' permission) revealed readable user profile data including password hashes and a paid learning app whose entire paid catalogue was accessible without authentication. The author notes the core mistake is not exposing Supabase client-side but failing to enforce Row-Level Security (RLS) at the database layer, and published a free passive surface-check tool at sealdy.dev.
Track Real-Time Market Signals & Shifts
Set up custom watchlists to receive automated, evidence-grounded executive digests whenever material signals or shifts occur across your tracked landscape.