Securing use of anon APIKEY, maybe inet_client_addr()?

[guicaro]

In an effort to look at securing my integration with Supabase and making it harder for someone to use my anon APIKEY and blast thousands of INSERTS to my Supabase DB I have been playing with RLS, but still no clear path.

I have a website where visitors can take a quiz and we keep a copy of answers in Supabase by calling API to INSERT from supabase-js client in our ReactJS app. Yes, ideally I would also stand a backend and have front end talk to backend instead and do other kind of auth there (ex. domain/ip origin). So as to only accept inserts when they come from my frontend.

inet_server_addr()

1. Playing with SQL Editor and PostgreSQL System Information Functions
2. Was hoping inet_client_addr() would identify my server (where frontend resides) and I could add an INSERT policy in Supabase
3. Ran SELECT inet_server_addr() in SQL Editor to find out where PostgreSQL was running
4. Created SELECT policy on a table where DEFINITION was (inet_server_addr() = 'x.x.x.x'::inet) where x.x.x.x is IP from step 3
5. Ran a SELECT statement using bash and it works. Changing the policy in (4) to a different IP gives me an empty array 🤠

What about inet_client_addr()

1. I was hoping this would present the IP where request originated but it is actually ip for https://<SUBDOMAIN>.supabase.co/rest/ 😞

Questions

1. Are there any plans to be able to write policies in table where one can look at the ip from where request originated?
2. Is there any other recommended practice to secure anon APIKEY as it will likely show up in browser dev tools and attacker could use it to write to Supabase

[guicaro]

I ended up going to Vercel for a Serveless function to act as my backend.

1. In the function called by my frontend (using the fetch API, I am getting the ip from req and the data that I will send to Supabase
2. I compare the ip from req with my known ip address of machine where my frontend resides
3. If (2) matches I make the call to Supabase using the supabase-js client. If it does not match I simply send back a 404 response

Yes, an attacker could still run this Serveless function from Vercel thousands of times, but at least it won't compromise my data on Supabase as ip will not match. I was also considering AWS Lambda and using an IAM Policy to restrict execution of an AWS Lambda based on ip. But Vercel should do for now until I can find another way to do this simply with Supabase 🤠

[kiwicopple]

Hey @guicaro - yes that's a good idea to proxy it thorugh a backend

Vercel should do for now until I can find another way to do this simply with Supabase 🤠

We will definitely bring out rate-limiting :). We use Kong in the background, and we'll expose a few of their plugins: https://docs.konghq.com/hub/