DEV Community: TIC

Fix StorageApiError: new row violates RLS on upload

TIC — Wed, 28 Oct 2026 13:30:03 +0000

Your upload was refused by a policy on the storage.objects table, not by the bucket, and making the bucket public does not change that. Four causes cover nearly every case, and the file path you pass to the upload call usually tells you which one you hit.

What you are looking at

StorageApiError: new row violates row-level security policy

What is this error? It is PostgreSQL refusing an insert into storage.objects: every file in Supabase Storage is a row in that table, and an upload is an insert into it. Row level security checks it exactly as it checks an insert into one of your own tables, which is why the message is the same one PostgreSQL raises for a table (that case is on the 42501 page). In Supabase's words: "By default Storage does not allow any uploads to buckets without RLS policies. You selectively allow certain operations by creating RLS policies on the storage.objects table."

Four causes. Check them in this order

There is no insert policy on storage.objects for your role

The bucket exists, the file is fine, and nothing lets a signed-in user insert the row. Supabase: "the only RLS policy required for uploading objects is to grant the INSERT permission to the storage.objects table." This policy lets each signed-in user upload into a folder named after their own user id inside one bucket. Proven on a real PostgreSQL: with it, a user stores a file under their own id and is refused under anyone else's.

create policy "users upload into their own folder"
on storage.objects for insert to authenticated
with check (
  bucket_id = 'avatars'
  and (storage.foldername(name))[1] = (select auth.uid())::text
);

The path you upload to does not match the policy

The policy above compares the first folder of the object's name with the signed-in user's id. An upload to avatar.png with no folder, or to a folder named after a username, an email, or a different id, fails with the same message. Log the path you pass to the upload call: its first segment must be the user id of the session making the request, and the bucket in the call must be the bucket in the policy. You can read how the helper splits a path in your SQL editor:

select (storage.foldername('11111111-1111-1111-1111-111111111111/avatar.png'))[1];

You are overwriting a file (upsert)

Uploading with upsert: true onto a path that already exists turns the insert into an update of the existing row, and that row is checked against your update policies. Supabase: "To allow overwriting files using the upsert functionality you will need to additionally grant SELECT and UPDATE permissions." PostgreSQL says why the error is a refusal and not a silent skip: "unlike a standalone UPDATE command, if the existing row does not pass the USING expressions, an error will be thrown." Proven: the same overwrite is refused while only the insert policy exists and succeeds once these two are added, and the other user's folder stays closed.

create policy "users read their own folder"
on storage.objects for select to authenticated
using (
  bucket_id = 'avatars'
  and (storage.foldername(name))[1] = (select auth.uid())::text
);

create policy "users overwrite their own files"
on storage.objects for update to authenticated
using (
  bucket_id = 'avatars'
  and (storage.foldername(name))[1] = (select auth.uid())::text
)
with check (
  bucket_id = 'avatars'
  and (storage.foldername(name))[1] = (select auth.uid())::text
);

The request is not signed in

The policies say to authenticated, and a request with no session reaches the database as the anonymous role, which they do not cover. Proven: the anonymous role is refused by the same policy that lets the signed-in user through. In the browser, make sure a session exists right before the upload. On the server, the client has to be built from the request's cookies; Supabase: "Use the browser client in code that runs on the browser, and the server client in code that runs on the server." If auth.uid() is null on the request, no folder policy can match; that case has its own page.

Two shortcuts that open the bucket to everyone

Do not allow uploads with with check (true) for every role. It makes the error disappear because it stops checking anything. Proven on a real PostgreSQL: with the policy below in place, a request with no session at all stores an object in the bucket, so anyone holding your public key can fill it.

create policy "anyone can upload"
on storage.objects for insert to anon, authenticated
with check (true);

Do not upload with the service key from the browser. The service role bypasses every policy, which the suite confirms by storing an object with no policy that allows it. Supabase: "Service keys entirely bypass RLS policies, granting you unrestricted access to all Storage APIs. Remember you should not share the service key publicly."

Straight answers

Does making the bucket public fix the upload?

No. A public bucket changes who can read, not who can write. Supabase: "When a bucket is designated as 'Public,' it effectively bypasses access controls for both retrieving and serving files within the bucket." And in the same passage: "Access control is still enforced for other types of operations including uploading, deleting, moving, and copying." Uploads still need an insert policy on storage.objects.

Which policies does a profile photo upload need?

One insert policy on storage.objects for the authenticated role, scoped to the bucket and to a folder named after the user's id. If the app overwrites the photo with upsert, add a select policy and an update policy with the same scope. Nothing else.

The error names a table called objects, and I never created one.

It is Supabase's own table, storage.objects, where every uploaded file is a row. Your policies for uploads go on that table, not on the bucket and not on any table of yours.

One missing policy is rarely alone. Check every table

Our free auditor reads your policies and lists the holes worst first, including the quiet ones that never raise an error. It runs in your own SQL editor in about a minute and never touches your rows.

Get the free RLS auditor

Also seeing 42501 on one of your own tables, or 42P17, infinite recursion detected in policy?

Stuck on an upload that still fails after this? The free RLS Auditor checks your policies read-only, and the RLS Security Pack Launch price USD 11.40 (normal USD 19) for the first 25 buyers or until 2026-10-31, whichever comes first. The code is already in the link. (Gumroad, USD 19) has a tested recipe for each finding.

Originally published with the full SQL and sources at https://ticassociation.com/supabase-storage-upload-row-level-security.

Five questions to ask before you use an AI answer

TIC — Thu, 22 Oct 2026 00:15:00 +0000

AI tools write answers that sound sure, including the wrong ones. You do not need to be technical to catch many of them. Ask these five questions, in this order, in the same chat.

"What would have to be true for this to be wrong?" A good answer names real conditions. A vague one tells you the first answer was weaker than it sounded.
"Which parts are you sure about, and which parts are you guessing?" Mark the guesses and check only those.
"What did you assume about my situation?" Many bad answers are good answers to a question you did not ask. Your country, your budget and your skill level are the usual missing pieces.
"Give me one source I can open myself, and tell me if you are not certain it exists." Then open it. If the link or the title is not real, treat the rest of the answer with care.
"How could I check this in five minutes without you?" A search, a calculator, a phone call, a look at the official page. Do that one thing before you act on the answer.

