DEV Community: Jacob Perks

Every Supabase key, what it does, and which ones can be public

Jacob Perks — Fri, 07 Aug 2026 19:16:15 +0000

I audit apps built with AI tools. Most of the exposed credentials I find are Supabase keys, and most of them are not a problem.

That is the part people get wrong in both directions. Some panic about a key that was designed to be published. Others ship the one that grants full database access and never notice, because nothing breaks.

There are four keys. Two of them are being retired.

The deadline

Supabase is replacing the original anon and service_role keys. Their own timeline is blunt about what happens at the end:

"Legacy API keys will be deleted and removed from the Docs / Dashboard. You have to migrate to use the new API keys by this point or your app will break."

That is scheduled for late 2026, marked as to be confirmed.

There is an earlier milestone that matters more:

"Projects restored from 1st November 2025 will no longer be restored with the legacy API keys. New projects no longer have anon and service_role available for use."

So if your project was created after November 2025, you already have the new keys and there is nothing to do. If it was created before, you are on legacy keys and you have a deadline.

Think about who that is. Nearly every app built during the 2025 rush of Lovable, Bolt and Replit projects predates that cutoff. Those apps are running legacy keys. Most of their owners have never opened the API settings page. The app stops working when the keys are deleted.

The four keys

Key	Format	Browser safe	What it grants
Publishable	`sb_publishable_...`	Yes	Low privilege. Access controlled by row level security through the `anon` and `authenticated` roles
Secret	`sb_secret_...`	No	Full access to your project's data. Bypasses row level security
`anon` (legacy)	JWT	Yes	Legacy version of the publishable key
`service_role` (legacy)	JWT	No	Legacy version of the secret key. Bypasses RLS via the `BYPASSRLS` attribute

Source: Supabase, Understanding API keys.

Two of these belong in your frontend. Two of them, if they reach a browser, mean your database is already compromised.

A public key is not a leak

The publishable key is meant to be shipped. It sits in your JavaScript bundle. Anyone who opens developer tools can read it. That is the design.

The key identifies your project. It is not what protects your data.

Row level security is what protects your data. The key gets a request as far as the anon or authenticated role, and the policies you write on each table decide what those roles can read and write.

So the key is exactly as safe as your policies are. If every table has policies, publishing it costs you nothing. If a table has RLS switched off, that same public key reads the whole table. So does anyone else who found it.

This is the most common serious finding in the audits I do. Not a stolen credential. A published one, working as designed, in front of a table that was never given a rule.

The secret key: full database access, no policies

The secret key bypasses row level security completely. It does not respect your policies because it is not supposed to. That is its job. It exists so your server can act on behalf of the system rather than a signed-in user.

If it reaches a browser, every protection you wrote is gone at once. Not weakened. Gone. Anyone who reads it out of your bundle can read, change or delete any row in your database.

There is no partial version of this finding. Treat the key as already compromised, because every visitor to your site has been able to read it.

Why the format changed

Here is the problem the new keys solve.

The legacy anon and service_role keys are both JSON web tokens. Both are long strings of the same characters. Side by side, you cannot tell them apart by looking. The only thing separating a key that belongs in every visitor's browser from a key that grants full database access is one field inside the token.

I built a security scanner for Framer sites, which is where I run into this constantly: Framer handles the front end, so anything with a database behind it has Supabase wired in from the browser, and the key is sitting in the page. The scanner decodes the token and branches on the role claim. service_role is reported as critical. anon is not reported at all, because reporting it would be wrong. A tool that flags your publishable key has not found anything. It has taught you that its output is noise, and the next thing you skip past will be the real one.

The new format removes the ambiguity. sb_publishable_ and sb_secret_ are different at a glance, to a person and to a tool. Supabase also added browser detection, so a secret key used from a browser returns HTTP 401 instead of quietly working.

Do not read that as a safety net. The check matches on the User-Agent header, and Supabase's own docs say so plainly: it "does not mean that attackers will not use it with other tools." Anyone who copies your key out of a page and sends it from curl gets straight through. The 401 stops your own code from working by accident. It does not stop the person who found the key.

That is a real improvement, and it is worth being clear about why. The old design made a catastrophic mistake and a harmless one look identical.

How to tell which one you shipped

On the new keys, read the prefix. sb_publishable_ is fine in your frontend. sb_secret_ is not.

On legacy keys, the prefix will not help. You have to decode the token and read the role field.

Do that locally, not in an online JWT decoder. If the key turns out to be service_role, you have just pasted full access to your database into somebody else's website. In your browser console:

JSON.parse(atob(key.split('.')[1].replace(/-/g, '+').replace(/_/g, '/'))).role

It says anon or service_role. That is the whole test.

The split and the two replace calls are not decoration. A JWT is three base64url segments joined by dots, so atob on the whole string fails, and base64url uses - and _ where atob expects + and /. Plenty of tokens happen to contain neither character, which is why the naive one-liner works right up until the day it does not.

Then check where each one is used. The publishable or anon key belongs in client code. The secret or service_role key belongs on a server, in an environment variable, never in a repository, and never in anything sent to a browser.

