8 ms·

Your Supabase is public if you turn off RLS

112 points by skilldeliver 9mo ago

ErroneousBosh 9mo ago
So like MongoDB twenty-odd years ago?
anxman 9mo ago
Supabase doesn’t make a public users table by default. The user schema is in auth and secured. The problem is that unskilled developers bypass those controls out of convenience and put data into Public without RLS. Even the Supabase docs warn against this.
- deleted 9mo ago
  [deleted]
- skilldeliver 9mo ago
  The point is that why they even have to make new users table? Something is driving them in this direction and as a counterexample you have Pocketbase where you don't have to.
  - MoonWalk 9mo ago
    To store application-specific data about users. The Supabase doc or examples show this. Where else would you put such data? But what the docs don't cover is the provided Users table. Missing documentation is why I gave up on Supabase; and the Users table was one of the first problems I encountered. I could find no details on what to expect in each column at any given time. Upon creating a new user, values get set in this table for no apparent reason. So if your application depends on knowing the verification status of a new user (for example), good luck... Supabase claimed every user was verified upon creation.
    - anxman 9mo ago
      The auth schema is intentionally not exposed to the rest api for security reasons. You need to use an auth hook to put data where you need, or an RPC with appropriate privileges, and of course RLS on any tables.
    - anxman 9mo ago
      https://supabase.com/docs/guides/auth/auth-hooks https://supabase.com/docs/guides/auth/auth-hooks These have gotten much less annoying to use now that it’s controlled through the config.toml.
    - fakedang 9mo ago
      I finally resorted to using Supabase as a Postgres database for Django. In that role, it has worked very nicely.
int0x29 9mo ago
Firebase seems to suffer a similar problem of people not setting permissions right. The only major difference is that they seem to steer devs pretty aggressively to Google auth which won't leak password hashes. While in theory your API can be the database it seems like a footgun for the inexperienced and AI.
- veeti 9mo ago
  AWS also had to add some serious warnings into S3 console to stop people from blowing their foot off with public buckets.
- tonyhart7 9mo ago
  to be fair, Auth and access control is just "hard" problem in general tbh we have so many data breach because they lack "common basic" security best practices, we aren't talking about state level hacker here just public bucket storage and so on
Raed667 9mo ago
> I think what's happening is people are creating additional public users tables and not setting proper RLS for them Yep: https://supabase.com/docs/guides/auth/managing-user-data https://supabase.com/docs/guides/auth/managing-user-data > For security, the Auth schema is not exposed in the auto-generated API. If you want to access users data via the API, you can create your own user tables in the public schema.
giogio 9mo ago
My experience with supabase is it does actually warn you constantly if you don't set up RLS
- bitbasher 9mo ago
  You assume people read. :)
- x0x0 9mo ago
  My experience is watching a colleague use lovable which will mostly ignore security. Sure, if you prompt it the system will do something which seems correct, but it will also happily undo that as well. eg I was trying to help her set up a webhook listener, and it undid our efforts. These tools seem incapable of building software in the hands of users who don't understand security already.
  - embedding-shape 9mo ago
    > These tools seem incapable of building software in the hands of users who don't understand security already. These tools are for augmentation of skills, not for wholesale "imma a programmer now", which a lot of people seem to think. And to be honest, lots of companies are selling that "experience" too, even though they know it isn't true, a bit shit.
    - x0x0 9mo ago
      It's definitely pushed as not needing an engineer. My colleague now understands why unit tests, after watching subsequent development regularly break previous work. Lovable doesn't support them. And I don't want to touch this codebase because I don't want to own it.
- dmix 9mo ago
  People are using LLMs to generate apps and it's easy for non-technical people to miss this stuff. The blog post mentions https://lovable.dev/ https://lovable.dev/ becoming a $300M company, which uses Supabase by default and basically generates React SPA's with no true backend. But random people won't understand this distinction and will want to create full real apps. Doing this serverless is tricky and requires a lot of careful thought to do right. Lovable is not going to tell them to use a proper auth service or fully secure their data. One Lovable project I looked at had generated an entire custom JS Markdown parser instead of using react-markdown, for example.
