Just figured out reverse proxy IS NOT POSSIBLE using Supabase! If you did set it up: you wasted time
Hi,
When supabase issues an auth token, in this token you can find the ID of your supabase instance. This ID can be used to determine the backend domain. So this makes it trivial to bypass any reverse proxy you think you have setup. Security through obscurity never works eh...
So a monkey with a typewriter could knock your supabase instance offline if you have ANY readable schemas, even if you have that fancy "reverse proxy with rate limit" setup.
What I have done to solve this currently:
- Configured tables to be no longer accessible by users
- Cloudflare instance sits in front of everything
- Cloudflare instance applies API key header
- Edge functions (when invoked) check presence of API header
- If API header is not present, IP is banned for X time
This leaves edge functions relatively safe from abuse.
Tables can still be called but will yield no results as that is how RLS is setup.
I have thought about renaming the public schema to publich89H&(G)H&W$G_H&WG*) and using cloudflare to transform the request to target this schema. This would add another layer of security to the application as attackers can't target the schema anymore.
If we could ban IP ranges (and not just from connecting to the database) alternatively we could pipe the logs to a custom solution, and if there are any calls to the database that do not originate from cloudflare, these should be added to the banlist.
But really the best and kind of only solution is to be able to whitelist IP ranges. That would make this SO much easier. I really dont understand why it not possible. Such a simple feature to add???
When supabase issues an auth token, in this token you can find the ID of your supabase instance. This ID can be used to determine the backend domain. So this makes it trivial to bypass any reverse proxy you think you have setup. Security through obscurity never works eh...
So a monkey with a typewriter could knock your supabase instance offline if you have ANY readable schemas, even if you have that fancy "reverse proxy with rate limit" setup.
What I have done to solve this currently:
- Configured tables to be no longer accessible by users
- Cloudflare instance sits in front of everything
- Cloudflare instance applies API key header
- Edge functions (when invoked) check presence of API header
- If API header is not present, IP is banned for X time
This leaves edge functions relatively safe from abuse.
Tables can still be called but will yield no results as that is how RLS is setup.
I have thought about renaming the public schema to publich89H&(G)H&W$G_H&WG*) and using cloudflare to transform the request to target this schema. This would add another layer of security to the application as attackers can't target the schema anymore.
If we could ban IP ranges (and not just from connecting to the database) alternatively we could pipe the logs to a custom solution, and if there are any calls to the database that do not originate from cloudflare, these should be added to the banlist.
But really the best and kind of only solution is to be able to whitelist IP ranges. That would make this SO much easier. I really dont understand why it not possible. Such a simple feature to add???
