@nextblock-cms/db 0.22.1 → 0.22.3

package/supabase/migrations/02024_advisor_trigger_grants_and_pg_net_schema.sql

@@ -0,0 +1,113 @@
+-- 02024: clear the Supabase Security Advisor warnings that came back after the 02022/02023
+-- deploys, and move a `pg_net` that was installed in `public` into `extensions`.
+--
+-- Why the SECURITY DEFINER warnings (lints 0028/0029) returned
+--   02013 revoked anon/authenticated EXECUTE on the two SECURITY DEFINER trigger functions
+--   (handle_new_user(), update_product_ratings()) and the advisor was clean. But every
+--   production build runs apps/nextblock/tools/build-migrate.mjs, whose migrate-core.mjs
+--   ends with a blanket `grant execute on all functions in schema public to anon,
+--   authenticated, service_role` and, unlike lib/setup/schema-apply.ts (the /setup path),
+--   had no pass taking that EXECUTE back off trigger functions or re-applying the API-role
+--   revokes of 02021/02022. So each deploy silently handed the privilege back. The hook is
+--   fixed in the same change (and a test now keeps the two files' SQL identical); this
+--   migration repairs the databases that were already re-granted. Postgres checks EXECUTE
+--   on a trigger function only at CREATE TRIGGER time, never when the trigger fires, and
+--   PostgREST cannot call a `RETURNS trigger` function via /rpc, so nothing loses access.
+--
+-- Why `pg_net` (lint 0014, "Extension in Public")
+--   A bare `create extension pg_net` lands in `public` (the first search_path entry), which
+--   exposes its objects through the API schema. pg_net is NOT relocatable, so the lint's
+--   `alter extension … set schema` is refused; the only way out is drop + re-create WITH
+--   SCHEMA extensions. Its own objects live in the `net` schema either way; only the
+--   extension's registration moves, and the request queue / response log are transient.
+--   pg_cron job commands are plain text (no dependency), so a scheduled `net.http_get`
+--   keeps working. Guarded: a database without pg_net, or with it already outside
+--   `public`, is untouched. Same statement tools/scripts/schedule-sandbox-reset.js runs.
+--
+-- Everything here is idempotent and safe on a fresh install, the sandbox replay and a
+-- /setup-installed database. The two Auth-dashboard warnings (leaked password protection,
+-- MFA options) are project settings, not schema, and are not addressed here.
+
+-- ---------------------------------------------------------------------------
+-- 1. Trigger functions: the API roles never need EXECUTE
+--    (identical to the post-apply pass in migrate-core.mjs / schema-apply.ts)
+-- ---------------------------------------------------------------------------
+do $nb_trg$
+declare r record;
+begin
+  for r in
+    select p.oid::regprocedure as sig
+      from pg_proc p
+      join pg_type t on t.oid = p.prorettype
+     where p.pronamespace = 'public'::regnamespace and t.typname = 'trigger'
+  loop
+    execute format('revoke execute on function %s from public, anon, authenticated', r.sig);
+  end loop;
+end $nb_trg$;
+
+-- The two the advisor names, stated explicitly so the intent survives a grep (02013 parity).
+REVOKE EXECUTE ON FUNCTION public.handle_new_user() FROM PUBLIC, anon, authenticated;
+GRANT EXECUTE ON FUNCTION public.handle_new_user() TO service_role;
+
+REVOKE EXECUTE ON FUNCTION public.update_product_ratings() FROM PUBLIC, anon, authenticated;
+GRANT EXECUTE ON FUNCTION public.update_product_ratings() TO service_role;
+
+-- ---------------------------------------------------------------------------
+-- 2. The API-role revokes of 02021 / 02022 that the same blanket grant handed back
+--    (identical to API_ROLE_REVOKE_SQL in migrate-core.mjs / schema-apply.ts)
+-- ---------------------------------------------------------------------------
+do $nb_api$
+begin
+  revoke truncate on all tables in schema public from anon, authenticated;
+  if to_regprocedure('public.generate_order_invoice_number()') is not null then
+    revoke execute on function public.generate_order_invoice_number() from public, anon, authenticated;
+  end if;
+  if to_regprocedure('public.assign_order_invoice_metadata(uuid, timestamp with time zone)') is not null then
+    revoke execute on function public.assign_order_invoice_metadata(uuid, timestamp with time zone) from public, anon, authenticated;
+  end if;
+  if to_regclass('public.order_invoice_number_seq') is not null then
+    revoke all on sequence public.order_invoice_number_seq from anon, authenticated;
+  end if;
+  if to_regprocedure('public.upsert_product_with_variants(jsonb)') is not null then
+    revoke execute on function public.upsert_product_with_variants(jsonb) from public, anon;
+  end if;
+  if to_regprocedure('public.bump_email_2fa_attempts(uuid)') is not null then
+    revoke execute on function public.bump_email_2fa_attempts(uuid) from public, anon, authenticated;
+  end if;
+  if to_regprocedure('public.redeem_coupon_atomically(uuid)') is not null then
+    revoke execute on function public.redeem_coupon_atomically(uuid) from public, anon, authenticated;
+  end if;
+end $nb_api$;
+
+-- ---------------------------------------------------------------------------
+-- 3. pg_net out of `public` (not relocatable: drop + re-create WITH SCHEMA extensions)
+-- ---------------------------------------------------------------------------
+do $nb_pg_net$
+declare
+  v_version text;
+begin
+  select e.extversion
+    into v_version
+    from pg_extension e
+   where e.extname = 'pg_net'
+     and e.extnamespace = 'public'::regnamespace;
+
+  if v_version is null then
+    return; -- not installed, or already registered outside public
+  end if;
+
+  if to_regnamespace('extensions') is null then
+    raise notice '02024: pg_net % is registered in schema public and this database has no extensions schema; reinstall it by hand with `create extension pg_net with schema <schema>`', v_version;
+    return;
+  end if;
+
+  -- The pg_net worker holds net.http_request_queue while a request is in flight. Fail fast
+  -- rather than queue behind it; re-running the migration is cheap.
+  perform set_config('lock_timeout', '15s', true);
+
+  drop extension pg_net;
+  create extension pg_net with schema extensions;
+
+  raise notice '02024: pg_net re-registered in schema extensions (was % in public, now %)',
+    v_version, (select extversion from pg_extension where extname = 'pg_net');
+end $nb_pg_net$;

package/supabase/migrations/02025_api_role_grant_hardening.sql

@@ -0,0 +1,66 @@
+-- 02025: grant-level hardening for the API roles (2026-10-21 posture review of 02021-02024).
+--
+-- Grants decide whether a role may touch a table at all; RLS decides which rows. This file
+-- removes three places where RLS had become the only barrier. It changes no row a legitimate
+-- request can reach: every statement below takes away a privilege that no RLS policy lets the
+-- role use.
+--
+-- 1. anon is read-only at the grant level.
+--    Supabase's historical default privileges, and the baseline (02003), granted anon
+--    INSERT/UPDATE/DELETE/REFERENCES/TRIGGER on every table in `public`. No policy in the
+--    schema lets anon write anything (checked against pg_policies on 2026-10-21: zero
+--    INSERT/UPDATE/DELETE/ALL policies reach anon or PUBLIC), so those grants only meant that
+--    a single permissive policy added by mistake would publish a table for writing to anyone
+--    with the public key. Every anonymous write path in the app (forms, consent, comments,
+--    checkout) already goes through a server route with the service role. Sequence USAGE and
+--    UPDATE go too: without INSERT, anon never draws a value.
+--
+-- 2. cortex_request_log is service-role only again.
+--    02022 created it with REVOKE ALL FROM anon, authenticated and no API policy. The
+--    post-apply pass of both apply paths (lib/setup/schema-apply.ts and the build hook in
+--    tools/lib/migrate-core.mjs) then ran `grant all on all tables ... to authenticated` and
+--    `grant select ... to anon` on every deploy, handing the table back to both roles. RLS
+--    still returned no row, but a signed-in WRITER could issue DELETEs against the counter
+--    that rate-limits the AI routes, and tools/scripts/security-verify.sql failed three checks
+--    on any deployed database. Both apply paths now repeat this revoke (API_ROLE_REVOKE_SQL).
+--
+-- 3. profiles.role is pinned by grants, not only by policy and trigger.
+--    The column was protected by profiles_update_policy's WITH CHECK and the
+--    protect_profile_role trigger (02021). authenticated now holds INSERT and UPDATE on every
+--    profiles column EXCEPT `role` (and `id` on UPDATE), so a policy regression can no longer
+--    reopen self-promotion to ADMIN. User-session writes only ever touch full_name,
+--    avatar_url, website, phone and updated_at (account page, checkout autofill); role changes
+--    go through the service role in app/cms/users/actions.ts, which these grants do not
+--    affect. DELETE, REFERENCES and TRIGGER on profiles are revoked from the API roles: no
+--    policy grants DELETE to them and account deletion runs through auth.admin. The column
+--    list is read from the catalog so a column added later keeps today's behaviour.
+--
+-- Both apply paths repeat all three after their blanket grants, so a deploy cannot undo
+-- them; tools/scripts/security-verify.sql asserts them. Idempotent: safe to re-run.
+
+-- 1. anon: read-only at the grant level
+REVOKE INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER ON ALL TABLES IN SCHEMA public FROM anon;
+REVOKE USAGE, UPDATE ON ALL SEQUENCES IN SCHEMA public FROM anon;
+
+-- 2. cortex_request_log: service_role only (its SELECT, INSERT, DELETE grant from 02022 stays)
+REVOKE ALL ON TABLE public.cortex_request_log FROM PUBLIC, anon, authenticated;
+
+-- 3. profiles: every column but `role` (and `id` on UPDATE) for authenticated
+DO $nb_profiles$
+DECLARE
+  v_insert_cols text;
+  v_update_cols text;
+BEGIN
+  SELECT string_agg(quote_ident(a.attname), ', ' ORDER BY a.attnum) FILTER (WHERE a.attname <> 'role'),
+         string_agg(quote_ident(a.attname), ', ' ORDER BY a.attnum) FILTER (WHERE a.attname NOT IN ('id', 'role'))
+    INTO v_insert_cols, v_update_cols
+    FROM pg_attribute a
+   WHERE a.attrelid = 'public.profiles'::regclass AND a.attnum > 0 AND NOT a.attisdropped;
+
+  -- Revoking the table-level privilege also revokes every column-level grant of that kind,
+  -- so the column grants below are the complete list afterwards.
+  REVOKE INSERT, UPDATE, DELETE, REFERENCES, TRIGGER ON TABLE public.profiles FROM PUBLIC, anon, authenticated;
+  EXECUTE format('GRANT INSERT (%s) ON TABLE public.profiles TO authenticated', v_insert_cols);
+  EXECUTE format('GRANT UPDATE (%s) ON TABLE public.profiles TO authenticated', v_update_cols);
+END
+$nb_profiles$;

package/supabase/migrations/02026_authenticated_write_grant_hardening.sql

@@ -0,0 +1,91 @@
+-- 02026: authenticated holds no table write privilege that no RLS policy lets it use
+-- (2026-10-21, the follow-up 02025 left open).
+--
+-- 02025 made anon read-only at the grant level. authenticated still held SELECT, INSERT,
+-- UPDATE, DELETE, REFERENCES and TRIGGER on every table in `public` (the baseline 02003, then
+-- `grant all on all tables in schema public to authenticated` in the post-apply pass on every
+-- deploy). On the tables below RLS was the only barrier between a signed-in session and a
+-- write: no permissive policy for authenticated or PUBLIC covers the listed commands, only a
+-- `TO service_role` policy or none at all. Every app write to them runs server-side with the
+-- service role after its own checks: 2FA challenges, trusted devices and security settings
+-- (lib/auth, settings/security), consent logs, contact-seller enquiries and message threads,
+-- UCP carts, coupon redemptions (checkout providers), license activations (lib/packages),
+-- the Freemius catalog sync, the update checker's alerts and Cortex's mutation audit.
+--
+-- Behaviour-neutral by construction: authenticated could never use a revoked privilege. Its
+-- INSERT failed the RLS check and its UPDATE or DELETE matched no row; now the grant refuses
+-- the statement before RLS is consulted, and no row any request reaches changes. (One CMS
+-- action, updateFreemiusOverride in libs/ecommerce, updates freemius_pricing through the
+-- cookie client: RLS has always discarded that UPDATE while the action reported success, and
+-- it now reports the permission error instead.) Every command that has a policy keeps its
+-- grant: the ADMIN UPDATE on message_threads, product_inquiries and system_alerts, the ADMIN
+-- INSERT on site_script_revisions, the owner DELETE on user_trusted_devices, and every SELECT.
+-- The pre-flight block re-checks that against pg_policies on the target database and aborts
+-- without changing anything if a policy has appeared since this list was taken (a replay
+-- through 02025 plus the post-apply pass, 2026-10-21).
+--
+-- REFERENCES and TRIGGER go from every table, as 02025 did for anon: they only let a role
+-- create a foreign key or a trigger, and no API request runs DDL. Foreign-key actions are not
+-- affected by any of this: ON DELETE CASCADE / SET NULL run as the owner of the referencing
+-- table, so an ADMIN deleting a product still removes its freemius_plans and freemius_pricing
+-- rows, and deleting an order still removes its coupon_redemptions.
+--
+-- Both apply paths repeat these revokes after their blanket grants (API_ROLE_REVOKE_SQL). To
+-- give authenticated one of these privileges later, add the policy and the GRANT in the same
+-- migration and take the table out of both copies of that list, or the next deploy revokes it
+-- again. tools/scripts/security-verify.sql sections 26-27 fail on a write grant no policy uses
+-- and on a write policy whose grant is missing. Idempotent: safe to re-run.
+
+DO $nb_preflight$
+DECLARE
+  offenders text;
+BEGIN
+  SELECT string_agg(format('%s %s (policy %s)', l.tbl, r.cmd, p.policyname), ', ' ORDER BY l.tbl, r.cmd, p.policyname)
+    INTO offenders
+    FROM (VALUES
+      ('cortex_ai_db_mutation_audit', ARRAY['INSERT', 'UPDATE', 'DELETE']),
+      ('coupon_redemptions',          ARRAY['INSERT', 'UPDATE', 'DELETE']),
+      ('email_2fa_challenges',        ARRAY['INSERT', 'UPDATE', 'DELETE']),
+      ('freemius_plans',              ARRAY['INSERT', 'UPDATE', 'DELETE']),
+      ('freemius_pricing',            ARRAY['INSERT', 'UPDATE', 'DELETE']),
+      ('package_activations',         ARRAY['INSERT', 'UPDATE', 'DELETE']),
+      ('privacy_consent_logs',        ARRAY['INSERT', 'UPDATE', 'DELETE']),
+      ('thread_messages',             ARRAY['INSERT', 'UPDATE', 'DELETE']),
+      ('ucp_cart_sessions',           ARRAY['INSERT', 'UPDATE', 'DELETE']),
+      ('user_security_settings',      ARRAY['INSERT', 'UPDATE', 'DELETE']),
+      ('message_threads',             ARRAY['INSERT', 'DELETE']),
+      ('product_inquiries',           ARRAY['INSERT', 'DELETE']),
+      ('system_alerts',               ARRAY['INSERT', 'DELETE']),
+      ('site_script_revisions',       ARRAY['UPDATE', 'DELETE']),
+      ('user_trusted_devices',        ARRAY['INSERT', 'UPDATE'])
+    ) AS l(tbl, cmds)
+    CROSS JOIN LATERAL unnest(l.cmds) AS r(cmd)
+    JOIN pg_policies p
+      ON p.schemaname = 'public' AND p.tablename = l.tbl
+     AND p.permissive = 'PERMISSIVE' AND p.cmd IN (r.cmd, 'ALL')
+     AND p.roles && ARRAY['authenticated', 'public']::name[];
+  IF offenders IS NOT NULL THEN
+    RAISE EXCEPTION '02026 would revoke a privilege that an RLS policy lets authenticated use: %. Nothing was changed; drop that table/command from this file and from API_ROLE_REVOKE_SQL, or drop the policy.', offenders;
+  END IF;
+END
+$nb_preflight$;
+
+-- 1. writes that no policy lets authenticated use
+REVOKE INSERT, UPDATE, DELETE ON TABLE
+  public.cortex_ai_db_mutation_audit,
+  public.coupon_redemptions,
+  public.email_2fa_challenges,
+  public.freemius_plans,
+  public.freemius_pricing,
+  public.package_activations,
+  public.privacy_consent_logs,
+  public.thread_messages,
+  public.ucp_cart_sessions,
+  public.user_security_settings
+  FROM authenticated;
+REVOKE INSERT, DELETE ON TABLE public.message_threads, public.product_inquiries, public.system_alerts FROM authenticated;
+REVOKE UPDATE, DELETE ON TABLE public.site_script_revisions FROM authenticated;
+REVOKE INSERT, UPDATE ON TABLE public.user_trusted_devices FROM authenticated;
+
+-- 2. REFERENCES / TRIGGER: DDL-only, unused by every API request
+REVOKE REFERENCES, TRIGGER ON ALL TABLES IN SCHEMA public FROM authenticated;

package/supabase/migrations/02027_api_role_select_grant_hardening.sql

@@ -0,0 +1,150 @@
+-- 02027: anon and authenticated hold SELECT only where an RLS policy lets them read
+-- (2026-10-21, the read side of 02025/02026).
+--
+-- 02025 made anon read-only and 02026 left authenticated only the writes some policy uses.
+-- SELECT was still granted to both roles on every table in `public` (the baseline 02003, then
+-- `grant select on all tables in schema public to anon` and `grant all ... to authenticated` in
+-- the post-apply pass on every deploy). On the tables below no permissive SELECT or ALL policy
+-- reaches the role (or PUBLIC), so RLS was the only barrier between the public key and orders,
+-- profiles, coupons, licenses, MCP tokens, revisions, drafts, 2FA challenges, carts and
+-- messages: one permissive policy added by mistake, or a table created with RLS off, would
+-- have published it to anyone holding that key.
+--
+--   anon: every table that only staff, an owner or the service role reads (29, listed below).
+--   authenticated: email_2fa_challenges and ucp_cart_sessions, whose only policy is TO
+--     service_role (lib/auth/twoFactor and the UCP routes read them with the service role;
+--     02026 already took authenticated's writes on both).
+--   profile_cards (02021): anon loses SELECT, authenticated loses INSERT/UPDATE/DELETE. It is a
+--     security_invoker view over profiles, so anon could only ever read it through a SELECT on
+--     profiles, which goes here. The public author card does not read the view: author()
+--     returns its row type from private.author_card(), a SECURITY DEFINER function, so
+--     `cms_interactions?select=*,author(full_name,avatar_url)` keeps working for anon (checked
+--     through PostgREST on 2026-10-21). The view is a read card; nothing writes through it.
+--
+-- Unlike a write, a SELECT can be needed on a table the request never names: a policy
+-- subquery (`EXISTS (SELECT ... FROM x)`), a security_invoker view, an invoker function or a
+-- PostgREST embed (`select=*,x(...)`) all read x as the calling role, and they fail with 42501
+-- once the grant is gone, where RLS used to return no row (or a null embed). The census behind
+-- this list (a replay through 02026 plus the post-apply pass, 2026-10-21) found:
+--   - one policy that reads another of these tables, order_items' owner policy (orders): it is
+--     TO authenticated, which keeps SELECT on orders;
+--   - one view, profile_cards (above);
+--   - invoker functions reading them: apply_order_inventory_deduction (orders, order_items),
+--     called by the app only with the service role and already refused to anon by its
+--     SELECT ... FOR UPDATE since 02025 (FOR UPDATE needs UPDATE), and the trigger functions of
+--     site_script_revisions / thread_messages, which fire only on writes anon cannot make;
+--   - no anonymous query in the app (getSsgSupabaseClient, the browser client, the cookie client
+--     on signed-out paths) embeds a listed table; the public author card goes through author().
+--     The anonymous paths that need one of these tables (checkout success, order access tokens,
+--     contact seller, threads, consent, forms, UCP, MCP tokens, the sign-up read of
+--     system_configuration) read it with the service role after their own checks. The few
+--     cookie-client reads a signed-out request can reach (a draft lookup in draft mode or with
+--     NEXTBLOCK_VISUAL_EDITING_ENABLED, verifyPackageOnline on an install with no service key,
+--     the MCP route's revision capture, a custom block's `profiles` relation) already got no
+--     row and handle the error the same way: no draft, not licensed, no revision, no record.
+-- Behaviour-neutral for every request that worked: an anon or authenticated read of a listed
+-- table returned no row before and is refused by the grant now. The pre-flight block re-checks
+-- the catalog side on the target database and aborts without changing anything if a policy
+-- lets the role read a listed table, if a policy the role is subject to reads one, or if a view
+-- the role can read depends on one.
+--
+-- Both apply paths repeat these revokes after their blanket grants (API_ROLE_REVOKE_SQL). To let
+-- one of these roles read a listed table later, add the policy and GRANT SELECT in the same
+-- migration and take the table out of both copies of that list, or the next deploy revokes it
+-- again. tools/scripts/security-verify.sql sections 28-29 fail on a SELECT grant no policy uses
+-- and on a read policy whose grant is missing. Idempotent: safe to re-run.
+
+DO $nb_preflight$
+DECLARE
+  offenders text;
+BEGIN
+  WITH l(role, tbl) AS (
+    SELECT 'anon'::name, t
+      FROM unnest(ARRAY[
+        'content_drafts', 'cortex_ai_db_mutation_audit', 'coupon_freemius_mappings',
+        'coupon_products', 'coupon_redemptions', 'coupons', 'email_2fa_challenges',
+        'form_endpoints', 'mcp_access_tokens', 'message_threads', 'order_items', 'orders',
+        'package_activations', 'page_revisions', 'post_revisions', 'privacy_consent_logs',
+        'product_drafts', 'product_freemius_sale_coupons', 'product_inquiries',
+        'product_revisions', 'profile_cards', 'profiles', 'site_script_revisions',
+        'system_alerts', 'system_configuration', 'thread_messages', 'ucp_cart_sessions',
+        'user_addresses', 'user_security_settings', 'user_trusted_devices']::name[]) AS t
+    UNION ALL
+    SELECT 'authenticated'::name, t
+      FROM unnest(ARRAY['email_2fa_challenges', 'ucp_cart_sessions']::name[]) AS t
+  ), r AS (
+    SELECT l.role, l.tbl, to_regclass('public.' || quote_ident(l.tbl)) AS oid FROM l
+  ), hits(what) AS (
+    -- a policy that lets the role read a listed table
+    SELECT format('%s reads %s through policy %s', r.role, r.tbl, p.policyname)
+      FROM r
+      JOIN pg_policies p
+        ON p.schemaname = 'public' AND p.tablename = r.tbl
+       AND p.permissive = 'PERMISSIVE' AND p.cmd IN ('SELECT', 'ALL')
+       AND p.roles && ARRAY[r.role, 'public']::name[]
+    UNION ALL
+    -- a policy the role is subject to, on any other table, whose expression reads a listed table
+    SELECT format('policy %s on %s reads %s as %s', pol.polname, pol.polrelid::regclass, r.tbl, r.role)
+      FROM r
+      JOIN pg_depend d
+        ON d.classid = 'pg_policy'::regclass AND d.refclassid = 'pg_class'::regclass AND d.refobjid = r.oid
+      JOIN pg_policy pol ON pol.oid = d.objid
+     WHERE pol.polrelid <> r.oid
+       AND (0::oid = ANY (pol.polroles) OR (SELECT oid FROM pg_roles WHERE rolname = r.role) = ANY (pol.polroles))
+    UNION ALL
+    -- a view the role keeps SELECT on that reads a listed table
+    SELECT format('view %s reads %s and stays readable by %s', rw.ev_class::regclass, r.tbl, r.role)
+      FROM r
+      JOIN pg_depend d
+        ON d.classid = 'pg_rewrite'::regclass AND d.refclassid = 'pg_class'::regclass AND d.refobjid = r.oid
+      JOIN pg_rewrite rw ON rw.oid = d.objid
+     WHERE rw.ev_class <> r.oid
+       AND has_table_privilege(r.role, rw.ev_class, 'SELECT')
+       AND NOT EXISTS (SELECT 1 FROM r r2 WHERE r2.role = r.role AND r2.oid = rw.ev_class)
+  )
+  SELECT string_agg(DISTINCT what, '; ') INTO offenders FROM hits;
+  IF offenders IS NOT NULL THEN
+    RAISE EXCEPTION '02027 would revoke a SELECT that a request still needs: %. Nothing was changed; drop that table from this file and from API_ROLE_REVOKE_SQL, or change the policy or view.', offenders;
+  END IF;
+END
+$nb_preflight$;
+
+-- 1. anon: SELECT on every table no policy lets anon read
+REVOKE SELECT ON TABLE
+  public.content_drafts,
+  public.cortex_ai_db_mutation_audit,
+  public.coupon_freemius_mappings,
+  public.coupon_products,
+  public.coupon_redemptions,
+  public.coupons,
+  public.email_2fa_challenges,
+  public.form_endpoints,
+  public.mcp_access_tokens,
+  public.message_threads,
+  public.order_items,
+  public.orders,
+  public.package_activations,
+  public.page_revisions,
+  public.post_revisions,
+  public.privacy_consent_logs,
+  public.product_drafts,
+  public.product_freemius_sale_coupons,
+  public.product_inquiries,
+  public.product_revisions,
+  public.profiles,
+  public.site_script_revisions,
+  public.system_alerts,
+  public.system_configuration,
+  public.thread_messages,
+  public.ucp_cart_sessions,
+  public.user_addresses,
+  public.user_security_settings,
+  public.user_trusted_devices
+  FROM anon;
+
+-- 2. authenticated: the two tables only the service role reads
+REVOKE SELECT ON TABLE public.email_2fa_challenges, public.ucp_cart_sessions FROM authenticated;
+
+-- 3. profile_cards: a read card for staff and owners (through profiles' policies)
+REVOKE SELECT ON TABLE public.profile_cards FROM anon;
+REVOKE INSERT, UPDATE, DELETE ON TABLE public.profile_cards FROM authenticated;