bArray 9mo ago
> Of course when a friend sends me their new project my natural tendency is to try hack it. Yep. Probably the most relatable tech friend thing to do. I send my projects to friends and get a list of improvement suggestions, it's always fun!
jscheel 9mo ago
The problem is that people just really do not comprehend what the "public" schema means in supabase. My guess is that that they think it means "default" or something along those lines. If you read the supabase documentation, you can clearly see that it says "your database's auto-generated Data API exposes the public schema by default", but to truly understand that, you need to understand what the data api is and how it relies on rls. For people first coming to supabase, they are probably either new devs, or they think of the db as a backend service that has application-layer authentication in front of it.
- EGreg 9mo ago
  That is why in https://github.com/Qbix/Streams https://github.com/Qbix/Streams the default for all streams is PRIVATE. And people can choose what to open up explicitly. We support access templates, mutable access, and inheritance, roles, even participant roles and custom permissions. But the default is private, and all that is machinery on top of it. Read this for a high level overview useful for HN: https://community.qbix.com/t/streams-plugin-access-control/292 https://community.qbix.com/t/streams-plugin-access-control/2...
- christophilus 9mo ago
  Interesting. That would have surprised me if I was a supabase user. I’m used to tossing everything into the public Postgres schema simply because it’s the default schema, and for many small apps, that’s all you need. Supabase should really rethink publicly exposing the default schema without explicit consent from the developer.
  - jscheel 9mo ago
    They do a lot more nowadays to make it clear to the user what is happening, but it still feels unnatural to me.
Jotra7 9mo ago
[dead]
devmor 9mo ago
> I'm not going to blame the vibe-coding wave entirely. As one vibe-coding's most fervent critics, I don't blame it at all. Amateur devs have been doing this for a decade and change with Firebase and other hosted datastores. I got one of my first small jobs as a contractor because of an Android app doing this back in 2012!
deleted 9mo ago
[deleted]
sapphirebreeze 9mo ago
[dead]
stephenlf 9mo ago
After seeing the responses, I believe that this is more evidence of the fact that Supabase is easy to work with (and thus attracts people who have NO IDEA what they’re doing), and less an issue with Supabase security.
- SOLAR_FIELDS 9mo ago
  It’s even worse than No Idea what you are Doing. One can, as has been alluded to in other comments, be a completely naive rube who is using Supabase under the hood with v0 or Lovable and not have any idea that you’re even using it or that it exists at all.
PierceJoy 9mo ago
I find that supabase is pretty good at warning you about these things in their project specific security advisories, but obviously you need to actually pay attention to them and then take action.
mediaman 9mo ago
I don't understand this. In supabase, the default is to turn on RLS for new tables. If you turn it on and have no policy set, no user can fetch anything from the table. You have to explicitly create a read-all policy for anon keys, and with no constraints, for people to get access to it. The default is secure. If you turn off RLS, there are warnings everywhere that the table is unsecured. The author goes on to compare this with PocketBase, which he says you "have to go out of your way" to make insecure. You have to go out of your way with Supabase, as well! I wonder if the author tested this? I do agree that some third party website builders who use supabase on the back end could have created insecure defaults, but that's not supabase's fault.
- SOLAR_FIELDS 9mo ago
  The situation is more nuanced than your comment implies, and a lot of this due to direct product decisions from the Supabase team themselves: https://github.com/orgs/supabase/discussions/4547 https://github.com/orgs/supabase/discussions/4547 The tldr is that Supabase makes this less secure by default because Security is Hard and they don’t want to scare off new users
  - doctorpangloss 9mo ago
    I’m not sure anyone’s scared off by this. It’s more that it’s more intuitive to declare your user queries (like Meteor did or how GraphQL works) than to reason about RLS.
    - SOLAR_FIELDS 9mo ago
      It’s not about being scared off, I’m simply challenging the notion that Supabase is secure by default. It depends on your definition of secure, since everyone has a different threat model, but the above thread demonstrates that probably a good chunk of people would say No, it’s not actually secure by default. Being scared off would be probably the best possible outcome over the current situation which is “we don’t really have a good story to tell about whether this is secure or not”. The fact that it takes a whole thread of conversation to even unwrap whether the default approach they took is good enough is a strong signal to me that it isn’t, because that level of complexity in the implementation often implies a model with a large enough attack surface with weaknesses that can be exploited without too much effort
