You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if you are using Supabase's PostgreSQL outside of their dashboard (say an ORM or just using the connection string) when you create a new table anyone can access all of the data in this table via the PostgREST API. This is mitigated if you enable RLS (with proper policies ofc), however most people don't enable RLS when creating tables in SQL. Further more if you are using an ORM like Prisma or Drizzle that creates the tables for you, you might have to enable it manually. outside of your ORM.
Requiring Supabase users to keep up with this poses a security risk when people inevitably make this mistake. This is not a hypothetical security concern and it has been found in a large number of services.
While this is not a bug with Supabase, this behavior is insecure by default. While this can be mitigated by using an api schema instead of a public schema or by disabling the data API, making it secure by default could go a long way to prevent accidently exposing data. A possible resolution to this within PostgreSQL itself might be to have an Event Trigger that enables RLS on all newly created tables. This however would deviate from default behaviors and would likely have unexpected consequences so discussion on this topic is needed.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently if you are using Supabase's PostgreSQL outside of their dashboard (say an ORM or just using the connection string) when you create a new table anyone can access all of the data in this table via the PostgREST API. This is mitigated if you enable RLS (with proper policies ofc), however most people don't enable RLS when creating tables in SQL. Further more if you are using an ORM like Prisma or Drizzle that creates the tables for you, you might have to enable it manually. outside of your ORM.
Requiring Supabase users to keep up with this poses a security risk when people inevitably make this mistake. This is not a hypothetical security concern and it has been found in a large number of services.
While this is not a bug with Supabase, this behavior is insecure by default. While this can be mitigated by using an api schema instead of a public schema or by disabling the data API, making it secure by default could go a long way to prevent accidently exposing data. A possible resolution to this within PostgreSQL itself might be to have an Event Trigger that enables RLS on all newly created tables. This however would deviate from default behaviors and would likely have unexpected consequences so discussion on this topic is needed.
Beta Was this translation helpful? Give feedback.
All reactions