None of this makes the tool perfect. You stay the one who decides.

We are TIC, a small studio that makes plain-language AI guides (ticassociation.com). The list above is free to copy and share.

Drafted with AI help and approved by a person before posting.

How to read the free limit of an AI tool before you rely on it

TIC — Wed, 21 Oct 2026 00:14:58 +0000

A tool that is free today can stop working for you halfway through a task. Most of the time the limit was written down. Here is the five-minute check we run before building anything on a free plan.

Go to the pricing page, not a review. Reviews often copy old numbers. The tool's own page is the one to trust, and the one you can point to later.
Find the unit. Is the limit in messages, credits, minutes, images or files? Two tools that both say "free" can mean very different amounts of work.
Find the reset period. Per day, per month, or once and never again? A one-time allowance is a trial, not a free plan.
Look for what is left out. The best model, longer files, exports, or commercial use are often excluded from the free tier. Read the line about commercial use before you use the output for a client.
Find out what happens at the limit. It may slow down, switch to a weaker model, stop until the reset, or ask for a card. Know which one before you are in the middle of a task.
Write down the date you checked. Limits change without notice. A note like "checked on 15 Oct: this plan allows N messages a day" is worth more than your memory.
Keep one fallback. Pick a second tool for the same job so a limit becomes a switch, not a stop.

If you do only one thing from this list, do number 6. It turns a guess into something you can recheck in a minute.

We are TIC, a small studio that makes plain-language AI guides (ticassociation.com). The list above is free to copy and share.

Drafted with AI help and approved by a person before posting.

Supabase works locally, not in production: 5 checks

TIC — Sun, 18 Oct 2026 00:13:22 +0000

Your local run and your production deployment differ in five places: the public variables the browser bundle was built with, the URL sign-in returns to, the cookies a server route reads, which key runs where, and whether the hosted database got your migrations. Check them in this order and the cause is usually the first one that fails.

Same code, two different environments

npm run dev, localhost:   works
vercel production:        500, a blank page, "Invalid API key", or sign-in that lands on localhost

What is different in production? Not your code. A production build freezes the public variables into the bundle, the deployment runs with the variables that existed when it was built, sign-in returns to whatever URL your project allows, and a server route only knows the user if the request's cookies reach it. Each of those is a setting, and each has a primary source below.

Five checks. In this order

The public variables were not there when the bundle was built

Anything the browser needs, such as your Supabase URL and publishable key, is prefixed NEXT_PUBLIC_, and Next.js says what that does: "it will be inlined into any JavaScript sent to the browser." And the consequence: "variables will be frozen with the value evaluated at build time, so these values need to be set appropriately when the project is built." So a variable added to the dashboard after the build is not in the bundle. Vercel: "Any change you make to Environment Variables are not applied to previous deployments, they only apply to new deployments." Check: the same names as in your .env.local exist for the Production environment, then redeploy.

Vercel project > Settings > Environment Variables > Production
NEXT_PUBLIC_SUPABASE_URL              set
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY  set       then: Deployments > Redeploy

Sign-in comes back to localhost

Magic links and OAuth return the user to the URL the project allows, and a project that only ever knew http://localhost:3000 sends production users there. Supabase: "we recommend setting the exact redirect URL path for your site URL in production." Check: the Site URL is your production domain and the production callback path is in the redirect allow list.

A server route has no session

Locally you were signed in through the browser; in production a server component, route handler or middleware built a client with no cookies, and the database saw nobody. Supabase: "Server-Side Rendering (SSR) with Supabase requires cookie-based session storage." Then every policy that compares auth.uid() fails, inserts get 42501 and selects come back empty. Proven on a real PostgreSQL and explained on the auth.uid() page.

The wrong key in the wrong place

The publishable key belongs in the browser and runs under row level security. The secret key belongs on the server only, and even there it does not always bypass policies. Supabase: "A secret key bypasses RLS only when the request carries no user access token." Check: no secret key in any NEXT_PUBLIC_ variable, and the server code that needs to bypass policies is not forwarding the user's token.

The hosted database never got the migration

If local development runs against a local database, the table, column or policy you added there does not exist on the hosted project until your migration is applied to it. Check: open the hosted project's SQL editor and confirm the table and its policies are there; if row level security is on with no policy, every request is refused, which is the 42501 page.

Straight answers

Do I have to redeploy after adding an environment variable on Vercel?

Yes. Vercel's documentation says changes to environment variables are not applied to previous deployments and only apply to new deployments, and Next.js inlines public variables into the bundle at build time.

Why does sign-in send production users to localhost?

Because the project's Site URL or redirect allow list still points at localhost. Supabase recommends setting the exact redirect URL path for your site URL in production.

Which Supabase key goes in the browser?

The publishable key, which runs under row level security. The secret key stays on the server, and it bypasses row level security only when the request carries no user access token.

Still broken after the five checks? Audit the policies

Most "works locally, fails in production" cases are a policy or a grant. The auditor is a read-only SQL file you run in your own SQL editor, and it lists the holes worst first.

Get the free RLS Auditor

Want a tested recipe for each finding? The RLS Security Pack Launch price USD 11.40 (normal USD 19) for the first 25 buyers or until 2026-10-31, whichever comes first. The code is already in the link. (Gumroad, USD 19) has them.

Originally published with the full SQL and sources at https://ticassociation.com/supabase-app-works-locally-not-in-production.

3 Production Security Pitfalls in Next.js App Router (And How to Fix Them)

TIC — Tue, 13 Oct 2026 13:09:58 +0000

Building fast with modern AI coding assistants makes shipping fullstack web apps effortless. However, code generators and tutorials often produce code that passes local tests but suffers from critical architectural security vulnerabilities in production.

When building multi-tenant SaaS applications with Next.js App Router and Supabase, developers frequently encounter subtle security flaws that allow unauthorized users to view private database records.