dangoodmanUT 9mo ago
One thing I find about these "all in one" platforms is that they tend to lure people into a sense of "wow this is easy to use" such that they forget to check security, assuming it's covered. This is one reason why Firebase was such a gold-mine for security researchers: everyone just forgot about security when they forgot about their backend.
- teaearlgraycold 9mo ago
  Any time I see a product like Firebase that rolls auth and other major features into a database I roll my eyes.
  - dangoodmanUT 9mo ago
    Convex has been quite good so far
  - SOLAR_FIELDS 9mo ago
    Are you saying that because you fundamentally just don’t believe the db is a good place for auth, or because these low-code frameworks tend to roll it in and as such you see a lot of low quality implementations of auth from these systems simply because using them is within reach of someone who has no idea what they are doing? To me it’s important to make this disambiguation. One take says that auth in db itself is a problem. The other take says “auth in db is a symptom of low code garbage”
    - vrosas 9mo ago
      FWIW firebase auth and firebase DB are two separate things, and you can use them completely separately. However "Firebase" is a PaaS so I see how it gets confusing.
      - SOLAR_FIELDS 9mo ago
        Fair call out but if I am a firebase customer, as I have been in the past but less frequently so, I treat them as a singular entity. In other words, there’s no situation I would use firebase and not use its auth, because the reason I might use firebase is Because Of the auth, not In Spite Of. There’s no world for me where firebase is the preferred option that doesn’t use auth, the integration like that is literally the only reason I would ever consider ClosedSourceOwnedByGoogle over alternatives
tonyhart7 9mo ago
if your product targeting "dummy user" they should make it dummy foolproof
k4rli 9mo ago
Supabase is great if the goal is insecure, incredibly slow postgres. Selfhosting it is also painful with ~10 separate containers, while supabase's own offering has downtimes that won't appear on their status page. Only thing it actually makes easier is auth. Other stuff just becomes harder to maintain. A simple springboot Java app, especially with basic boilerplate implemented with llm help, will last a long time, be cheap+simple to host, easily extensible.
dmillar 9mo ago
- Enable RLS and/or - Turn off the REST API (if you just use pg connections) - Disable the JWT/anon token(s)
koakuma-chan 9mo ago
Guys, please, stop using all these Vercel-likes. It won't do you any good. There was an excellent article on self hosting PostgreSQL the other day. https://pierce.dev/notes/go-ahead-self-host-postgres#user-content-fn-1 https://pierce.dev/notes/go-ahead-self-host-postgres#user-co...
- wahnfrieden 9mo ago
  That article is good if you don't care about uptime or incident recovery time. Yugabyte is the best open source postgres for HA.
  - cess11 9mo ago
    Once you have reason to care about that, then you should also be able to afford to hire people that can sort it out for you.
    - wahnfrieden 9mo ago
      Not really. Maybe for consumer. But there are many kinds of b2b infrastructure businesses that I can build and launch myself where I wouldn't want to expose myself to risk of day-long outages (for either reputational or as competitive disadvantage of having no HA story), such as anything to do with payment gateways, API gateways, AI proxies or other AI infrastructure - anything where client services would experience critical outages if your service goes down... Lots of these businesses are started without VC investment or big money from day 1. Luckily now with solutions like Yugabyte, we can achieve enterprise-grade HA without high cost or high maintenance complexity.
      - cess11 9mo ago
        I'm not familiar with their products but it seems they had a four hour incident a few months ago: https://status.yugabyte.cloud/history https://status.yugabyte.cloud/history You should not run a payment gateway on an inexperienced team. Start with something with lesser risk and then introduce the team to things like load balancers, keepalived, clustering and so on over time. An hour of downtime is a lot once HA is something to invest in, and the first thing you need to do when there's an incident is to tell your customers what you're doing about it and the second thing they want to know is whether it will happen again. Since I don't know how Yugabyte works I'm not sure about the degree of lock-in, but preferably you should have an incident process where you at minute ten or so of downtime boot load balancing with a customer facing message at another infra provider and update DNS records, then start to rebuild the system there in parallel with the main incident response.
pranavm27 9mo ago
Isn't Supabase anon key actually a publishable one? What's voila about finding it. RLS disabled is a more of a voila here.
dbcpp 9mo ago
Related to this, I've been wondering how much we should actually be depending on RLS for. There are known timing attacks against it [1]. [1] https://www.cs.tau.ac.il/~mad/publications/sigmod2023-rls.pdf https://www.cs.tau.ac.il/~mad/publications/sigmod2023-rls.pd...
fakedang 9mo ago
So, turn it on? You'll get rid of the constant warnings on Supabase too. I mean, Supabase strongly emphasizes using RLS in every part of the dashboard. They literally advise you everywhere not to expose the database data anywhere client side.

