SecureStartKit
SecurityFeaturesPricingDocsBlogChangelog
Sign inBuy Now
Home/Glossary/Anon key
Data Layer

Anon key

Also known as: SUPABASE_ANON_KEY, anonymous key, public key

Definition

The anon key is the Supabase public API key that respects Row Level Security. It is safe to include in the browser bundle because RLS gates every query against the user's JWT claims. The anon key alone cannot read or modify rows unless an RLS policy explicitly allows it.

What is the anon key?

The anon key is a long-lived JWT signed by your Supabase project's secret. It identifies any caller as "the public role" and is the credential that browser clients use to talk to PostgREST and Supabase Auth. The key itself confers no data access; RLS policies do.

Is it safe to put the anon key in the browser?

Yes, by design. The key is marked NEXT_PUBLIC_SUPABASE_ANON_KEY for exactly this reason. The safety argument depends on RLS being enabled with sensible policies on every table. A table without RLS enabled, or with a permissive "true" policy, exposes data to any browser caller who knows the table name.

How does the anon key relate to service_role?

They are inverse. Anon is bounded by RLS; service_role bypasses RLS. Anon belongs in the browser; service_role never does. A common attack pattern in AI-generated code is using service_role in a Client Component because the AI confused the two keys. The fix is structural: import 'server-only' on the file that owns the service_role client.

Learn more

  • Backend-only Data Access
  • Exposed API Keys: How AI Tools Leak Secrets

Related terms

  • Service role keyThe service role key is the Supabase API key that bypasses Row Level Security and grants full database access. It must never enter the browser bundle. In a Next.js app, the service role key is used only in Server Actions and Route Handlers via createAdminClient, with the import gated by Next.js's server-only enforcement.
  • Row Level SecurityRow Level Security is a Postgres feature that filters which rows of a table each user can see or modify. In Supabase apps, RLS policies are written in SQL and evaluated on every query against the authenticated user's JWT claims, making the database itself the authorization boundary.
  • Backend-only data accessBackend-only data access is an architectural pattern where the database is never queried directly from the browser. All queries run through Server Actions or Route Handlers using the service_role key, after server-side authentication and Zod validation. The browser only receives data the server explicitly returns.
← Back to full glossary
SecureStartKit

The security-first Next.js SaaS template. Auth, payments, and everything you need to launch - with backend-only data access, Zod validation on every input, and built-in optimization for AI coding agents.

Summarize with AI

Product

  • Security
  • Features
  • Pricing
  • FAQ
  • Docs
  • About

Use Cases

  • For Indie Hackers
  • For Solo Developers
  • Fintech SaaS
  • Internal Tools
  • Healthtech SaaS

Free Tools

  • All Tools
  • RLS Policy Generator
  • Security Checklist
  • Security Headers
  • JWT Decoder
  • JWT Generator
  • CORS Config Generator
  • JSON to Zod Converter
  • API Key Generator
  • Stripe Webhook Verifier
  • Stripe Fee Calculator
  • SaaS Pricing Calculator
  • Tech Stack Costs
  • OG Image Preview

Compare

  • All comparisons
  • vs ShipFast
  • vs Makerkit
  • vs Supastarter
  • vs Divjoy
  • vs Nextbase
  • One-time vs subscription

Resources

  • Blog
  • Glossary
  • Security Patterns
  • Changelog
  • Contact
  • Privacy
  • Terms

More from the same maker

  • AppScreenshotStudio
  • QueryScope
  • FrictionScope
  • MCP Hunter
  • BookIllustrationAI
  • MyCVCraft
  • StyleMyFade

© 2026 SecureStartKit. All rights reserved.

Built with SecureStartKit