August 19th, 2024

Client-side filtering of private data is a bad idea

Matthew Garrett revealed security vulnerabilities in the dating app Feeld, indicating misleading privacy claims, retrievable sensitive data, and challenges in reporting issues, stressing the need for robust security measures.

Read original articleLink Icon
Client-side filtering of private data is a bad idea

Matthew Garrett discusses the security vulnerabilities he discovered in the dating app Feeld, which is popular among alternative relationship communities. He highlights that the app's claim of protecting user privacy is misleading, as he found that private data could be accessed through simple queries. By analyzing the app's code, he identified that certain fields, such as "lookingFor" and "ageRange," were not displayed in the user interface but were still retrievable through the app's queries. This indicates that the app was not adequately protecting sensitive information. Additionally, hidden profiles were still included in the data sent to the app, raising further privacy concerns. Garrett faced challenges in reporting these issues, as there was no clear security contact, but eventually communicated with Feeld's security team, who confirmed that the vulnerabilities had been addressed. He emphasizes that client-side filtering is insufficient for protecting private data and that developers must implement robust security measures to prevent unauthorized access. While he acknowledges that some aspects, like private images and location data, appeared to be secure, he stresses the importance of thorough verification to ensure all potential vulnerabilities are resolved.

- Feeld's privacy claims were found to be misleading, as private data could be accessed through queries.

- Sensitive fields were retrievable even if not displayed in the app's user interface.

- Hidden profiles were still included in data sent to the app, raising privacy concerns.

- Garrett faced difficulties reporting the vulnerabilities but successfully communicated with Feeld's security team.

- Emphasizes the need for robust security measures beyond client-side filtering to protect private data.

Link Icon 12 comments
By @avh3 - 5 months
The title reads like: "Why jumping from a bridge is a bad idea". Does this needs to be stated?
By @Sephr - 5 months
Caveat to the title: Except for local client-side data emissions. Filtering private data before it gets sent from your device in the first place is a good idea.
By @globular-toast - 5 months
I wonder how many backends are just pure CRUD with all business rules implemented on the frontend? Scary to think. I'm forever having to tell devs that form validation in js isn't enough, you need to do it on the backend too (or, preferably, only). This article is about reading data you shouldn't be able to, but my strong suspicion is a bunch of stuff out there will let you write stuff you shouldn't be able to as well.
By @cesarb - 5 months
This is a risk common to all "fat clients", when the same team develops both the server code and the client code: it's easy to forget that, unlike the server code, the client code cannot be trusted.
By @dboreham - 5 months
Translated: implementing a server query interface with insufficient access controls is a bad idea.

The article is mostly about the resulting security by obscurity being broken.

By @Cerium - 5 months
They should learn about bloom filters. Could kill two birds with one stone, fix leaking the preferences via the swipe list and fix the ever growing query problem.
By @robertclaus - 5 months
I've always been a bit suspicious that mistakes like this are easier in GraphQL than older REST (or even SOAP) models because GraphQL is designed for more frontend-driven development. Obviously this is just one example, but it was interesting that it involved "hidden" GraphQL data.
By @Arch-TK - 5 months
Long post to say that yet another application had an access control issue which was being masked because the access control was implemented on the client.

Incredibly common in my experience in the security field.

By @olliej - 5 months
Oh I see, the claim is “we don’t do the result filtering ourselves so we don’t know what you’re looking for” but that is done by … taking your filters and broadcasting them to everybody?

So they’ve removed the server from the filtering process but made the privacy implications far worse.

By @andreareina - 5 months
403 Forbidden
By @autoexec - 5 months
I don't understand this idea that you can do anything "privately" on a device designed to collect and leak your personal information whose admin is a corporation that can make changes to the system at any time without your consent or awareness, and where multiple parties (carrier, and manufactures) have privileged access to do the same, and where your own access is extremely limited and controlled. The entire system is totally insecure and non-private by design.

The idea that dating app could prevent your preferences from being collected seems unlikely to me too. If people are posting profiles and messaging each other on a platform, that platform is going to have no problem learning what their interests are. They don't need to know what you're searching for, as long as they know who you're finding.

By @kkfx - 5 months
Ehm... A long time developer do think data sent on someone else machine can still be "private"? Ehm... Mh... I have some issue to find a politically correct way to state the fact that no damn laws can "protect" people who send anything to a third party...

BTW if some user of a dating service is concerned about his/her own searches... More than beings scared about "potential client-side leaks other dating service user might harvest" try to concentrate on how much personal dating interests the service can harvest and eventually re-sell, if not "the service" just some working for it and having some side business...