SecureStartKit
SecurityFeaturesPricingDocsBlogChangelog
Sign inBuy Now
Home/Glossary/Backend-only data access
Data Layer

Backend-only data access

Also known as: server-only data access, backend-only architecture

Definition

Backend-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.

What is backend-only data access?

A structural commitment: no Supabase client is instantiated in a Client Component, no anon key is used for query construction, and the service_role key never enters the browser bundle. Every database operation is wrapped in a Server Action that validates input, authenticates the user, authorizes the operation, and only then queries.

Why is this pattern safer than client-side queries with RLS?

RLS is a strong second line, but it relies on perfect policies across every table. A single missing policy on a new table is a wide-open leak. Backend-only access removes that whole risk class: there is no client-side query path, so missing policies on internal tables cannot be exploited.

How does this differ from the Supabase quickstart?

The quickstart shows client-side queries with RLS as the only defense. That pattern works for prototypes but fails at scale: every new table is a security-relevant migration, and a single mistake exposes data. Backend-only access uses RLS as a deny-all safety net AND a Server Action layer that does the explicit authorization work in code that you can read.

Learn more

  • Backend-only Data Access: The Architectural Pattern

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.
  • Anon keyThe 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.
  • 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.
  • Server ActionsServer Actions are Next.js functions marked with the 'use server' directive that run on the server and can be called from client components. Every Server Action is a public HTTP endpoint and must validate inputs with Zod, authorize identity from the session, and never trust user IDs from the request payload.
← Back to full glossary