In this guide, we walk through three common vulnerability scenarios, provide reproducible code examples, demonstrate secure implementation patterns, and cite official framework specifications.

Code Implementation Disclaimer: The reference implementation patterns and code snippets in this guide have been statically reviewed against official framework specifications (@supabase/ssr 0.5.x and Next.js 14/15 App Router) rather than executed as live automated test suites. Always verify integration behavior within your project's specific dependency versions and deployment environment.

Vulnerability Scenario 1: The "auth.uid() IS NOT NULL" Trap

When developers first enable PostgreSQL Row-Level Security (RLS), tutorials frequently suggest a policy like this:

-- VULNERABLE RLS POLICY
CREATE POLICY "Allow authenticated users to read records"
ON public.customer_records
FOR SELECT
TO authenticated
USING (auth.uid() IS NOT NULL);

Why It Fails:

This policy only checks whether the client has presented a valid JWT token. It does NOT verify that the authenticated user owns the specific row being requested.

If User A logs in and runs supabase.from('customer_records').select('*'), PostgreSQL evaluates auth.uid() IS NOT NULL to true for every single row in the table. User A can now read all customer records belonging to User B, User C, and every other tenant.

The Secure Implementation Pattern:

A secure RLS policy must explicitly check that the record belongs to the requester:

-- SECURE RLS POLICY: Direct Tenant Ownership
CREATE POLICY "Users can only read own records"
ON public.customer_records
FOR SELECT
TO authenticated
USING (auth.uid() = user_id);

For team or organization-based workspaces, join through a validated membership table:

-- SECURE RLS POLICY: Workspace Membership
CREATE POLICY "Members can view workspace records"
ON public.workspace_documents
FOR SELECT
TO authenticated
USING (
  EXISTS (
    SELECT 1 FROM public.workspace_memberships
    WHERE workspace_memberships.workspace_id = workspace_documents.workspace_id
      AND workspace_memberships.user_id = auth.uid()
  )
);

Vulnerability Scenario 2: Shared Cache & Set-Cookie Leaks in Next.js App Router

In Next.js 14 and 15, route handlers and Server Components cache aggressively by default. If your middleware or route handler refreshes Supabase session tokens, an intermediate proxy or CDN might cache the response headers, including Set-Cookie.

Why It Fails:

When User A visits /dashboard, the server generates a new session token and returns a Set-Cookie: sb-<project_ref>-auth-token=... header. If the response headers lack explicit cache privacy directives, a shared edge cache (e.g., Cloudflare, CloudFront, or Vercel Edge Cache) may cache that response.

When User B visits the same URL, the edge cache serves the cached response along with User A's session cookie. User B is now authenticated as User A.

The Secure Implementation Pattern:

Any endpoint handling authentication credentials or user-specific data must declare strict private caching directives:

// app/api/auth/callback/route.ts
import { NextResponse } from 'next/server';

export async function GET(request: Request) {
  // Authentication logic...
  const response = NextResponse.redirect(new URL('/dashboard', request.url));

  // Enforce private cache boundary
  response.headers.set('Cache-Control', 'private, no-cache, no-store, must-revalidate');
  response.headers.set('Pragma', 'no-cache');
  response.headers.set('Expires', '0');

  return response;
}

Vulnerability Scenario 3: Stripe Webhook HMAC Mutation

When integrating payment webhooks, developers frequently parse incoming JSON requests using standard body parsers:

// VULNERABLE WEBHOOK HANDLER
import { NextResponse } from 'next/server';
import Stripe from 'stripe';

export async function POST(request: Request) {
  const body = await request.json(); // BUG: Mutates signed byte order
  const sig = request.headers.get('stripe-signature')!;

  // Fails or behaves inconsistently:
  const event = stripe.webhooks.constructEvent(JSON.stringify(body), sig, secret);
}

Why It Fails:

Stripe signs the raw request payload bytes. Calling request.json() and re-stringifying it mutates whitespace, property key ordering, and floating-point number representations. This causes HMAC verification to fail intermittently.

The Secure Implementation Pattern:

Always read the unparsed string buffer before HMAC verification:

// SECURE WEBHOOK HANDLER
import { NextResponse } from 'next/server';
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, { apiVersion: '2023-10-16' });

export async function POST(request: Request) {
  const rawBody = await request.text(); // PRESERVES EXACT SIGNED BYTES
  const signature = request.headers.get('stripe-signature');

  if (!signature) {
    return new Response('Missing Stripe signature header', { status: 400 });
  }

  try {
    const event = stripe.webhooks.constructEvent(
      rawBody,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    );

    // Process verified event idempotently...
    return NextResponse.json({ received: true });
  } catch (err: any) {
    return new Response(`Webhook Error: ${err.message}`, { status: 400 });
  }
}

Automated Verification Script

Run this quick audit in your project root to check for common security configuration issues:

# 1. Detect leaked secrets in public environment variables
grep -rnE "NEXT_PUBLIC_.*(SECRET|PRIVATE_KEY|SERVICE_ROLE)" . \
  --include="*.env*" --include="*.ts" --include="*.tsx" --include="*.js"

# 2. Check for raw JSON parsing inside Stripe webhook handlers
grep -rn "request.json()" app/api/webhooks/ \
  && echo "WARNING: Stripe webhooks must read request.text(), not request.json()"

# 3. Detect broad RLS policies that check auth without tenant filtering
grep -rnE "USING\s*\(\s*auth\.uid\(\)\s+IS\s+NOT\s+NULL\s*\)" . \
  --include="*.sql" && echo "WARNING: Policy checks login, but not tenant row ownership"

Complete 18-Point Production Checklist & Open Runbook

These three scenarios are part of an 18-point production invariant checklist developed to audit multi-tenant web applications under the REST Personal Economic Operating System.

The complete 18-point runbook and automated bash audit script are available as an open, free resource:

Download the Free 18-Point Production Security Runbook

100% free open developer resource (EUR 0.00). No email signup or credit card required.

Published by Tori under the REST Personal Economic Operating System.

