Replies: 1 comment
-
Very well put and eloquently phrased questions that much resonate with my own reservation; may I ask if you have found some solutions to them yet? Maybe add a new bucket for each user project. Buckets can have max size. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey all, new to supabase (or firebase for that matter). Hacked on a little app that I'd slowly like to release but have a few questions about security and best practices. I'm coming from a traditional server background so going with something that isn't a backend that I've written is uncharted waters for me.
It's great that I can just build my entire app with the client SDKs, and I know that I can do a lot with policies. But from what I gathered, once a user has UPDATE permission on, say, "avatars" to update their avatar, wouldn't they also have full permission to just hit the REST API directly and mess with whatever columns are in that row? For example monkey with timestamps or even just changing the url, or changing the user_id of an object to force an avatar onto someone else?
Are the goto best practice for this VIEWs or triggers like mentioned here? https://github.com/orgs/supabase/discussions/656
This wasn't so easy to find so I'm sure more people aren't doing that.
Should I focus on very small tables the user can access that only have the absolute minimum in them?
I could also write my own edge function that strips data and returns it in the shape that I want, but then I'm kind of back at just writing my own backend
Similar 1), but for storage. I can of course add policies that restrict actions to only files the user themselves have uploaded, or to files that are under a specific folder like:
But this would still give the user permission to upload whatever they want and monkey with objects in that bucket/folder. For example renaming a file (unless UPDATE is stripped), inserting/spamming smaller files or freely deleting without going through the application path which would leave the database relations in a broken state.
Yeah I can write an Edge function to do that like https://github.com/supabase/supabase/blob/master/examples/edge-functions/supabase/functions/file-upload-storage/index.ts, but is this the best practice for handling user files?
Coming with the "Don't trust the user" mindset, is there something obvious I missed? 😄
Beta Was this translation helpful? Give feedback.
All reactions