this post was submitted on 28 Jul 2025
328 points (97.4% liked)
Technology
73465 readers
3749 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
Every time. With startups, it's always an unsecured Firebase or S3 bucket.
I'm certainly no web security expert, but shouldn't Tea's junior network/backend/security developers, let alone seniors, know how to secure said Firebase or S3 buckets with STARTTLS or SSL certificates? Shouldn't a company like this have some sort of compliance department?
It's a little more complex than that. If you want the app on the user device to be able to dump data directly into your online database, you have to give it access in some way. Encrypting the transmission doesn't do much if every app installation contains access credentials that can be extracted or sniffed.
Obviously there are ways around this too, but it's not just "use TLS".
Encrypt the credentials then? Or OAUTH pipeline, perhaps? Automated temporary private key generation for each upload (that sounds unrealistic, to be fair)? Can credentialing be used for intermediary storage that encrypts the data on that server and then decrypted on the database host?
Clearly my utter "noobishness" is showing, but at least it's triggering a slight urge to casually peruse modern WebSec production workflows. I am a DNN researcher. Thus, I am far removed from customer-facing production environments, and it shows.
Any recommendations on literature or articles on how engineers solve these problems in a "best practices" way that you can recommend? I suppose I could just look it up, but I thought I'd ask.
Edit: I don't know why I'm down-voted. My questions were sincere.
You've got the right ideas. Noone should ever be storing any password in plaintext. It should always be hashed and only the hash stored. That's like WEBDEV99 (remedial course, not even 101).
Really. Despite your stated "noobishness", you basically landed in the territory of best practices right of the bat.
If you're looking for a good source of best practices, the CIS benchmarks are great. https://www.cisecurity.org/
Brother, I need the "remedial" lessons since I self-host a lot of my experimental DNN solutions on a GPU cluster served via CasaOS/Ubuntu-Server LTS.
I've followed basic tutorials about nginx, end-to-end encryption, and DNS, but I need more knowledge and training about the theory behind modern security best practices. I think I'm doing okay but I have this ever-present anxiety that I've overlooked something and my ass (i.e., sensitive data) is really just hanging out in the wind.
Thank you for your recommendation.
I am not sure, but I read somewhere that the developer(s) used vibe coding to create the app so...
A lot of people have speculated that.
According to their statement their code was written in Feb/2024 and predates "vibe coding"
What intrigue me is this:
So they used vibe coding, they are only saying that they think/hope that it is not the cause of the break (and maybe also of the second one)
And if vvibe coding is not caused then they are even more incompetent.
My hey we’re probably using Firestore as their database without authenticating their api calls to firebase functions. Basically leaving their api endpoints open to the public Internet.
They could have connected service account and used some kind of auth handshake between that and generate a temporary login token based on user credentials and the service account oauth credentials to access the api. but they probably just had everything set to unauthenticated
Yup. It sounds like they were following security worst practices.
I get doing that in Dev for testing before launch, but in production? that’s insane.
Like it has to either be a junior developer playing the role of lead or some serious lack of web dev fundamentals haha
I'd argue that it should not even be done in Dev. Dev, staging/testing, and prod environments should all be as close to one another as possible, especially for infra like datastores.