Questions or feedback: hello@ticassociation.com

We checked 15 'make money with AI' schemes against their sources

TIC — Fri, 09 Oct 2026 00:17:20 +0000

Every week there is a new "make money with AI" playbook. We took 15 of the most common ones, opened the sources behind them, and labelled each scheme by what we could check. Date of the check: 2026-10-08.

VERIFIED: the figures come from a platform, a company report, a data service or a regulator we could open. It does not mean the scheme pays.
CLAIM: someone states a figure or a rule we could not trace, or could only trace in part.
MARKETING: the figures come from a company that sells a tool, platform or course in the same area, with no outside check.

The result: 7 verified, 3 claims, 5 marketing. In the sources we opened, none of the 15 came with a dated record of what a newcomer earned.

Seven with traceable figures

Micro-SaaS. TrustMRR verifies revenue through Stripe and lists 4,152 AI startups. Of the first 30 shown, the highest has $864k in monthly recurring revenue. Two listings we opened show $70 all-time and $4,549 all-time, both with no active subscription. The site does not show how revenue is spread across the 4,152, so a top exists and a tiny bottom exists, and the typical result is unknown.

Solo AI-native companies. Stripe (2026-05-28) found AI-native solo startups earned almost twice the revenue of other solo-founded startups by month 24, and the median solo B2B founder earned more than four times the median solo B2C founder. It also found median first-six-month revenue in 2025 down 23% year over year while the top decile was up 19%. Atlas companies are a self-selected group.

Freelance marketplaces. Fiverr's Q2 2026: revenue $97.8M, down 10%, marketplace revenue down 15.5%, with the decline tied to AI eroding low-value gigs. Upwork's Q2 2026: total volume down 3.6%, AI-related volume up more than 22% to about $330M. Both are news summaries of company results, and market totals do not tell you what a new account wins.

x402 agent payments. a16z, using Allium data (2026-03-12) put 30 days of agent transactions at about $3M, and about $1.6M after removing wash trades. An earlier reported figure was $24M.

Two "AI income" business opportunities, per the FTC. An FTC release dated 2025-06-23 says an e-commerce coaching company charged tens of thousands of dollars for online storefronts and marketed AI-powered tools; the FTC alleges it falsely claimed buyers would quickly earn thousands of dollars a month. The proposed order is a $25M judgment, partly suspended, and a permanent ban on selling business opportunities. An FTC release dated 2026-03-24 reports a proposed settlement with an AI sales-agent company over alleged false earnings and refund claims: an $18M judgment, largely suspended, and a ban on selling business opportunities. These are allegations and proposed orders, not court findings.

Three claims we could not confirm

AI content and programmatic SEO. Google's spam policy defines scaled content abuse as pages made mainly to manipulate rankings and says it does not matter how the content is created. A September 2026 blog says enforcement removed 50 to 80 percent of traffic from thin sites, and that AI Overviews cost the top result about 58% of clicks. It names no source for either number.

Faceless YouTube channels. YouTube's help page (notice dated 2025-07-15) says repetitive or mass-produced content "has always been ineligible for monetization." A services firm says channels with about 35 million subscribers were removed in January 2026; it cites no source.

AI-written books and digital products. Amazon KDP requires you to disclose AI-generated content but not AI-assisted content. We found rules, and no earnings source at all.

Five where the numbers come from a seller

Automation agencies. The page that ranks says its figures are "estimates from public rate pages, not a survey."
AI voice agencies. The margin figures come from a survey of 47 applicants to the author's own platform beta.
GEO audits. Price ranges from a company that sells a demo platform to agencies, with no source for the ranges.
Paid MCP servers and Apify Actors. Apify's page quotes "$500k+ payouts to developers every month" with no date. One independent author reported zero paying users after two weeks.
AI avatar videos and TikTok Shop. A guide from a company that sells an analytics platform, with no creator earnings in it.

How to read the next one

Who is selling something?
Is it a price list or a sales record?
How many tried?
Revenue or profit?
Can a third party check it?
Is there a date?

What we could not verify

A dated record of what any newcomer earned from any of the 15. How revenue is spread across TrustMRR's listings. Fiverr's and Upwork's own releases, which we read only as news summaries. Revenue screenshots on Reddit and X, which we could not open. If you have a source we missed, tell us in the comments and we will check it and note the date.

Tori

auth.uid() is null: why Supabase RLS denies your app

TIC — Thu, 08 Oct 2026 16:30:03 +0000

Row level security compares auth.uid() with the row's owner. When the request carries no JWT, auth.uid() is null, every comparison is false, inserts fail with 42501 and selects come back empty with no error at all. The SQL editor hides it too: on its default role it runs as postgres, which row security lets through.

Three faces of one missing session

from the app, insert:  42501 new row violates row-level security policy for table "profiles"
from the app, select:  []   no error, no rows
in the SQL editor:     works on its default role

What is auth.uid()? It is the Supabase helper that reads the subject of the JWT that came with the request. In Supabase's words: "When a request is made without an authenticated user (e.g., no access token is provided or the session has expired), auth.uid() returns null". A policy that compares it with the owner column then fails on every row, because, as the same guide puts it, "null = user_id is always false in SQL". Proven on a real PostgreSQL: with no subject on the request the insert is refused with 42501, the select returns 0 rows and no error, and both succeed the moment the subject is present. You can see the value your editor session carries:

select auth.uid();

On the editor's default role it returns null too. There is no JWT there either; that role is just not stopped by it, for the reason in the last section.

Three places. Check them in this order

The browser client has no session yet

The query ran before sign-in finished, or after the session expired. Right before the query, ask the client who the user is and log the answer; if it is empty, nothing you do in the policy will help. Do not widen the policy to the anonymous role to make the error go away: that hands the table to anyone holding your public key.

A server route built its client without the user's cookies

A server component, route handler or middleware that creates a plain client has no session, so the database sees no user. Supabase: "Server-Side Rendering (SSR) with Supabase requires cookie-based session storage." And: "Use the browser client in code that runs on the browser, and the server client in code that runs on the server." The server client is built from the request's cookies, and that is what carries the JWT to the database.