If the wrong key is already public

This is where the two key systems stop being equivalent, and it is the strongest practical argument for migrating.

On the new keys, you replace it. Create a second secret key in Settings, API Keys, move everything over to it, then delete the compromised one. The publishable key is untouched, nobody is signed out, and there is no downtime. Deleting a secret key is permanent, so do it in that order.

On legacy keys, you cannot. Supabase's own troubleshooting documentation is explicit: "it is no longer possible to rotate the legacy anon, service and JWT secrets." There is no button. An exposed service_role key stays exposed until you migrate off it.

That is worth sitting with. If you are on legacy keys and your service_role key is in a browser bundle today, migration is not a piece of housekeeping with a 2026 deadline. It is the only way to revoke the key, and it is this week's job.

Historically the fix was to regenerate the project's JWT secret, which signed both legacy keys and therefore invalidated every session in one go. Supabase describes the effect as all current secrets being "immediately invalidated, and all connections using them will be severed." That route is closed now, and the replacement path is the new keys, which is the point of the whole exercise: individually revocable credentials instead of two tokens welded to one secret.

Then check your row level security policies while you are there. An exposed service_role key usually means nobody was thinking about database access rules at the time, so the policies are often missing too.

Migrating off the legacy keys

Supabase's migration guide covers the process:

Create the new keys in Settings, API Keys
Replace the anon key with the publishable key in client code
Replace service_role with the secret key on the server
Update Edge Functions to read the new environment variables
Confirm nothing still uses the old keys
Deactivate the legacy keys

Both sets work at the same time, so you can move gradually. And deactivating the legacy keys is reversible. If you miss a client, turn them back on. That matters more than it sounds, because fear of breaking production is the main reason this gets postponed.

Five things in the migration are easy to get wrong, all documented:

Neither new key goes in an Authorization: Bearer header. Send them on the apikey header only. Many Supabase clients pass the key on both by default, and the platform then tries to parse it as a JWT and rejects the request with Invalid JWT. That error message sends people looking in the wrong place for hours.
Database Webhooks and pg_net calls need the same change.
Do not hardcode secret keys in SQL or webhook configuration. Use Vault.
Edge Functions cannot verify the new keys in Authorization headers, so set verify_jwt = false. That makes the function publicly invokable by anyone with the URL, so the authorisation check has to move into the function body. The docs say to "authorize the request in your own code", and this is the step people skip, because the function keeps working perfectly whether or not you do it.
Public Realtime connections are limited to 24 hours unless the connection is upgraded with user-level authentication through Supabase Auth or a supported third-party provider.

What to do this week

Open your Supabase dashboard and go to Settings, API Keys. If you see anon and service_role, your project predates November 2025 and you have a migration to do.

While you are there, three checks:

Confirm every table has row level security enabled, then look at the policies. Enabled is not the same as protected. A table with a policy of USING (true) is readable by anyone holding your public key, which is everyone, and the dashboard will still show RLS as on. The same goes for a table exposed through a SECURITY DEFINER view, which runs as its owner and bypasses policies entirely. Neither shows up as a warning.

Search your frontend code and your deployed bundle for service_role and sb_secret_. Search the built output, not just the source, because environment variables get inlined at build time and that is usually how it happens. If you find one, see the section above: replaceable on the new keys, not replaceable on legacy.

Decode the key that is actually in your client bundle and confirm the role says anon. Not the one in your .env file. The one that shipped.

Those take a few minutes. They will not tell you whether the policies you wrote are correct, or whether a later change reopened something you had already closed. Finding an exposed key and knowing your access rules hold are different problems. On AI-built apps, the second is where most of the work is.

If you would rather not check it yourself

That second problem is most of what I do. I audit apps built with AI tools, work through the access rules account by account, and send back a report with every finding, where it lives and what to change. Fixed price, from $750. That is the audit we do, and you can request one here.

Sources

Understanding API keys, Supabase Docs
Migrating to publishable and secret API keys, Supabase Docs
Upcoming changes to Supabase API Keys, Discussion #29260
Rotating Anon, Service, and JWT Secrets, Supabase Docs

Originally published at thunkle.ai.

What I scan for in Framer code components

Jacob Perks — Mon, 27 Jul 2026 15:33:25 +0000

Most of a Framer site is not code. The parts that are, are code components, and that is where the risk collects. A component that calls an API needs a key. A component that needs a library sometimes imports it from a URL. A component rendering content from elsewhere has to decide how much it trusts that content.

I built a free plugin that reads them and reports what it finds. Here is what it looks for, and the parts that were harder than expected.

First, the thing that caught me out

Framer has two things called code:

Code components, the .tsx files under Assets
Custom code, the named scripts under Settings with a placement dropdown

Same risk. A key in either ships to the browser. A plugin can only read the first.

The API has getCustomCode(), which sounds like it returns the project's custom code:

type CustomCodeLocation = "headStart" | "headEnd" | "bodyStart" | "bodyEnd"
type CustomCode = Record<CustomCodeLocation, {
    disabled: boolean
    html: string | null
}>