112 points by skilldeliver 9mo ago

So like MongoDB twenty-odd years ago?

Supabase doesn’t make a public users table by default. The user schema is in auth and secured. The problem is that unskilled developers bypass those controls out of convenience and put data into Public without RLS. Even the Supabase docs warn against this.

deleted 9mo ago
[deleted]
skilldeliver 9mo ago
The point is that why they even have to make new users table? Something is driving them in this direction and as a counterexample you have Pocketbase where you don't have to.
- MoonWalk 9mo ago
  To store application-specific data about users. The Supabase doc or examples show this. Where else would you put such data? But what the docs don't cover is the provided Users table. Missing documentation is why I gave up on Supabase; and the Users table was one of the first problems I encountered. I could find no details on what to expect in each column at any given time. Upon creating a new user, values get set in this table for no apparent reason. So if your application depends on knowing the verification status of a new user (for example), good luck... Supabase claimed every user was verified upon creation.
  - anxman 9mo ago
    The auth schema is intentionally not exposed to the rest api for security reasons. You need to use an auth hook to put data where you need, or an RPC with appropriate privileges, and of course RLS on any tables.
  - anxman 9mo ago
    https://supabase.com/docs/guides/auth/auth-hooks https://supabase.com/docs/guides/auth/auth-hooks These have gotten much less annoying to use now that it’s controlled through the config.toml.
  - fakedang 9mo ago
    I finally resorted to using Supabase as a Postgres database for Django. In that role, it has worked very nicely.

int0x29 9mo ago

Firebase seems to suffer a similar problem of people not setting permissions right. The only major difference is that they seem to steer devs pretty aggressively to Google auth which won't leak password hashes. While in theory your API can be the database it seems like a footgun for the inexperienced and AI.

veeti 9mo ago
AWS also had to add some serious warnings into S3 console to stop people from blowing their foot off with public buckets.
tonyhart7 9mo ago
to be fair, Auth and access control is just "hard" problem in general tbh we have so many data breach because they lack "common basic" security best practices, we aren't talking about state level hacker here just public bucket storage and so on

Raed667 9mo ago

> I think what's happening is people are creating additional public users tables and not setting proper RLS for them Yep: https://supabase.com/docs/guides/auth/managing-user-data https://supabase.com/docs/guides/auth/managing-user-data > For security, the Auth schema is not exposed in the auto-generated API. If you want to access users data via the API, you can create your own user tables in the public schema.

giogio 9mo ago

My experience with supabase is it does actually warn you constantly if you don't set up RLS

bitbasher 9mo ago
You assume people read. :)
x0x0 9mo ago
My experience is watching a colleague use lovable which will mostly ignore security. Sure, if you prompt it the system will do something which seems correct, but it will also happily undo that as well. eg I was trying to help her set up a webhook listener, and it undid our efforts. These tools seem incapable of building software in the hands of users who don't understand security already.
- embedding-shape 9mo ago
  > These tools seem incapable of building software in the hands of users who don't understand security already. These tools are for augmentation of skills, not for wholesale "imma a programmer now", which a lot of people seem to think. And to be honest, lots of companies are selling that "experience" too, even though they know it isn't true, a bit shit.
  - x0x0 9mo ago
    It's definitely pushed as not needing an engineer. My colleague now understands why unit tests, after watching subsequent development regularly break previous work. Lovable doesn't support them. And I don't want to touch this codebase because I don't want to own it.
dmix 9mo ago
People are using LLMs to generate apps and it's easy for non-technical people to miss this stuff. The blog post mentions https://lovable.dev/ https://lovable.dev/ becoming a $300M company, which uses Supabase by default and basically generates React SPA's with no true backend. But random people won't understand this distinction and will want to create full real apps. Doing this serverless is tricky and requires a lot of careful thought to do right. Lovable is not going to tell them to use a proper auth service or fully secure their data. One Lovable project I looked at had generated an entire custom JS Markdown parser instead of using react-markdown, for example.

bArray 9mo ago

> Of course when a friend sends me their new project my natural tendency is to try hack it. Yep. Probably the most relatable tech friend thing to do. I send my projects to friends and get a list of improvement suggestions, it's always fun!

jscheel 9mo ago