A secret-key client on the server still runs as the user

This one surprises people in the other direction: the request was denied even though the server used the secret key. Supabase: "A secret key bypasses RLS only when the request carries no user access token. If the request carries one, it runs under the RLS policies of that signed-in user, even when the client library was initialized with a secret key." So a secret-key client that also forwards the user's token is checked like the user, and a secret-key client that forwards nothing bypasses every policy. Keep the second kind on the server only.

Say what you mean: signed in, and the owner

(select auth.uid()) = user_id already refuses a request with no session, because null never equals anything. The guide still asks for the check to be explicit: "we recommend explicitly checking for authentication". This policy does that for every operation on the table. Proven: with no subject it refuses the insert (42501) and returns 0 rows; with the subject present the same user inserts and reads their own row.

create policy "own rows only"
on public.profiles for all to authenticated
using ((select auth.uid()) is not null and (select auth.uid()) = user_id)
with check ((select auth.uid()) is not null and (select auth.uid()) = user_id);

The editor is the owner, by default

By default, queries in the dashboard run as postgres. Supabase: "Queries you run in the Dashboard execute as postgres". That role usually owns your tables, and PostgreSQL lets owners through: "Table owners normally bypass row security as well". Proven: the table owner inserts a row with no JWT at all, while the signed-in role with no JWT is refused. So a query that works in the editor on its default role tells you nothing about the policy. To test the policy itself, switch the editor's role dropdown to Authenticated and pick the user. Supabase: "You can use the new Role dropdown to select a different Postgres role for your queries in Studio."

Straight answers

Why does select auth.uid() return null in the SQL editor?

Because on its default role the editor sends no JWT: auth.uid() reads the subject of the request's JWT, and there is none. It still works on your tables because it runs as postgres, which usually owns them, and row security lets the owner through. Switch the role dropdown to Authenticated and pick a user to test as them.

Why do I get no error, just no rows?

A select is filtered, not refused: rows that fail the policy are simply left out. With auth.uid() null every row fails, so the result is empty and nothing raises. Proven on a real PostgreSQL: 0 rows, no error, and the same select returns the user's row once the JWT subject is present.

Is auth.uid() = user_id wrong?

No, it refuses a request with no session as well, because null equals nothing. Supabase recommends adding the explicit null check so the intention is clear to whoever reads the policy next. The suite runs the explicit form on this page and confirms it refuses and allows exactly as expected.

One policy is rarely the only one. Check every table

Our free auditor reads your policies and lists the holes worst first, including the quiet ones that never raise an error. It runs in your own SQL editor in about a minute and never touches your rows.

Get the free RLS auditor

Also seeing 42501, new row violates row-level security policy, the same error on a file upload, or 42P17, infinite recursion detected in policy?

Still denied after the session is fixed? The free RLS Auditor checks the rest of your policies read-only, and the RLS Security Pack Launch price USD 11.40 (normal USD 19) for the first 25 buyers or until 2026-10-31, whichever comes first. The code is already in the link. (Gumroad, USD 19) has a tested recipe for each finding.

Originally published with the full SQL and sources at https://ticassociation.com/supabase-auth-uid-null-rls.

Supabase: permission denied for table (42501)

TIC — Sun, 04 Oct 2026 16:30:04 +0000

This is not row level security. The database role your app uses (anon or authenticated) has no privilege on the table at all, so Postgres refuses before any policy is read. A correct policy cannot fix it; a grant can. Supabase is also changing a default that makes this error easier to hit.

Same code, different error

from the app:  42501 permission denied for table notes
not this one:  42501 new row violates row-level security policy for table "notes"

What is permission denied for table? It is Postgres refusing a statement because the role running it holds no privilege (select, insert, update or delete) on that table. Supabase's API surfaces it as error 42501.

Both errors carry the code 42501, which is why they get mixed up. The text tells them apart. Supabase: "If you see an error like permission denied for table your_table, the querying role may not have the required privilege for the operation." A row level security violation names a policy. This one names only the table. Proven on a real PostgreSQL: with a correct select policy in place, a role that had its privileges revoked got permission denied for table on a select and on an insert; the policy never ran. A row that fails the insert policy of a role that does have the privilege got the other message, new row violates row-level security policy.

New tables stop being granted for you

Until now a table you created in the public schema was usable by the API roles straight away. Supabase's changelog (April 28, 2026): "New tables in the public schema will no longer be exposed to the Data API automatically." The dates it gives: from May 30, 2026 the setting starts to become the default for new projects (a gradual rollout), and on October 30, 2026 it is applied to existing projects. Existing tables are not affected; only tables created after the change reaches your project need the grant. And the advice: "For new tables you want to expose via the Data API, make explicit grants part of your table-creation flow." A table created by a migration that has no grant for the API roles gets exactly this error on the first query.

Ask the database what the role may do

Run this in the SQL editor, with your table name in place of your_table. If it returns f, the role has no select privilege and a grant is the fix. Proven: it returned f after the privilege was revoked and t after it was granted back.

select has_table_privilege('authenticated', 'public.your_table', 'select');

To see every privilege the API roles hold on the table:

select grantee, privilege_type from information_schema.role_table_grants
where table_schema = 'public' and table_name = 'your_table'
and grantee in ('anon', 'authenticated', 'service_role');

Grant the privilege, keep row security on

A grant decides whether the role may touch the table. Row level security still decides which rows. PostgreSQL: "In addition to the SQL-standard privilege system available through GRANT, tables can have row security policies that restrict, on a per-user basis, which rows can be returned by normal queries or inserted, updated, or deleted by data modification commands." So grant, and keep the policies. Proven: after the grant below, the owner reads their row, another signed-in user gets 0 rows and no error, and a row that fails the insert policy is refused with the policy message.

grant select, insert, update, delete on public.your_table to authenticated;

Grant only what the app needs: for a read-only table, select alone. Never grant to a role to make an error go away on a table that has row level security switched off, because then every row is open to anyone holding your public key. Our free auditor lists tables in that state.