It returns whatever your own plugin put there. I confirmed it by pasting a script into the Code panel of a real project, saving, and printing the counts:

headStart: 0 chars
headEnd:   0 chars      ← script visibly sitting in Settings → Code
bodyStart: 0 chars
bodyEnd:   0 chars

codeFiles: 1
  Test.tsx: 830 chars   ← Assets → Code, readable

The docs say a plugin can detect custom code "set by your plugin", which read carefully is the entire answer. I went through every read method on the API, roughly fifty, and nothing returns user-authored custom code or site settings.

So the scanner reads what it can:

const files = await framer.getCodeFiles()

for (const file of files) {
    console.log(file.name, file.content.length)  // Test.tsx 830
}

subscribeToCodeFiles and subscribeToRedirects let the panel re-scan as the user edits.

Credentials in components

The most common real finding, for an ordinary reason: standing up a server to hold a key is a bigger job than the component that needs it, so the key goes in the file and stays there.

Fifteen formats, weighted toward what people reach for when a component calls a model: OpenAI, Anthropic, Groq, Replicate, Hugging Face, Perplexity, alongside Stripe, AWS, Supabase, GitHub, SendGrid, Slack, Twilio, Resend and Convex.

The check that decides whether anyone trusts the tool.

Supabase issues two keys. Both are JWTs, both are long, and side by side you cannot tell them apart. The anon key belongs in the browser and is protected by row-level security. The service_role key bypasses RLS entirely.

One field in the payload separates them, so decode rather than pattern match:

function supabaseJwtRole(token: string): string | null {
    const parts = token.split(".")
    if (parts.length !== 3) return null
    try {
        const payload = JSON.parse(
            atob(parts[1].replace(/-/g, "+").replace(/_/g, "/"))
        ) as { role?: unknown }
        return typeof payload.role === "string" ? payload.role : null
    } catch {
        return null
    }
}

service_role is critical. anon is not reported at all. Same for Firebase browser keys and Stripe publishable keys, which exist to ship in a page.

A scanner that flags those has not found anything. It has taught its user that its output is noise, and the next thing they skip will be real.

Modules imported from a URL

Framer lets a component import straight from a URL. Useful, mostly fine, and it means whoever controls that host controls part of your site. If the file changes tomorrow, your site runs the new version.

Two cases get flagged: anything over plain http, and anything from a host that is not a recognised package CDN. esm.sh, jsDelivr, unpkg and Skypack stay quiet since that is normal practice. An unrecognised domain is worth a look, especially on a site someone else built.

Content turned into code

Three worth knowing about:

dangerouslySetInnerHTML, where any part of the HTML coming from a URL parameter or CMS field means someone can run scripts on your site
eval and new Function, which run whatever string they are handed
reading a key or token out of location.search or location.hash, which leaks it into browser history, referrer headers and analytics

Redirects

Not components, but the other thing nobody re-reads. When a redirect's destination page is deleted, Framer nulls the target:

interface Redirect {
    id: string
    from: string
    to: string | null   // null = destination page was deleted
    expandToAllLocales: boolean
}

That is a broken redirect with no indication in the UI. Chains, loops and duplicate sources all fall out of the same array.

The bug I shipped into my own first draft

Before publishing I ran the patterns against strings that are not secrets. Four of six benign inputs came back flagged:

FALSE POSITIVE  git commit SHA in a comment    -> "Twilio API key exposed"
FALSE POSITIVE  cache-busting hash in a URL    -> "Twilio API key exposed"
FALSE POSITIVE  css class name                 -> "OpenAI API key exposed"
FALSE POSITIVE  hyphenated word chain          -> "OpenAI API key exposed"

A Twilio key identifier is SK plus 32 hex characters, which is also every other git hash. And I had allowed hyphens in the OpenAI pattern, so sk-spinner-container-large-variant qualified.

Two guards. Require a match to mix character classes:

function looksHighEntropy(value: string): boolean {
    const classes = [/[A-Z]/, /[a-z]/, /[0-9]/].filter(re => re.test(value))
    return classes.length >= 2
}

And for formats shape-identical to ordinary text, require supporting context before reporting at all:

{
    id: "twilio-key",
    pattern: /\bSK[0-9a-fA-F]{32}\b/g,
    requiresContext: /twilio/i,   // no Twilio in the file, no finding
}

Zero false positives afterwards, every real key still caught.

Not a lesson about regexes. One confident wrong finding costs more trust than ten correct ones earn, and the only way to know which you have written is to test against things that are fine.

Limits worth stating out loud

No custom code. A clean scan does not mean a clean site. Check the Settings panel yourself.
No published HTML. No API for the rendered site, and you cannot fetch it cross-origin from the plugin iframe.
No proof a tracker fired before consent. That needs a browser watching the network on the live page. From inside the editor you can only infer, so the tool says "no consent signal found" rather than asserting a violation.

The plugin

Free, no account, no tiers: Thunkle Security Scanner on the Framer Marketplace.

Runs entirely in the browser, zero network requests, small static bundle so you can verify that in devtools rather than take my word for it.

I write more of this at thunkle.ai, where I audit and fix apps built with AI tools.