this post was submitted on 28 Jul 2025
345 points (97.5% liked)
Technology
73540 readers
2728 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Wouldn't some sort of proxy in between the bucket and the client app solve this problem? I feel like you could even set up an endpoint on your backend that manages the upload. In other words, why is it necessary for the client app to connect directly with the bucket?
Maybe I'm not understanding the gist of the problem
Exactly, it's not necessary. It's bad / lazy design. You don't expose the DB storage directly, you expose a frontend that handles all the authentication and validation stuff before accessing the DB on the backend. That's normal Client-Server-Database architecture.
Yeah. You also landed on a correct thought process for security. Cloud providers will let you make datastores public but that's like handing over a revolver with an unknown number of live chambers and saying "Have fun playing Russian roulette! I hope you win." Making any datastore public facing, without an API abstraction to control authN and authZ is not just a bad practice, it's a stupid practice.