Three look-alikes, each with its own message

A table another role created

Default grants belong to the role that set them up. PostgreSQL: "For most kinds of objects, the initial state is that only the owner (or a superuser) can do anything with the object." Proven: a table created by a different role, with a correct select policy, gave permission denied for table to the signed-in role until it was granted. Run the grant above.

A schema other than public

The message changes to permission denied for schema. PostgreSQL: usage on a schema "Essentially this allows the grantee to "look up" objects within the schema." Proven: with select granted on a table in a custom schema but no usage on the schema, the error named the schema; granting usage fixed it. Use your schema's name:

grant usage on schema app to authenticated;

A serial column and its sequence

An insert into a table with a serial id also uses a sequence, and the message names it: permission denied for sequence. PostgreSQL: "For sequences, allows use of the currval and nextval functions." Proven: with insert granted on the table but no usage on the sequence, the insert failed naming the sequence, and succeeded after this grant (the sequence is named after the table and column):

grant usage on sequence public.your_table_id_seq to authenticated;

Straight answers

Is permission denied for table the same as the row level security error?

No. Both carry the code 42501, but permission denied for table means the role has no privilege on the table, and no policy can change that. The row level security error says new row violates row-level security policy and names a policy. Proven on a real PostgreSQL: a correct select policy did not help a role whose privileges were revoked.

Does the service role need grants too?

Yes. The service role skips row level security but not privileges. Proven on a real PostgreSQL: after its privileges on a table were revoked, the service role also got permission denied for table.

Why did my new table work before and fail now?

Supabase's changelog says new tables in the public schema will no longer be exposed to the Data API automatically, from May 30, 2026 as the default for new projects (gradual rollout) and on October 30, 2026 for existing projects, and only for tables created after the change reaches your project. Add the grant to the migration that creates the table.

One missing grant is easy. The next one may be a hole

Our free auditor names every table whose policies never run because a grant is missing, and prints the GRANT for each, alongside the row level security holes, worst first. It runs in your own SQL editor in about a minute and never touches your rows.

Get the free RLS auditor

Also seeing 42501, new row violates row-level security policy, auth.uid() returning null, or an app that works locally and not in production?

Still denied after the grant? The free RLS Auditor checks the rest of your tables read-only, and the RLS Security Pack Launch price USD 11.40 (normal USD 19) for the first 25 buyers or until 2026-10-31, whichever comes first. The code is already in the link. (Gumroad, USD 19) has a tested recipe for each finding.

Originally published with the full SQL and sources at https://ticassociation.com/supabase-permission-denied-for-table.

Supabase 42501: new row violates row-level security

TIC — Thu, 01 Oct 2026 12:30:03 +0000

PostgreSQL refused the write because no policy let this user write this row. In a Supabase app that comes down to one of six causes, and three things tell you which: the table named in the error, the role making the request, and whether you asked for the row back.

What you are looking at

{
  "code": "42501",
  "message": "new row violates row-level security policy for table \"profiles\""
}

What is error 42501? 42501 is the PostgreSQL error code insufficient_privilege. PostgreSQL raises exactly this message, with exactly this code, when a new row fails a row level security check; you can see it in its executor's source. The same code also covers permission denied for table, which is a missing grant rather than a policy. That case is further down.

Six causes. Check them in this order

There is no insert policy for your role

With row level security on, PostgreSQL refuses anything no policy allows. In its own words: "If no policy exists for the table, a default-deny policy is used, meaning that no rows are visible or can be modified." Check the table's policies in your dashboard: is there an INSERT (or ALL) policy for the authenticated role? If not, add one:

create policy "insert own rows"
on public.profiles for insert to authenticated
with check ((select auth.uid()) = user_id);

The row you send fails the check

The policy exists, but the new row does not pass its WITH CHECK. The usual reason is that the app never sends user_id, or sends a different one. PostgreSQL: "Rows being inserted that do not pass this policy will result in a policy violation error, and the entire INSERT command will be aborted." Send the signed-in user's id, or let the database fill it in so the app cannot get it wrong:

alter table public.profiles alter column user_id set default auth.uid();

The request is not signed in

Your policy says to authenticated, but the request reached the database as the anonymous role: the client had no session yet, or a server route built its client without the user's session. Supabase: "Once RLS is enabled, no data is accessible through the API when using a publishable key, until you create policies." Check that a session exists right before the insert, and on the server build the client from the request's cookies. Do not widen the policy to anon to make the error go away.

You chained `.select()` after `.insert()`

Supabase's client returns nothing from an insert by default: "By default, inserted rows are not returned. To return it, chain the call with .select()." Asking for the row back adds a RETURNING clause, and then PostgreSQL also requires a SELECT policy the new row passes: "If a newly inserted or updated row does not satisfy the relation's SELECT policies, an error will be thrown." That is why the same insert works without .select() and fails with it. Add a select policy, or drop .select():

create policy "select own rows"
on public.profiles for select to authenticated
using ((select auth.uid()) = user_id);

It is an upsert

An upsert is an insert that may turn into an update, so it needs an update policy as well as an insert policy. When the row already exists, PostgreSQL checks it against your update policies and, as its documentation says, "unlike a standalone UPDATE command, if the existing row does not pass the USING expressions, an error will be thrown." It needs a select policy too: the same page says "the rows proposed for insertion are checked using the relation's SELECT policies", and on a real PostgreSQL an upsert of a new row with no select policy was refused with 42501. Add the update policy:

create policy "update own rows"
on public.profiles for update to authenticated
using ((select auth.uid()) = user_id)
with check ((select auth.uid()) = user_id);

It is a file upload

If the table in the error is objects, the refusal came from Supabase Storage, not your own table. Supabase: "By default Storage does not allow any uploads to buckets without RLS policies. You selectively allow certain operations by creating RLS policies on the storage.objects table." This lets signed-in users upload into one bucket; overwriting with upsert also needs SELECT and UPDATE policies. The four upload causes, a folder-scoped policy and the upsert policies are on the Storage upload page:

