Why the database is the lock

A Supabase app ships a publishable key (called the anon key on older projects) inside the web page. That is by design: the key only identifies your project. Anyone can copy it from the browser and call your database's API directly, without your screens ^[1]. So hiding a button protects nothing. What protects the data is row-level security (RLS): a rule Postgres applies to every query, for the person making it ^[2][3].

Default deny, built into Postgres

Postgres has default deny built in. When RLS is turned on for a table and no policy grants access, nobody but the table's owner sees a single row ^[2]. Every grant is then a policy: a condition that must be true for a row to be read, added, changed or removed. If no policy grants it, the action is refused.

From the matrix to policies

Session 6 builds the full Role and Exposure Matrix. Today you write the first rows by hand for the stamping plant's tables: who may read and add inspections and holds, per site. Each cell that grants something becomes one policy. Each empty cell becomes nothing at all, and is therefore refused.

-- Who belongs to which site, with which role. People read only their own rows here.
create table public.memberships (
  user_id uuid not null references auth.users(id) on delete cascade,
  site_id bigint not null references public.sites(id),
  role    text not null check (role in ('operator', 'quality_lead', 'manager')),
  primary key (user_id, site_id)
);
alter table public.memberships enable row level security;
create policy "read own memberships" on public.memberships
  for select to authenticated using (user_id = (select auth.uid()));

-- Inspections: members of the site read them; operators and quality leads add them.
alter table public.inspections enable row level security;
create policy "site members read inspections" on public.inspections
  for select to authenticated
  using (site_id in (select site_id from public.memberships where user_id = (select auth.uid())));
create policy "operators and leads add inspections" on public.inspections
  for insert to authenticated
  with check (site_id in (select site_id from public.memberships
                          where user_id = (select auth.uid()) and role in ('operator', 'quality_lead')));
-- No update or delete policy: an inspection, once recorded, is corrected by a new row.

Two details from Supabase's guidance matter here: name the role the policy applies to (to authenticated), so it never runs for strangers, and wrap auth.uid() in a select so Postgres works it out once per query rather than once per row ^[3].

Prove it in the SQL editor

You do not have to trust a policy; you can test it. In the Supabase SQL editor, these queries run as a stranger and as a test user, inside a transaction that is rolled back so nothing changes. The first query lists every table that still has RLS off; the answer must be empty.

-- 1. Tables in the public schema with row-level security OFF. Must return no rows.
select c.relname as table_without_rls
from pg_class c join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r' and not c.relrowsecurity;

-- 2. As a stranger (the publishable key, nobody signed in): must return 0.
begin;
set local role anon;
select count(*) from public.inspections;
rollback;

-- 3. As the test operator you invited (Authentication, Users): only their site's rows.
begin;
set local role authenticated;
select set_config('request.jwt.claims',
  json_build_object('sub', (select id from auth.users where email = 'operator.test@example.com'), 'role', 'authenticated')::text, true);
select site_id, count(*) from public.inspections group by site_id;
rollback;

Who can have an account

A plant platform is not a public website. Nobody should be able to create an account by visiting the sign-in page. In the Supabase dashboard, under Authentication, turn off Allow new users to sign up; from then on people get accounts only when you invite them ^[1]. This one switch closes a whole class of attack: there is no account for a stranger to make.

Deny by default, at the front door

Every request to your app passes a guard before any page is built. In a Next.js app this is a single file at the root of the project (Next.js 16 names it proxy.ts; earlier versions called it middleware.ts) ^[2]. The guard asks four questions in order, and any 'no' stops the request.

The key design choice is the list. An allow-list names the few pages anyone may see (the home page, sign-in, the link people click in an invitation) and closes the rest. A block-list names pages to protect and leaves the rest open. The OWASP Authorization Cheat Sheet recommends denying by default for exactly the reason below ^[3].

// proxy.ts (outline): every request comes here first.
// The few public pages are listed; everything else needs a signed-in user.
const PUBLIC = new Set(["/", "/sign-in", "/auth/callback"]);

export async function proxy(request) {
  if (PUBLIC.has(request.nextUrl.pathname)) return next();          // 1. public page
  const user = await currentUser(request);                          // 2. signed in? (Supabase checks the token)
  if (!user) return redirectTo("/sign-in", request);                //    no: go and sign in
  if (!allowed(user.role, request.nextUrl.pathname))                // 3-4. fresh session, role allowed by the matrix
    return new Response("Not allowed", { status: 403 });
  return next();
}

Sessions and two-step sign-in

NIST's digital identity guidelines and OWASP both say the same things about sessions: they expire, they end at sign-out, and the people who can change important data prove who they are with a second factor ^[5][6]. For a plant platform, that means:

Supabase supports two-step sign-in with an authenticator app (time-based one-time passwords) at no extra cost on every plan ^[7]. Turn it on for the roles that can hold or release a lot. Operators on shared tablets get short sessions instead, because a code on a phone is impractical in gloves.

The ten risks

The OWASP Top 10 is the most widely used list of the most serious web application security risks, revised from real-world data; the 2025 edition is the current one ^[1]. It is a starting point, not a complete standard: the OWASP Application Security Verification Standard (ASVS) is the detailed checklist when you need one, and the Web Security Testing Guide shows how to test each item ^[2][3].

The first tests

Your AI agent writes these in a pull request; you read them before merging. They need no special tools: Node's built-in test runner and fetch are enough. The addresses and keys come from environment variables that you type into GitHub's Actions secrets yourself, never into a chat or a file.

// tests/security.test.mjs  (run with: node --test)
import test from "node:test";
import assert from "node:assert/strict";
const BASE = process.env.BASE_URL;                 // the preview address under test
const API = process.env.SUPABASE_URL, KEY = process.env.SUPABASE_PUBLISHABLE_KEY;

test("A01: a stranger asking for a private page is sent to sign in", async () => {
  const r = await fetch(BASE + "/holds", { redirect: "manual" });
  assert.ok([302, 303, 307].includes(r.status));
  assert.match(r.headers.get("location") || "", /\/sign-in/);
});

test("A01: the publishable key alone reads no inspections", async () => {
  const r = await fetch(API + "/rest/v1/inspections?select=id", { headers: { apikey: KEY } });
  assert.deepEqual(await r.json(), []);
});

test("A02: public sign-up is closed", async () => {
  const r = await fetch(API + "/auth/v1/signup", { method: "POST", headers: { apikey: KEY, "content-type": "application/json" },
    body: JSON.stringify({ email: "stranger@example.com", password: "a-long-test-password-123" }) });
  assert.ok(r.status >= 400, "a stranger could create an account");
});

test("A02: security headers are set", async () => {
  const r = await fetch(BASE + "/");
  assert.ok(r.headers.get("content-security-policy"), "no Content-Security-Policy");
  assert.equal(r.headers.get("x-content-type-options"), "nosniff");
});

The header test checks for a Content Security Policy, which tells the browser which scripts may run and so blunts cross-site scripting ^[6]. Add tests for the other categories one pull request at a time; the table above gives the test for each.

Make the tests the referee

The tests only protect you if a failing one stops the merge. Session 1 protected main so that pull requests must pass CI; add the security tests to that CI run. From then on, a change that opens a door, from a person or an agent, turns the pull request red and cannot merge.