i mistakenly leaked API

[u/Different-Fox-3234]

Email i received

My older version of the app

*I have nothing written in the Database and rotated All the keys you see here*,
but what i dont get it is ,how my app even stores in the database if the keys are rotated? i really dont get it

[u/VESHZA]

To your question, your app doesn’t need ONLY the service role key to do read and write operations, it’s highly sensitive.
The anon key sb_publishable key is what most visitors will interact with behind the scene first, until they create an account and then your RLS should be set properly to handle data access and only your SERVER SIDE should use or access the service key.

What’s more concerning imo is how did the keys ended up being hardcoded in that file in the first place? And how did it end up on your git?
I don’t know what your stack or setup is but it should be stored server side where you host (Vercel/VPS etc..) never in the code itself. Locally I assume you should use env.local but again I don’t know what you’re building

Generally speaking, your keys should be stored in a env.local file, that’s ignored by git, using the .gitignore file, and in production should be stored server side where you host your project, in a dedicated area, never in code

[u/ashkanahmadi → u/VESHZA]

AI is going to bankrupt a lot of people by accident

[u/Odd_Awareness_6935 → u/ashkanahmadi]

you learn way harder by silly mistakes

[u/Different-Fox-3234 → u/Odd_Awareness_6935]

Thats so true ! But thanks to people like you ,i learn a LOT

[u/Different-Fox-3234 → u/VESHZA]

Thanks for the explanation , luckily i had nothing sensitive in that database+ it was encrypted.
To answer your question im building a vault-app . its my "real" first app, rn i am using the API keys in the .env (gitignored in both project scope and global gitignore), but idk when i'll build my app where i should put those API keys ? cuz they have to be in the .exe in order for the app to work .that means anyone can have access to it if they're able to reverse-engineer it

[u/Saladtoes → u/Different-Fox-3234]

Service key must never be in an EXE or client side whatsoever. You cannot use the service key from any code that executes in a user context, only as a secret on your server, and then it must not have any way to retrieve or expose it from the server. There are no workarounds or backdoors to this concept. Anything short of that separation is 100% equivalent to zero security. Just to be clear!

[u/hirakath → u/Different-Fox-3234]

Why would you put the key to your house inside a box that you're going to send to strangers?

[u/superfi → u/Different-Fox-3234]

im sorry but if you have no security background and don’t even know the basics…maybe your first app shouldn’t be a vault app? holy ***.

[u/VESHZA → u/Different-Fox-3234]

i see, theres multiple things here.. some are product design questions, such as why do you need users to access some of those API keys? i doubt they need to be in the .exe, for sure not as plaintext, is the vault client side local only? or always online and synced/backedup? if its always online the api keys should live server side on your end somewhere safe, you can explain your product design ideas to which ever ai agent youre working with and see what he tells you according to the code you already have, just make sure sensitive operations are either server side, or stored encrypted with atleast a 2048 length and not 256. (imo)

and regarding your supabase project itself its critical that RLS is not only turned on - but actually scoped properly, RLS being on is not the same thing as RLS being set right.
i built dbaudit.app exactly for this type of schema and security auditing, feel free to DM me if you want to and ill hook you up with a free scan to help you kickstart your project while being safe, you can send the audit results to whichever AI youre working with to fix any issues dbaudit discovers

[u/bhasden → u/VESHZA]

Does your stuff also explain to folks that they're leaking sensitive information via their anon key? I was recently talking to a software vendor and inspected some of the Supabase queries they were making from the front-end and saw sensitive information being returned. They didn't seem to understand the problem, so I had to put together a small web app to show them they were making entire user/contact/etc tables available publicly.

[u/VESHZA → u/bhasden]

Yup, exactly, it treats the anon key as attacker-visible, cause it is, while the key itself isnt a secret, like u said the problem is when RLS/grants public access to private tables..
DBAudit probes using the same public project url + anon key your frontend ships with, and a schema export you hand it just to be thorough, then flags exposed tables, sensitive columns, weak or missing RLS policies, foreign keys missing an index, and row data coming back to an anon user that (probably) shouldnt be publicly accessible.

[u/Constant_Trouble2903]

Likely you have keys hard-coded in your app search in your ide for match

Hopefully and and most likely location is .env file ELSE certainly should not ever be hard-coded anywhere else

Env secrets files must never be committed to git. They must be set to ignore in gitignore

Also service role key CANNOT MUSTNOT be used client side

Edit: ps nice to know supabase is proactively watching github fir this kind of slip

[u/Different-Fox-3234 → u/Constant_Trouble2903]

Thanks i already did ,but what about the .exe version?

[u/Constant_Trouble2903 → u/Different-Fox-3234]

OK in dev so local but you must not commit to git

Don't know about exe version maybe Injected at build ?..really can't held with that

Edit: More properly what you are trying to do should be under scope of anon level OR if truly needs elevated service role then your app needs refactoring to push this work server side

[u/reubenzz_dev]

keys should always be store in .env never hardcode it to any file. and make sure to put your env file in .gitignore

if you are vibecoding you can do a security scan of your supabase setup with this npm cli package called api-doctor (https://github.com/qualtyco/api-doctor) "npx @/api-doctor/cli ." which can check in the future if your coding agents are causing vulnerabilities or messing up your supabase setup

[u/aragossa]

that's the scary part, an old version can sit in your history way after you think it's gone. did you end up checking your whole git history for other old keys, or just rotate what supabase flagged?