create policy "signed-in users can upload"
on storage.objects for insert to authenticated
with check (bucket_id = 'your-bucket');

Two fixes that trade the error for a leak

Do not switch row level security off. The error goes away because nothing is checked any more. Supabase gives its API roles access to tables in the public schema by default, so without RLS anyone holding your public key can read and write the table.

Do not move the insert to the secret key in the browser. Supabase: "A secret key authorizes access through the service_role Postgres role, which has the bypassrls attribute. Never use a secret key in the browser or expose it to customers."

Same code, different cause

If the message is permission denied for table, no policy was ever consulted: the role has no grant on the table at all. Supabase's own troubleshooting page explains that by default "tables in the public schema are granted SELECT, INSERT, UPDATE, and DELETE to the anon and authenticated roles". A table in a custom schema, or one whose grants were revoked, has to be granted again. The auth and vault schemas are closed to the API on purpose, so reach them through a security definer function instead.

grant select, insert, update, delete on table public.profiles to anon, authenticated;

Straight answers

Why does the same insert work in the SQL editor?

Because the dashboard runs your queries as the postgres role (Supabase: "Queries you run in the Dashboard execute as postgres"), the role that created, and so owns, your tables. PostgreSQL lets table owners skip row security: "Table owners normally bypass row security as well." Your users are not table owners, so the same insert is checked for them. When the app's request carries no session at all, auth.uid() is null and every ownership check fails; that case has its own page.

What does error 42501 mean in Supabase?

42501 is PostgreSQL's code for insufficient_privilege. With the message "new row violates row-level security policy", a row you tried to write failed a row level security check. With "permission denied for table", the role has no grant on the table.

Is it safe to just turn RLS off?

No. Supabase gives its API roles access to tables in the public schema by default, so a table without row level security is readable and writable by anyone holding your public key. Fix the policy instead.

One broken policy is rarely alone. Check every table

Our free auditor reads your policies and lists the holes worst first, including the quiet ones that never raise an error. It runs in your own SQL editor in about a minute and never touches your rows.

Get the free RLS auditor

Also seeing 42P17, infinite recursion detected in policy?

Originally published with the full SQL and sources at https://ticassociation.com/supabase-42501-row-level-security.

How We Replaced 50/mo Social Growth Subscriptions with a Local Desktop Tool

TIC — Sun, 26 Jul 2026 22:29:08 +0000

If you are a solo developer or indie hacker, you know the monthly subscription stack adds up fast.

Every tool wants $30 to $60 every single month just to run basic repetitive loops like audience targeting, account auditing, and following/unfollowing non-responders.

The Problem with Cloud SaaS for Personal Workflows

Monthly Subscription Tax: Paying $400 to $600 per year for simple automation loops.
Security & Credential Risk: Giving third-party servers your session cookies or password.
Overkill Complexity: Massive web dashboards when all you need is a reliable local script or app.

The Local Desktop Alternative

We built XDB (for X/Twitter) and IDB (for Instagram) as standalone, local-first Windows desktop tools.

Key Benefits

Zero Cloud Dependence: Everything runs on your own machine. Your credentials never touch a external server.
Safety Governor: Built-in human pacing delays prevent account blocks.
One-Time Purchase: Pay once ($29), keep it forever.

You can inspect the tools and local documentation here:

Built by the team at TIC Association.

Next.js App Shows a White Screen After Vercel Deploy: 5 Real Causes

TIC — Mon, 20 Jul 2026 19:48:58 +0000

A Next.js app that works perfectly on your machine and shows a blank white page the moment Vercel deploys it is one of the most common ways an AI-built app breaks in production. It is also one of the most misleading, because "white screen" is not a cause. It is what five or six different causes all look like from the outside.

Here is how to actually narrow it down, in the order that catches the most cases fastest.

1. Open the browser console before anything else

A white screen almost always means the client-side JavaScript threw an error before it could render anything, and that error is sitting in the browser console even when nothing shows up in the Vercel deploy log. This single step splits the problem in half: if there is an error here, you are debugging client-side code. If the console is silent, the failure is happening before the client ever runs, which points at the next two checks instead.

2. Check for a missing environment variable

This is the single most common cause. Your .env.local file exists on your machine and never gets deployed, by design. If your code reads process.env.SOMETHING and that variable was never added in the Vercel project's Environment Variables settings, the value is undefined in production, and depending on how it is used, that can fail completely silently, especially if it is passed into a client SDK's constructor with no error handling around it. Check the Vercel deploy's Function Logs, not just the build log. A build can succeed while the actual request still fails.

3. Check whether the build genuinely succeeded, not just that it finished