The problem is that people just really do not comprehend what the "public" schema means in supabase. My guess is that that they think it means "default" or something along those lines. If you read the supabase documentation, you can clearly see that it says "your database's auto-generated Data API exposes the public schema by default", but to truly understand that, you need to understand what the data api is and how it relies on rls. For people first coming to supabase, they are probably either new devs, or they think of the db as a backend service that has application-layer authentication in front of it.

EGreg 9mo ago
That is why in https://github.com/Qbix/Streams https://github.com/Qbix/Streams the default for all streams is PRIVATE. And people can choose what to open up explicitly. We support access templates, mutable access, and inheritance, roles, even participant roles and custom permissions. But the default is private, and all that is machinery on top of it. Read this for a high level overview useful for HN: https://community.qbix.com/t/streams-plugin-access-control/292 https://community.qbix.com/t/streams-plugin-access-control/2...
christophilus 9mo ago
Interesting. That would have surprised me if I was a supabase user. I’m used to tossing everything into the public Postgres schema simply because it’s the default schema, and for many small apps, that’s all you need. Supabase should really rethink publicly exposing the default schema without explicit consent from the developer.
- jscheel 9mo ago
  They do a lot more nowadays to make it clear to the user what is happening, but it still feels unnatural to me.

Jotra7 9mo ago

[dead]

devmor 9mo ago

> I'm not going to blame the vibe-coding wave entirely. As one vibe-coding's most fervent critics, I don't blame it at all. Amateur devs have been doing this for a decade and change with Firebase and other hosted datastores. I got one of my first small jobs as a contractor because of an Android app doing this back in 2012!

deleted 9mo ago

[deleted]

sapphirebreeze 9mo ago

[dead]

stephenlf 9mo ago

After seeing the responses, I believe that this is more evidence of the fact that Supabase is easy to work with (and thus attracts people who have NO IDEA what they’re doing), and less an issue with Supabase security.

SOLAR_FIELDS 9mo ago
It’s even worse than No Idea what you are Doing. One can, as has been alluded to in other comments, be a completely naive rube who is using Supabase under the hood with v0 or Lovable and not have any idea that you’re even using it or that it exists at all.

PierceJoy 9mo ago

I find that supabase is pretty good at warning you about these things in their project specific security advisories, but obviously you need to actually pay attention to them and then take action.

mediaman 9mo ago

I don't understand this. In supabase, the default is to turn on RLS for new tables. If you turn it on and have no policy set, no user can fetch anything from the table. You have to explicitly create a read-all policy for anon keys, and with no constraints, for people to get access to it. The default is secure. If you turn off RLS, there are warnings everywhere that the table is unsecured. The author goes on to compare this with PocketBase, which he says you "have to go out of your way" to make insecure. You have to go out of your way with Supabase, as well! I wonder if the author tested this? I do agree that some third party website builders who use supabase on the back end could have created insecure defaults, but that's not supabase's fault.

SOLAR_FIELDS 9mo ago
The situation is more nuanced than your comment implies, and a lot of this due to direct product decisions from the Supabase team themselves: https://github.com/orgs/supabase/discussions/4547 https://github.com/orgs/supabase/discussions/4547 The tldr is that Supabase makes this less secure by default because Security is Hard and they don’t want to scare off new users
- doctorpangloss 9mo ago
  I’m not sure anyone’s scared off by this. It’s more that it’s more intuitive to declare your user queries (like Meteor did or how GraphQL works) than to reason about RLS.
  - SOLAR_FIELDS 9mo ago
    It’s not about being scared off, I’m simply challenging the notion that Supabase is secure by default. It depends on your definition of secure, since everyone has a different threat model, but the above thread demonstrates that probably a good chunk of people would say No, it’s not actually secure by default. Being scared off would be probably the best possible outcome over the current situation which is “we don’t really have a good story to tell about whether this is secure or not”. The fact that it takes a whole thread of conversation to even unwrap whether the default approach they took is good enough is a strong signal to me that it isn’t, because that level of complexity in the implementation often implies a model with a large enough attack surface with weaknesses that can be exploited without too much effort

dangoodmanUT 9mo ago

One thing I find about these "all in one" platforms is that they tend to lure people into a sense of "wow this is easy to use" such that they forget to check security, assuming it's covered. This is one reason why Firebase was such a gold-mine for security researchers: everyone just forgot about security when they forgot about their backend.

