BDSM, LGBTQ+, and sugar dating apps have been found exposing users’ private images, with some of them even leaking photos shared in private messages.
BDSM, LGBTQ+, and sugar dating apps have been found exposing users’ private images, with some of them even leaking photos shared in private messages.
So the devs were inexperienced in secure architectures and put a bunch of stuff on the client which should probably have been on the server side. This leaves anyone open to just use their API to access every picture they have on their servers. They then made multiple dating apps with this faulty infrastructure by copy-pasting it everywhere.
I hope they are registered in a country with strong data privacy laws, so they have to feel the consequences of their mismanagement
Inexperienced? This is not-giving-a-fuck level.
No, it’s lack of experience. When I was a junior dev, I had a hard enough time understanding how things worked, much less understanding how they could be compromised by an attacker.
Junior devs need senior devs to learn that kind of stuff.
It does help if services that generate or store secrets and keys display a large warning that they should be kept secret, every time they’re viewed, no matter the experience level of the viewer. But yeah understanding why and how isn’t something that should be assumed for new devs.
I’ve met the type who run businesses like that, and they likely do deserve punishment for it. My own experience involved someone running gray legality betting apps, and the owner was a cheapskate who got unpaid interns and filipino outsourced work to build their app. Guy didn’t even pay 'em sometimes.
Granted, you could also hire inexperienced people if you’re a good person with no financial investor, but that I’ve mostly seen with education apps and other low profit endeavors. Sex stuff definitely is someone trying to score cash.
Do you reckon this app could have been vibecoded/a product of AI? Or massive use of AI in development? I’d know not to do this as a teenager when I was beginning to tinker with making apps, nevermind an actual business.
I know for a fact that a lot of applications made these mistakes before AI was around so while AI is a possibility it is absolutely not necessary.
I had a test engineer demand an admin password be admin/admin in production. I said absolutely not and had one of my team members change it to a 64-character password generated in a password manager. Dumbass immediately logs in and changes it to admin again. We found out when part of the pipeline broke.
So, we generated another new one, and he immediately changed it back to admin again. We were waiting for it the second time and immediately called him out on the next stand-up. He said he needs it to be admin so he doesn’t have to change his scripts. picard_facepalm.jpg
How is he not fired? Incompetence and ignorance is one thing, but when you combine it with effectively insubordination… well, you better be right. And he is not.
Firmly agree, I don’t believe he should have had access to change these password in the first place unless I’m misunderstanding their definition of test engineer, but if OP had the authority and permission to change the password in the first place, and that person deliberately changed it back to the insecure route again, management would be involved and there would some sort of reprimandment because that’s past ignorance, that’s negligence
It was an admin account to do regression testing for the admin interface and functions before prod releases.
I had my guys enable/disable the account during the testing pipeline so people can’t login anymore.
Why would you have regression on prod? Or why would you care what the password is on staging environments?
We have our lower environments (where all testing happens) on a VPN completely separated from prod, and testing engineers only ever touch those lower environments. Our Ops team manages all admin prod accounts, and those are completely separate from lower environment accounts.
So I guess I’m struggling to understand the issue here. Surely you could keep a crappy password for pre-prod testing? We even create a copy of prod as needed and change the admin accounts if there’s something prod-specific.
The production database gets down-synced to the lower environments on demand, so they can test on actual production datasets. That would require us to manually remake this user account every time a dev down-syncs the database to a lower environment.
The customer is paranoid, as the project is their public facing website, so they want testing against the actual prod environment.
We don’t mange the SSO, as that is controlled by the customer. The only local (application specific) account is this account for testing.
He was a subcontractor, so technically, he’s not our employee.
I bubbled it up the chain on our side, and it hasn’t happened since.
my main question in this is, why does a test engineer have the credentials to change an admin password in production. Like I get that he needs to test things but I doubt he needs access to changing profile/account settings
He had to do admin functionality regression tests before prod releases to make sure nothing broke.
The system uses SSO for logins for everything else.
He is a subcontractor who was using scripts for all his projects. I told him he really needs to use env vars for creds.
The illusion of choice
A lot of “normal” dating apps are also owned by the same companies
Every single one of those “secrets” is publicly available information for every single Firebase project. The real issue is the developers didn’t have proper access control checks.