Update Data API docs to include explicit grants#42969
Conversation
Update API quickstart and creating-routes guides to include steps for granting Data API permissions via SQL GRANT statements and the table editor toggle. Add a new "Enable Data API access" section to all SDK installing docs explaining the permission requirements. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Update the shared quickstart_db_setup partial to include the grant statement for enabling Data API access, and mention the toggle when using the Table Editor. This update affects all framework quickstart guides (Next.js, React, Flutter, etc). Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Clarify that each client library uses the Data API to query and mutate Postgres data, and fix toggle label to "Data API Access". Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Include grant execute on function alongside table grants in the Data API access section. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
📝 WalkthroughWalkthroughThis PR consolidates Data API guidance into a new "Data API" guide, removes the "Hardening the Data API" page, updates navigation labels/URLs and redirects, and adds consistent "Enable Data API access" instructions and SQL GRANT examples across quickstarts, tutorials, troubleshooting, and multiple SDK install docs. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
There was a problem hiding this comment.
Pull request overview
Updates Supabase docs to reflect explicit Data API grants as the mechanism for exposing tables/functions, adds a dedicated “Data API” guide, and rewires references away from the removed “Hardening the Data API” page.
Changes:
- Add a new
/docs/guides/database/data-apipage describing exposure via grants and default privileges. - Update multiple client library “Installing” reference pages and API guides to mention Data API integration settings and example GRANT statements.
- Remove the old
hardening-data-apiguide and adjust navigation/redirects/links to point to the new destinations.
Reviewed changes
Copilot reviewed 17 out of 17 changed files in this pull request and generated 11 comments.
Show a summary per file
| File | Description |
|---|---|
| apps/www/lib/redirects.js | Adds a redirect for the removed hardening page (but currently duplicates an existing rule). |
| apps/docs/docs/ref/swift/installing.mdx | Adds “Enable Data API access” section + SQL GRANT examples. |
| apps/docs/docs/ref/python/installing.mdx | Adds “Enable Data API access” section + SQL GRANT examples. |
| apps/docs/docs/ref/kotlin/installing.mdx | Adds “Enable Data API access” section + SQL GRANT examples. |
| apps/docs/docs/ref/javascript/installing.mdx | Adds “Enable Data API access” section + SQL GRANT examples. |
| apps/docs/docs/ref/dart/installing.mdx | Adds “Enable Data API access” section + SQL GRANT examples. |
| apps/docs/docs/ref/csharp/installing.mdx | Adds “Enable Data API access” section + SQL GRANT examples. |
| apps/docs/content/troubleshooting/database-api-42501-errors.mdx | Updates troubleshooting guidance to reference Data API integration settings and new Data API page. |
| apps/docs/content/guides/security/product-security.mdx | Updates security guide links to point to the new Data API page. |
| apps/docs/content/guides/database/secure-data.mdx | Updates security guide links to point to the new Data API page. |
| apps/docs/content/guides/database/data-api.mdx | Introduces a new concise guide for Data API exposure/access. |
| apps/docs/content/guides/api/securing-your-api.mdx | Updates wording around exposure/grants and removes the “disable/restrict schema” section. |
| apps/docs/content/guides/api/quickstart.mdx | Adds explicit GRANT step and updates dashboard instructions to use integration settings. |
| apps/docs/content/guides/api/hardening-data-api.mdx | Removes the old hardening guide. |
| apps/docs/content/guides/api/creating-routes.mdx | Replaces video with steps including integration settings + GRANT example and adds explanatory note. |
| apps/docs/content/_partials/quickstart_db_setup.mdx | Adds integration settings mention and a GRANT example for read access. |
| apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts | Updates one nav entry from hardening to the new Data API page. |
|
@copilot open a new pull request to apply changes based on the comments in this thread |
…ct and nav link (#44061) ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Docs update ## What is the current behavior? - All SQL grant examples use `grant all ... to anon, authenticated, service_role` — overly broad and encourages insecure copy-paste - `securing-your-api.mdx` incorrectly states RLS applies to functions - `redirects.js` has a duplicate `source: '/docs/guides/database/hardening-data-api'` — the first entry (which wins) pointed to the now-deleted `/guides/api/hardening-data-api` page, breaking the redirect - Nav entry "Hardening the Data API" in the API Security section links to the deleted page ## What is the new behavior? **Least-privilege grants** across all SDK `installing.mdx` files, `creating-routes.mdx`, and `quickstart.mdx`: ```sql -- anon gets read-only grant select on public.your_table to anon; -- authenticated gets CRUD grant select, insert, update, delete on public.your_table to authenticated; -- service_role is unrestricted server-side grant all on public.your_table to service_role; -- functions: execute for authenticated/service_role only grant execute on function public.your_function to authenticated, service_role; ``` **RLS wording fix** (`securing-your-api.mdx`): scope RLS guidance to tables/views only; add a separate note that function access is controlled via `EXECUTE` grants and `SECURITY DEFINER` review. **Redirect consolidation** (`redirects.js`): single redirect for `/docs/guides/database/hardening-data-api` → `/docs/guides/api/securing-your-api`; new redirect for the deleted `/docs/guides/api/hardening-data-api` → same destination. **Nav fix** (`NavigationMenu.constants.ts`): replace broken "Hardening the Data API" link with "Data API" → `/guides/database/data-api`. ## Additional context Addresses review feedback on PR #42969. <!-- START COPILOT CODING AGENT TIPS --> --- 💬 Send tasks to Copilot coding agent from [Slack](https://gh.io/cca-slack-docs) and [Teams](https://gh.io/cca-teams-docs) to turn conversations into code. Copilot posts an update in your thread when it's finished. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: SaxonF <1072756+SaxonF@users.noreply.github.com>
| permanent: true, | ||
| source: '/docs/guides/database/hardening-data-api', | ||
| destination: '/docs/guides/api/hardening-data-api', | ||
| destination: '/docs/guides/api/securing-your-api', |
There was a problem hiding this comment.
The old Hardening Data API guide is being redirected to .../api/securing-your-api, but this PR introduces a new .../database/data-api guide and updates navigation to point there. Consider redirecting /docs/guides/database/hardening-data-api to the new Data API page (or adding an additional redirect) so users land on the closest replacement content instead of a narrower security-focused page.
| destination: '/docs/guides/api/securing-your-api', | |
| destination: '/docs/guides/database/data-api', |
| destination: '/docs/guides/api/securing-your-api', | ||
| }, | ||
| { | ||
| permanent: true, | ||
| source: '/docs/guides/api/hardening-data-api', | ||
| destination: '/docs/guides/api/securing-your-api', |
There was a problem hiding this comment.
Same redirect target concern as above: /docs/guides/api/hardening-data-api currently redirects to .../api/securing-your-api, but the PR replaces the removed guide with a new .../database/data-api page and nav points there. Redirecting to the new Data API page would better preserve intent for existing links.
| destination: '/docs/guides/api/securing-your-api', | |
| }, | |
| { | |
| permanent: true, | |
| source: '/docs/guides/api/hardening-data-api', | |
| destination: '/docs/guides/api/securing-your-api', | |
| destination: '/docs/guides/database/data-api', | |
| }, | |
| { | |
| permanent: true, | |
| source: '/docs/guides/api/hardening-data-api', | |
| destination: '/docs/guides/database/data-api', |
| supabase-js uses the Data API to query and mutate your Postgres data. You first need to grant Data API roles permissions to access your tables and functions. | ||
|
|
||
| In [Data API integrations settings](/dashboard/project/_/integrations/data_api/settings), expose the specific tables and functions you want to access. To automatically grant access for new tables and functions in `public`, enable **Default privileges for new entities**. | ||
|
|
There was a problem hiding this comment.
This section introduces granting table/function privileges for Data API access, but it doesn’t warn that exposing/granting access without RLS can make data broadly accessible. Consider adding a short note here recommending enabling RLS on exposed tables/views and creating appropriate policies before granting client-role access.
| Before exposing tables or granting Data API access to client roles such as `anon` and `authenticated`, enable Row Level Security (RLS) on those tables/views and create appropriate policies to ensure only the intended data is accessible. |
| supabase-py uses the Data API to query and mutate your Postgres data. You first need to grant Data API roles permissions to access your tables and functions. | ||
|
|
||
| In [Data API integrations settings](/dashboard/project/_/integrations/data_api/settings), expose the specific tables and functions you want to access. To automatically grant access for new tables and functions in `public`, enable **Default privileges for new entities**. | ||
|
|
There was a problem hiding this comment.
This new section explains granting Data API access but doesn’t mention that granting privileges without enabling RLS (and writing policies) can expose data broadly to client roles. Consider adding a short RLS warning here to align with the security guidance elsewhere in the Data API docs.
| When granting Data API access to client roles such as `anon` and `authenticated`, ensure Row Level Security (RLS) is enabled on those tables and that you have written restrictive policies so you do not expose more data than intended. |
| -- Grant least-privilege access to tables | ||
| grant select on public.your_table to anon; | ||
| grant select, insert, update, delete on public.your_table to authenticated; | ||
| grant all on public.your_table to service_role; | ||
|
|
There was a problem hiding this comment.
The snippet claims "Grant least-privilege access to tables" but then uses grant all on public.your_table to service_role;. Consider either using explicit privileges (e.g., CRUD) or adjusting the wording so it doesn’t describe the example as least-privilege while granting ALL.
| alter default privileges for role postgres in schema public | ||
| grant select, insert, update, delete on tables to anon, authenticated, service_role; | ||
|
|
||
| alter default privileges for role postgres in schema public | ||
| grant execute on functions to anon, authenticated, service_role; |
There was a problem hiding this comment.
The ALTER DEFAULT PRIVILEGES FOR ROLE postgres ... example will only affect objects created by the postgres role. If users create tables/functions owned by another role, the default privileges won’t apply and the "Default privileges for new entities" behavior won’t match this snippet. Consider adding a note to replace postgres with the role that owns/creates new objects (or omit FOR ROLE and explain it runs for the current role).
| -- Grant least-privilege access to tables | ||
| grant select on public.your_table to anon; | ||
| grant select, insert, update, delete on public.your_table to authenticated; | ||
| grant all on public.your_table to service_role; | ||
|
|
There was a problem hiding this comment.
The snippet header says "Grant least-privilege access to tables" but includes grant all on public.your_table to service_role;. Consider listing the explicit privileges needed or adjusting the wording so it doesn’t describe the example as least-privilege while using GRANT ALL.
| -- Grant least-privilege access to tables | ||
| grant select on public.your_table to anon; | ||
| grant select, insert, update, delete on public.your_table to authenticated; | ||
| grant all on public.your_table to service_role; | ||
|
|
There was a problem hiding this comment.
The snippet calls this "least-privilege" but grants ALL on the table to service_role. Consider replacing GRANT ALL with explicit privileges or adjusting the wording so it doesn’t claim least-privilege while granting ALL.
| supabase-csharp uses the Data API to query and mutate your Postgres data. You first need to grant Data API roles permissions to access your tables and functions. | ||
|
|
||
| In [Data API integrations settings](/dashboard/project/_/integrations/data_api/settings), expose the specific tables and functions you want to access. To automatically grant access for new tables and functions in `public`, enable **Default privileges for new entities**. | ||
|
|
There was a problem hiding this comment.
This section introduces granting Data API access but doesn’t mention that granting privileges without enabling RLS (and writing policies) can expose data broadly to clients. Consider adding a short RLS warning here to align with the rest of the Data API security guidance.
| When granting Data API access to tables that contain sensitive data, make sure [Row Level Security (RLS)](/docs/guides/database/postgres/row-level-security) is enabled and that you have written appropriate policies. Without RLS, these role grants can allow clients to access all rows in the exposed tables. |
|
|
||
| supabase-kt uses the Data API to query and mutate your Postgres data. You first need to grant Data API roles permissions to access your tables and functions. | ||
|
|
||
| In [Data API integrations settings](/dashboard/project/_/integrations/data_api/settings), expose the specific tables and functions you want to access. To automatically grant access for new tables and functions in `public`, enable **Default privileges for new entities**. |
There was a problem hiding this comment.
This new section tells readers to grant Data API access but doesn’t mention that without RLS (and policies) client-role grants can expose data broadly. Consider adding a short warning here recommending enabling RLS on exposed tables/views and creating policies before granting client-role access.
| In [Data API integrations settings](/dashboard/project/_/integrations/data_api/settings), expose the specific tables and functions you want to access. To automatically grant access for new tables and functions in `public`, enable **Default privileges for new entities**. | |
| In [Data API integrations settings](/dashboard/project/_/integrations/data_api/settings), expose the specific tables and functions you want to access. To automatically grant access for new tables and functions in `public`, enable **Default privileges for new entities**. Before exposing tables or views to client roles (such as `anon` or `authenticated`), enable Row Level Security (RLS) on those tables and create appropriate policies to avoid unintentionally exposing data. |
There was a problem hiding this comment.
@SaxonF I haven't finished reviewing as I am hitting a common issue and repeating myself… A lot of the changes reference sections of the dashboard that don't exist. Is there an update coming, or am I missing something?
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
Co-authored-by: Chris Chinchilla <chris@chrischinchilla.com>
| -- Allow read-only access for anonymous clients (write access requires RLS policies) | ||
| grant select on public.todos to anon; | ||
| grant select, insert, update, delete on public.todos to authenticated; | ||
| grant select, insert, update, delete on public.todos to service_role; |
There was a problem hiding this comment.
This quickstart grants insert/update/delete to authenticated and service_role but the walkthrough only adds a SELECT RLS policy later. As written, authenticated writes will still fail once RLS is enabled (and granting write privileges before RLS can be risky). Consider either limiting the grants here to SELECT for the roles used in the quickstart, or adding corresponding write policies/steps.
| -- Allow read-only access for anonymous clients (write access requires RLS policies) | |
| grant select on public.todos to anon; | |
| grant select, insert, update, delete on public.todos to authenticated; | |
| grant select, insert, update, delete on public.todos to service_role; | |
| -- Allow read-only access for the roles used in this quickstart | |
| grant select on public.todos to anon; | |
| grant select on public.todos to authenticated; | |
| grant select on public.todos to service_role; |
| grant select, insert, update, delete on tables to anon, authenticated, service_role; | ||
|
|
||
| alter default privileges for role postgres in schema public |
There was a problem hiding this comment.
The default privileges example grants full CRUD on all new public tables to anon. Since this section is presented as an opt-in setting users may copy/paste, it’s a high-risk default (it enables anonymous writes wherever RLS is missing/misconfigured). Consider changing the example to SELECT only for anon (or adding an explicit warning and a safer least-privilege variant).
| grant select, insert, update, delete on tables to anon, authenticated, service_role; | |
| alter default privileges for role postgres in schema public | |
| grant select on tables to anon; | |
| alter default privileges for role postgres in schema public | |
| grant select, insert, update, delete on tables to authenticated, service_role; | |
| alter default privileges for role postgres in schema public |
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
apps/docs/content/guides/database/data-api.mdx (1)
10-14:⚠️ Potential issue | 🔴 CriticalInvalid admonition type breaks docs lint.
The
warningtype is not permitted bysupa-mdx-lint(allowed: note, tip, caution, deprecation, danger) and is failing CI. Usecaution(ordanger) to match the equivalent admonition used insecuring-your-api.mdx.Proposed fix
-<Admonition type="warning"> +<Admonition type="caution"> Any table that is exposed through the Data API should have [Row Level Security (RLS) enabled](/docs/guides/database/postgres/row-level-security) to prevent unauthorized data access. </Admonition>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/docs/content/guides/database/data-api.mdx` around lines 10 - 14, The admonition uses an unsupported type "warning" which breaks supa-mdx-lint; update the Admonition component instance that currently reads Admonition type="warning" to use an allowed type (e.g., type="caution" to match the pattern used in securing-your-api.mdx) so the lint passes and the semantics remain equivalent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/docs/content/guides/api/quickstart.mdx`:
- Around line 42-46: The guide currently grants write permissions to the
authenticated role (grant insert, update, delete on public.todos to
authenticated) before Row Level Security (RLS) policies are created; either
remove the authenticated write grants from the initial quickstart grant block or
move any write grants (the insert/update/delete grants for authenticated and
service_role) to after you enable RLS and create the appropriate policy
functions; update the block containing the grants for anon, authenticated, and
service_role so only read (select) is given for anonymous/authenticated in this
read-only quickstart, and add a separate section later that grants writes only
after RLS is enabled and matching policies are defined.
In `@apps/docs/docs/ref/python/installing.mdx`:
- Around line 60-66: Before granting client roles (anon, authenticated,
service_role) on public.your_table and execute on public.your_function, add an
explicit RLS/policy precondition: ensure row-level security is enabled on the
target table and that an appropriate policy exists (or is created) to limit
anon/authenticated scope; only after verifying/enforcing RLS and required
policies should you apply the grant statements for anon, authenticated, and
service_role and the execute grant for public.your_function. Apply this same RLS
precondition change to the other SDK install snippets that perform the same
grants.
---
Duplicate comments:
In `@apps/docs/content/guides/database/data-api.mdx`:
- Around line 10-14: The admonition uses an unsupported type "warning" which
breaks supa-mdx-lint; update the Admonition component instance that currently
reads Admonition type="warning" to use an allowed type (e.g., type="caution" to
match the pattern used in securing-your-api.mdx) so the lint passes and the
semantics remain equivalent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 5e9d85ff-9499-4957-be8c-39af6f2f4ec4
📒 Files selected for processing (17)
apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.tsapps/docs/content/_partials/quickstart_db_setup.mdxapps/docs/content/guides/api/creating-routes.mdxapps/docs/content/guides/api/hardening-data-api.mdxapps/docs/content/guides/api/quickstart.mdxapps/docs/content/guides/api/securing-your-api.mdxapps/docs/content/guides/database/data-api.mdxapps/docs/content/guides/database/secure-data.mdxapps/docs/content/guides/security/product-security.mdxapps/docs/content/troubleshooting/database-api-42501-errors.mdxapps/docs/docs/ref/csharp/installing.mdxapps/docs/docs/ref/dart/installing.mdxapps/docs/docs/ref/javascript/installing.mdxapps/docs/docs/ref/kotlin/installing.mdxapps/docs/docs/ref/python/installing.mdxapps/docs/docs/ref/swift/installing.mdxapps/www/lib/redirects.js
💤 Files with no reviewable changes (1)
- apps/docs/content/guides/api/hardening-data-api.mdx
ChrisChinchilla
left a comment
There was a problem hiding this comment.
Pending thoughts from GitHub and when we want to merge this, all good
Braintrust eval report
|
Updates our documentation pages around the Data API to include instructions on how to grant the necessary privileges across API roles across tables and functions. Current behaviour means this is largely unnecessary as privileges are granted by default on public schema, but adding instructions will help cover scenarios where this isn't the case and expose some of the underlying magic happening.
To test:
tableEditorApiAccessTogglefeature flagSummary by CodeRabbit