teaearlgraycold 9mo ago
Any time I see a product like Firebase that rolls auth and other major features into a database I roll my eyes.
- dangoodmanUT 9mo ago
  Convex has been quite good so far
- SOLAR_FIELDS 9mo ago
  Are you saying that because you fundamentally just don’t believe the db is a good place for auth, or because these low-code frameworks tend to roll it in and as such you see a lot of low quality implementations of auth from these systems simply because using them is within reach of someone who has no idea what they are doing? To me it’s important to make this disambiguation. One take says that auth in db itself is a problem. The other take says “auth in db is a symptom of low code garbage”
  - vrosas 9mo ago
    FWIW firebase auth and firebase DB are two separate things, and you can use them completely separately. However "Firebase" is a PaaS so I see how it gets confusing.
    - SOLAR_FIELDS 9mo ago
      Fair call out but if I am a firebase customer, as I have been in the past but less frequently so, I treat them as a singular entity. In other words, there’s no situation I would use firebase and not use its auth, because the reason I might use firebase is Because Of the auth, not In Spite Of. There’s no world for me where firebase is the preferred option that doesn’t use auth, the integration like that is literally the only reason I would ever consider ClosedSourceOwnedByGoogle over alternatives

tonyhart7 9mo ago

if your product targeting "dummy user" they should make it dummy foolproof

k4rli 9mo ago

Supabase is great if the goal is insecure, incredibly slow postgres. Selfhosting it is also painful with ~10 separate containers, while supabase's own offering has downtimes that won't appear on their status page. Only thing it actually makes easier is auth. Other stuff just becomes harder to maintain. A simple springboot Java app, especially with basic boilerplate implemented with llm help, will last a long time, be cheap+simple to host, easily extensible.

dmillar 9mo ago

- Enable RLS and/or - Turn off the REST API (if you just use pg connections) - Disable the JWT/anon token(s)

koakuma-chan 9mo ago

Guys, please, stop using all these Vercel-likes. It won't do you any good. There was an excellent article on self hosting PostgreSQL the other day. https://pierce.dev/notes/go-ahead-self-host-postgres#user-content-fn-1 https://pierce.dev/notes/go-ahead-self-host-postgres#user-co...

wahnfrieden 9mo ago
That article is good if you don't care about uptime or incident recovery time. Yugabyte is the best open source postgres for HA.
- cess11 9mo ago
  Once you have reason to care about that, then you should also be able to afford to hire people that can sort it out for you.
  - wahnfrieden 9mo ago
    Not really. Maybe for consumer. But there are many kinds of b2b infrastructure businesses that I can build and launch myself where I wouldn't want to expose myself to risk of day-long outages (for either reputational or as competitive disadvantage of having no HA story), such as anything to do with payment gateways, API gateways, AI proxies or other AI infrastructure - anything where client services would experience critical outages if your service goes down... Lots of these businesses are started without VC investment or big money from day 1. Luckily now with solutions like Yugabyte, we can achieve enterprise-grade HA without high cost or high maintenance complexity.
    - cess11 9mo ago
      I'm not familiar with their products but it seems they had a four hour incident a few months ago: https://status.yugabyte.cloud/history https://status.yugabyte.cloud/history You should not run a payment gateway on an inexperienced team. Start with something with lesser risk and then introduce the team to things like load balancers, keepalived, clustering and so on over time. An hour of downtime is a lot once HA is something to invest in, and the first thing you need to do when there's an incident is to tell your customers what you're doing about it and the second thing they want to know is whether it will happen again. Since I don't know how Yugabyte works I'm not sure about the degree of lock-in, but preferably you should have an incident process where you at minute ten or so of downtime boot load balancing with a customer facing message at another infra provider and update DNS records, then start to rebuild the system there in parallel with the main incident response.

pranavm27 9mo ago

Isn't Supabase anon key actually a publishable one? What's voila about finding it. RLS disabled is a more of a voila here.

dbcpp 9mo ago

Related to this, I've been wondering how much we should actually be depending on RLS for. There are known timing attacks against it [1]. [1] https://www.cs.tau.ac.il/~mad/publications/sigmod2023-rls.pdf https://www.cs.tau.ac.il/~mad/publications/sigmod2023-rls.pd...

fakedang 9mo ago

So, turn it on? You'll get rid of the constant warnings on Supabase too. I mean, Supabase strongly emphasizes using RLS in every part of the dashboard. They literally advise you everywhere not to expose the database data anywhere client side.