Vercel will sometimes complete a build and still ship something broken if a data-fetching call at build time (generateStaticParams, a server component's own fetch) silently failed and got swallowed instead of throwing. The page "builds," but the HTML that gets served is empty or wrong. Look at the actual deployed HTML source (view source on the live URL, not the rendered page) and check whether meaningful content is even there before the JavaScript runs.

4. Check the output configuration if you changed frameworks or moved directories

If the project was migrated, restructured, or built with an AI tool that changed the framework preset partway through, Vercel can end up looking in the wrong output directory, or running a build command that no longer matches the actual project structure. This usually shows up as a successful-looking build with nothing meaningful in the output, which again reads as a plain white screen once deployed.

5. Node version mismatches

Code that relies on a newer JavaScript or Node feature than the one Vercel's build environment is using can fail in ways that do not always throw a clean, readable error, particularly inside a dependency rather than your own code. Pin the Node version explicitly in your project settings rather than leaving it on whatever the platform default happens to be, and confirm it matches what you built and tested locally.

The pattern underneath all five

Every one of these fails in a way that looks identical from the outside (a blank page) while being caused by something that only shows up if you look in a specific, different place: the browser console, the environment variables panel, the raw HTML source, the output directory, or the build environment's Node version. Checking the symptom again does not help. Checking each of those five places, in order, usually does.

If you have already gone through this and the app still will not come back, we do free diagnosis on exactly this class of problem, then a fixed-price repair only if the fix is clear: https://rescue.ticassociation.com

How to Check Supabase Row Level Security Holes (Free SQL Audit)

TIC — Mon, 20 Jul 2026 19:45:45 +0000

Row level security in Supabase fails quietly. There is no crash, no red error banner, nothing in your logs that says "this table is wide open." The app keeps working in the demo. The first sign anything is wrong is usually someone else's data showing up where it shouldn't, and by then it already happened.

Here is how to check for the five holes that cause almost all of it, using nothing but a read-only SQL query against your own database's catalog.

The five holes, in order of how often they actually happen

1. RLS switched off entirely. The single most common leak. It usually happens to a table created after row security was already turned on for the rest of the schema, and the new table never got the same treatment. Anyone with your anon key can read and write it.

2. RLS is on, but zero policies exist. This is the most common cause of the 42501 error ("new row violates row-level security policy"), and it goes both ways: depending on the default deny/allow behavior for the operation, the table either blocks everything (your own app breaks) or exposes everything (your data leaks), and it is easy to not notice which one happened.

3. A write policy with no WITH CHECK. A policy can correctly gate who is allowed to write, using USING, while leaving the actual row values unchecked. That lets an authenticated user insert or update a row that claims to belong to someone else, because nothing verified what they wrote, only that they were allowed to write.

4. A policy that resolves to true for everyone. This one is sneaky because it looks like security. There is a policy. It has a name. It shows up in your dashboard as "protected." But the condition inside it evaluates to true for every role, so it protects nothing while giving every appearance of doing so.

5. The anon role holds a direct grant. Someone ran a GRANT statement straight against the anonymous role at some point, usually while debugging, and it bypasses your row-level policies entirely regardless of how carefully those policies are written.

The query

You can check for most of these directly from Supabase's own SQL editor, because the answers live in Postgres's own catalog tables (pg_policies, pg_class, information_schema), not in anything Supabase adds. A useful starting query:

select
  n.nspname as schema,
  c.relname as table_name,
  c.relrowsecurity as rls_enabled,
  count(p.polname) as policy_count
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
left join pg_policies p on p.tablename = c.relname and p.schemaname = n.nspname
where n.nspname = 'public' and c.relkind = 'r'
group by n.nspname, c.relname, c.relrowsecurity
order by rls_enabled asc, policy_count asc;

Any row with rls_enabled = false is hole #1. Any row with rls_enabled = true and policy_count = 0 is hole #2. Holes #3 through #5 need a look at the actual policy definitions (pg_policies.qual and .with_check) and at information_schema.role_table_grants for direct grants to anon, which is more than fits cleanly in one query.

Why this is worth checking even if nothing looks broken

The whole point of these five is that none of them produce an error under normal use. Your own testing, as the table's owner or as an authenticated user hitting your own rows, will not surface a policy that is technically present but too permissive, or a grant that quietly overrides your policies. The only way to know is to check the catalog directly, which is exactly what this kind of query is for.

We built a free, one-file version of this check that runs the fuller version of the above (read-only, checks all five holes, plain-language output with the fix for each finding) and never asks for your project URL or your keys, because it runs inside your own SQL editor. It is a SQL file, so you can read exactly what it does before you run it: https://ticassociation.com/supabase-rls-audit

Nothing here is a substitute for reading your own policies. It is a fast way to find out where to start looking.

DEV Community: TIC

Fix StorageApiError: new row violates RLS on upload

What you are looking at

Four causes. Check them in this order

There is no insert policy on storage.objects for your role

The path you upload to does not match the policy

You are overwriting a file (upsert)

The request is not signed in

Two shortcuts that open the bucket to everyone

Straight answers

One missing policy is rarely alone. Check every table

Five questions to ask before you use an AI answer

How to read the free limit of an AI tool before you rely on it

Supabase works locally, not in production: 5 checks

Same code, two different environments

Five checks. In this order

The public variables were not there when the bundle was built

Sign-in comes back to localhost

A server route has no session

The wrong key in the wrong place

The hosted database never got the migration

Straight answers

Still broken after the five checks? Audit the policies

3 Production Security Pitfalls in Next.js App Router (And How to Fix Them)

Vulnerability Scenario 1: The "auth.uid() IS NOT NULL" Trap

Why It Fails:

The Secure Implementation Pattern:

Vulnerability Scenario 2: Shared Cache & Set-Cookie Leaks in Next.js App Router

Why It Fails:

The Secure Implementation Pattern:

Vulnerability Scenario 3: Stripe Webhook HMAC Mutation

Why It Fails:

The Secure Implementation Pattern:

Automated Verification Script

Complete 18-Point Production Checklist & Open Runbook

We checked 15 'make money with AI' schemes against their sources

Seven with traceable figures

Three claims we could not confirm

Five where the numbers come from a seller

How to read the next one

What we could not verify

auth.uid() is null: why Supabase RLS denies your app

Three faces of one missing session

Three places. Check them in this order

The browser client has no session yet

A server route built its client without the user's cookies

A secret-key client on the server still runs as the user

Say what you mean: signed in, and the owner

The editor is the owner, by default

Straight answers

One policy is rarely the only one. Check every table

Supabase: permission denied for table (42501)

Same code, different error

New tables stop being granted for you

Ask the database what the role may do

Grant the privilege, keep row security on

Three look-alikes, each with its own message

A table another role created

A schema other than public

A serial column and its sequence

Straight answers

One missing grant is easy. The next one may be a hole

Supabase 42501: new row violates row-level security

What you are looking at

Six causes. Check them in this order

There is no insert policy for your role

The row you send fails the check

The request is not signed in

You chained .select() after .insert()

It is an upsert

It is a file upload

Two fixes that trade the error for a leak

Same code, different cause

Straight answers

One broken policy is rarely alone. Check every table

How We Replaced 50/mo Social Growth Subscriptions with a Local Desktop Tool

The Problem with Cloud SaaS for Personal Workflows

The Local Desktop Alternative

Key Benefits

Next.js App Shows a White Screen After Vercel Deploy: 5 Real Causes

You chained `.select()` after `.insert()`