Your Supabase Is Public 🔗 **Source:** [Your Supabase Is Public](https://skilldeliver.com/your-supabase-is-public) > [!note]+ Document Notes > tags: [security, Supabase, SaaS] > author: [MISSING] > source: skilldeliver.com > reference: [https://skilldeliver.com/your-supabase-is-public] > date created: 2025-12-23 10:00 > > # 🏷️ Title: Your Supabase Is Public > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: The author casually tested a friend’s new SaaS, found exposed Supabase anon credentials, and could read the entire users table (including sensitive data), a pattern they’ve seen multiple times. - Why it matters: Misconfigured Supabase Row Level Security (RLS) effectively makes production user databases public from the browser. - Key stakeholders: Indie devs, low-code users, SaaS founders, Supabase/Lovable/PocketBase-type platforms, end‑users whose data is exposed. - Risks and tradeoffs: Rapid “vibe coding” and easy defaults trade off against secure-by-default policies; Supabase flexibility vs. risk of catastrophic misconfiguration. - Bottom line: Supabase anon keys are meant to be public, but if you don’t correctly enable RLS—especially on user tables—your whole database may be readable; platforms should make this hard to mess up. ## 📖 Main Content - Core argument: - The author inspects a friend’s SaaS, finds the Supabase URL and anon key via browser dev tools, and uses them directly with curl. - Using the REST endpoint, they fetch the OpenAPI schema and then request the `users` table, which returns full user records (names, emails, password hashes, etc.). - They argue this is common: developers often add their own `users`-like tables without configuring RLS, turning the anon key into a de facto master key. - Responsibility is partly on developers, but the author argues Supabase should warn aggressively when a table named `users` (or similar) is created without RLS. - They contrast Supabase with PocketBase, which ships with a `_pb_users_auth_` collection and secure-by-default access rules (e.g., `id = @request.auth.id`), so you must intentionally weaken security to expose data. - Context & definitions: - Supabase: a hosted backend-as-a-service on Postgres, exposing REST and client SDKs with row‑level security policies. - Anon key: a public key used by frontends to talk directly to Supabase; it is safe only when RLS prevents access to unauthorized rows. - RLS (Row Level Security): Postgres feature that restricts which rows a given user/session can query or mutate, enforced on the database side. - PocketBase: a lightweight backend that provides collections and access rules with more opinionated, safe defaults. - Uncertainties / contested claims: - The exact frequency of this misconfiguration isn’t quantified; the author infers from a small sample (three personal discoveries) and speculation about “100,000+ projects” on tools like Lovable. - Responsibility split (platform vs. developer) is partly normative design philosophy, not strictly empirical. ### 🗒️ Notes - Author describes a pattern: when friends send them new SaaS links, they inspect network requests and often find exposed Supabase credentials. - They capture the Supabase URL and anon key directly from the browser’s network inspector. - With a simple GET to `/rest/v1/?apikey=…` they pull the OpenAPI schema, revealing available tables and endpoints. - Focus then shifts from schema to data: the key question is whether there’s a `users` table exposed through REST. - A follow-up curl to `/rest/v1/users` with the anon key both as `apikey` and `Authorization: Bearer` header returns user data. - When “lucky,” this response includes names, nicknames, emails, password hashes, and any other columns the app stored. - The author notes they’ve never used Supabase for production but have found this pattern three times, including at a seed-stage startup. - Interpretation: developers often create custom `users` tables instead of using built‑in auth tables, but forget (or don’t know how) to configure RLS. - Key claim: the anon key is designed to be public; misconfigured RLS is what turns it into a “master key” to the entire database. - The author explicitly resists blaming only “vibe-coding”; they also question Supabase’s responsibility in UX and safety defaults. - Proposed UX fix: when a developer creates a `users` table, show “a massive red warning popup” clarifying that without RLS, all data is public. - They connect this to Lovable’s $330M Series B and their use of Supabase, wondering how many of the huge number of generated projects leak data. - They argue systems can and should be designed to prevent common dangerous misconfigurations. - PocketBase is held up as a positive example: it ships a `_pb_users_auth_` collection with extended fields and secure default access rules (e.g., `id = @request.auth.id`). - In PocketBase, you must actively override these access rules to make things insecure; in Supabase, you must actively add RLS to make things secure. - Implicit recommendation: choose platforms or patterns that are “secure by default” and treat user data as sensitive from day one. ## 📚 References - Supabase docs — Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security - Supabase Auth & anon key overview: https://supabase.com/docs/guides/auth - PocketBase docs — Collections & rules: https://pocketbase.io/docs/collections/ - Lovable (referenced platform): https://lovable.dev/ - OWASP Top 10 (insecure design / broken access control): https://owasp.org/www-project-top-ten/ ## 🗣️ Paraphrase - Paragraph A paraphrase: The author casually audited a friend’s SaaS, grabbed the Supabase anon key from the browser, and used simple curl commands to inspect tables and read user records, revealing that RLS was missing. - Paragraph B paraphrase: They argue that developers frequently misconfigure Supabase by adding public-like user tables without RLS, effectively turning the anon key into a master key, and contend that Supabase should adopt stronger, opinionated safeguards similar to PocketBase’s secure-by-default access rules. ## 📰 Newsletter In this week’s WordPress-adjacent security corner: a cautionary tale from the Supabase world. A developer pokes at a friend’s new SaaS and, with only an anon key from the browser, pulls the entire users table—emails and password hashes included. The culprit isn’t the idea of public keys, but missing Row Level Security and loose defaults. For WordPress builders running headless or custom backends, the lesson is clear: never assume your API defaults are safe, and don’t let “vibe coding” ship to production. Treat any frontend-exposed key as powerful unless proven otherwise, and favor platforms that are secure by default, as PocketBase shows with opinionated auth collections and rules. Want to tighten your stack? - Audit your REST endpoints and headless integrations. - Ensure sensitive resources are guarded server-side, not just in JavaScript. - Review access control for any custom “users” or “profiles” tables in external services. Security is a feature your users will never see—but they’ll feel it if it’s missing. ## ✅ Action Items #### DevRel - Document a “Supabase anon key safety” guide with examples of correct RLS and common misconfigurations. - Build a demo app showing both insecure and secure Supabase setups, with tests that fail when RLS is absent. - Publish blog posts and talks for WordPress and JS communities about secure backend defaults and frontend-visible keys. - Create quickstart templates (e.g., Next.js, WP headless) that wire Supabase/PocketBase with safe RLS/rules out of the box. - Run office hours to help teams audit their backend auth and RLS configurations. - Collect developer feedback on confusing security UX patterns in backend-as-a-service tools. #### OSPO - Add guidance that any FOSS backend tooling endorsed internally must support secure-by-default auth and RLS-like mechanisms. - Integrate license and security compliance reviews for backend SDKs and hosted backends used with WordPress projects. - Define an intake process for reporting and triaging exposure incidents discovered in community tools. - Maintain an inventory of approved backends with documented security baselines and SBOM coverage. - Offer consultation hours for teams choosing between Supabase, PocketBase, or custom backends. #### Community - Host maintainer clinics on secure API and database defaults for popular WP plugins and companion services. - Provide contributor-friendly “first issue” tasks focused on hardening auth and data access paths. - Encourage sponsors to fund security reviews and audits of popular backend integrations. - Coordinate cross-project incident drills simulating a leaked anon key or public database. #### WordPress - Core: Encourage patterns that avoid exposing raw DB or user data via public endpoints; reinforce capabilities and nonce checks. - Core Performance: Ensure performance optimizations don’t bypass or weaken access checks. - Core AI: When using external vector stores or auth backends, document strict access and key-handling patterns. - Core Program Team: Align security expectations for any official headless or SaaS-style integrations. - Mobile: Review how mobile apps store and use API keys; avoid embedding powerful secrets. - Playground: Provide labs demonstrating safe Supabase/PocketBase integration with RLS. - Community: Include security-by-default topics in meetup and WordCamp content suggestions. - Training: Add lessons on backend access control, RLS, and “public key” misconceptions. - Marketing: Highlight security-conscious plugins, hosts, and backends as part of best-practice storytelling. - Support: Add KB articles on common external-backend misconfigurations and how to spot them. - Design: Incorporate clear security warnings and patterns into admin UI designs where external backends are configured. - Documentation: Add examples showing secure integrations with Supabase/PocketBase from WP. - Photos/TV/Openverse: N/A beyond normal security hygiene. - Polyglots: Help localize security guidance to reach non‑English devs. - Accessibility: Ensure any security warnings are accessible and clearly perceivable. - Meta: Harden .org APIs and exposure of plugin/theme usage telemetry to third‑party services. - CLI: Provide commands to scan and report on external backend keys in configs. - Hosting/Tide: Encourage hosts and quality scores to consider secure backend configuration. - Themes/Plugins: Add review criteria for safe handling of external keys and endpoints. #### The WPOCC - Launch fellowship tracks focused on security and backend integrations. - Offer microgrants for audits of popular Supabase- or PocketBase-based tools in the WP ecosystem. - Pilot funding experiments tied to measurable security hardening outcomes (e.g., RLS adoption). ### FAIR - Promote backend choices that support local verification and minimal sharing of secrets. - Recommend transparent funding and governance for shared backend tools to avoid misaligned incentives. - Curate reusable security policy templates and access-control scorecards for projects. ## 🧪 Hypotheses - H1: A significant fraction of Supabase-based apps expose at least one user-related table without proper RLS when anon keys are used from the frontend. - H2: Opinionated, secure-by-default platforms (like PocketBase) produce fewer data exposure incidents than flexible platforms with weaker defaults. - H3: Clear, high-friction warnings at table creation time (e.g., for `users`) reduce misconfigured public access to sensitive data. - H4: Developers using low-code/no-code tools (e.g., Lovable) are more likely to misconfigure backend security than those with stronger backend experience. ### 📊 Methodology - For H1: - Randomly sample public web apps known to use Supabase; attempt to collect anon keys from browser tools and query common tables with RLS checks. - Analyze rates of successful unauthorized reads. - For H2: - Compare incident reports, disclosures, and search for leaked datasets for Supabase vs. PocketBase projects normalized by adoption. - For H3: - Run controlled UX experiments in staging consoles: track configuration errors with/without strong warnings and secure presets. - For H4: - Survey and interview users of low-code platforms vs. traditional frameworks; correlate self-reported expertise and observed misconfigurations. ### ❓ Questions - How many Supabase projects in the wild have at least one table effectively public via anon key? - Should Supabase automatically apply restrictive RLS on any table with user-like column names? - How can tooling detect and warn about “dangerous by pattern” tables (e.g., containing emails, password hashes)? - What education formats most effectively teach frontend-heavy devs about backend data access control? - How can WordPress plugins safely integrate Supabase/PocketBase without leaking secrets or user data? ### 🔮 Future Research - Automated scanners for Supabase/PocketBase configs that detect unsafe RLS/rule patterns. - IDE and dashboard integrations that lint schema changes for potential data exposure. - Behavior studies on how developers respond to security warnings vs. secure defaults. - Empirical comparisons of security incident rates across BaaS platforms. ### 💡 Implications - Practice: Teams must treat frontend-visible keys as powerful and enforce database-side RLS for all sensitive tables. - Policy: Platforms may need internal policies requiring secure-by-default backend tools for user data. - Security: Misconfigured RLS can be as dangerous as no auth at all, warranting dedicated audits. - Education: Curricula for web dev should include concrete labs on RLS and public-key patterns. - Funding models: Investors backing low-code/BaaS ecosystems should require evidence of strong default security. ### 🧠 Learning Styles Assessment - Reading level (rough estimate via Flesch–Kincaid): upper high school to early college; informal but technical vocabulary (RLS, endpoints, schemas). #### 👀 Visual learners - Present: Minimal; references to screenshots (“Supabase credentials exposed”, “Pocketbase default access control”) but not shown here. - Improve: Add architecture diagrams of frontend–backend–DB flows and RLS enforcement points. #### 🔊 Aural learners - Present: No audio. - Improve: 2–5 minute narrated explanation or podcast-style segment on Supabase security pitfalls. #### 🗣️ Verbal learners - Present: Story-driven anecdote, clear explanation of what anon keys and RLS do. - Improve: Add a small glossary of key terms and analogies (e.g., “master key vs. guest key”). #### 🧩 Kinesthetic learners - Present: Implicit tasks (curl examples) but no guided exercises. - Improve: Step-by-step labs to intentionally misconfigure and then fix RLS in a test project. #### 🧠 Logical learners - Present: Clear cause–effect chain between missing RLS and data exposure. - Improve: Tables or flowcharts of request paths and access decisions. #### 🧑‍🤝‍🧑 Social learners - Present: Story about a friend’s app; little collaborative guidance. - Improve: Group exercises or code review checklists for teams to apply. #### 🧘‍♀️ Solitary learners - Present: Short article conducive to solo reflection and experimentation. - Improve: Reflection prompts on readers’ own backend configurations. #### 🌿 Naturalistic learners - Present: No environment analogies. - Improve: Use ecosystem metaphors (e.g., “perimeter vs. internal species barriers”) for security layers. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Basic headings and paragraphs; likely readable. - Improve: Ensure headings hierarchy is consistent and images have descriptive alt text (especially security warning screenshots). #### Keyboard navigation - Present: Standard article layout likely keyboard-friendly. - Improve: Ensure focus indicators are visible and skip links are available if layout is complex. #### Contrast and readability - Present: Unknown; depends on site theme. - Improve: Verify 4.5:1 contrast and adequate line spacing. #### Text resizing and reflow - Present: Likely responsive. - Improve: Test at 200% zoom and on small screens to prevent clipping; respect prefers-reduced-motion. #### Media and captions - Present: Static images only. - Improve: Add captions describing what the security-related screenshots show. #### Forms and interactions - Present: Minimal interactivity. - Improve: If any email/signup forms exist nearby, ensure labels and error messages are accessible. #### Standards reference - Map any issues to WCAG 2.2 AA for text contrast, keyboard access, and non-text content. ### 🌍 DEIB Assessment #### Cultural breadth - Present: Generic tech context, no region-specific assumptions. - Improve: Consider examples from diverse developer communities and access levels. #### Inclusive language - Present: Mostly neutral; some casual slang (“vibe-coding wave”) but not targeted. - Improve: Add plain-language summary sections for non-native English readers. #### Neurodiversity support - Present: Short, linear structure; manageable for many. - Improve: More subheadings and bulleting for scan-ability; avoid dense paragraphs. #### Representation - Present: No people pictured or described in detail. - Improve: If adding imagery, ensure diverse, non-stereotypical representation. #### Psychological safety - Present: Lightly critical tone toward tooling and patterns, not individuals. - Improve: Emphasize learning and systemic fixes rather than blaming “bad developers.” ### ✅ Logical Validity #### Strong reasoning - The causal link between public anon key + missing RLS and database exposure is solid and technically correct. - The analogy to PocketBase as “secure by default” is a good comparative argument, showing an alternative design that reduces error. #### Fallacies - Potential hasty generalization: extrapolating from three observed incidents to a large fraction of all Supabase apps. Could be improved by acknowledging the anecdotal nature and calling for data. #### Tone of voice - Informal, slightly sardonic, and opinionated. Uses humor (“vibe-coding wave”, seed-stage startup skull) to make a serious security point without being overly alarmist. ### 🛡️ DARVO Analysis - Deny: No denial or minimization of the security issue; the author is highlighting the problem. - Attack: Mild critique toward Supabase UX and “vibe coding,” but not an attack on specific individuals. - Reverse victim/offender: None. The author frames users as potentially harmed, and developers/platforms as responsible parties; no attempt to recast offenders as victims. ## 🎯 Conclusion The article shows how easy it can be to read an entire Supabase-backed user database from the browser when RLS is missing, especially on custom `users` tables. Anon keys are meant to be public, but they are only safe when the database enforces strict, carefully designed row-level policies. Platforms and developers alike should push toward secure-by-default patterns, clearer warnings, and routine audits of backend access rules. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] Supabase anon key can expose users > [!quote] [Your Supabase Is Public](https://skilldeliver.com/your-supabase-is-public) by an unnamed author via [[skilldeliver.com]]. Published 2025-12-22. > “The anon key is designed to be public but if you are not careful that anon key becomes a master key to your entire database.” Two lines: context and use. Cite data if relevant. [view highlight](https://skilldeliver.com/your-supabase-is-public#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] PocketBase is secure by default > [!quote] [Your Supabase Is Public](https://skilldeliver.com/your-supabase-is-public) > “You literally have to go out of your way to make it insecure.” Two lines: context and use. [view highlight](https://skilldeliver.com/your-supabase-is-public#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Supabase anon key risks depend on RLS - Supabase anon keys are only safe when strict row-level security is configured on all sensitive tables. - Pointer to article example with exposed `users` table. - Links: [[Supabase]] [[Row-Level-Security]] #### [Z2] Secure-by-default backends reduce misconfigurations - Opinionated, restrictive defaults (like PocketBase’s auth rules) lower the chance of accidental public data exposure. - Pointer to PocketBase `_pb_users_auth_` default rules. - Links: [[Secure-By-Default-Design]] [[Backend-as-a-Service]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Audit all Supabase projects for missing RLS on user-related tables — context/https://skilldeliver.com/your-supabase-is-public #fleeting #inbox - [F2] Draft WordPress guide on secure external backend integrations — context/https://skilldeliver.com/your-supabase-is-public #fleeting #inbox - [F3] Prototype linter that flags unsafe Supabase schemas in CI — context/https://skilldeliver.com/your-supabase-is-public #fleeting #inbox --- <!-- deep-read:sections end -->