Vulnerabilities in the Feeld dating app

Severe security flaws in the Feeld dating app reportedly left intimate photos, matches, chats and other highly sensitive data effectively public, with access controls implemented only in the client and easily bypassed. Commenters condemn the company’s apparent cost-cutting, weak engineering practices, and slow remediation despite substantial revenue, arguing that handling sexual preference and identity data this carelessly borders on criminal negligence. The incident is used to highlight broader problems in dating apps, GraphQL-based backends, and an industry where meaningful penalties for privacy failures are rare, leaving users to assume anything they share could become public.

Overall reaction

  • Many commenters describe the vulnerabilities as “criminally negligent,” especially given the app’s focus on highly sensitive sexual data.
  • The issues are seen as embarrassingly basic, the kind of security mistakes that should have disappeared a decade ago.

Security and engineering failures

  • Core problem: authorization/permission checks appear to be enforced largely on the client side instead of the backend, across many endpoints.
  • Commenters compare this to “decorative” security: easy to bypass, similar to classic front-end-only auth or plain-JS password checks.
  • Some suspect use of “automatic DB APIs” / magic GraphQL-to-SQL layers that encourage exposing too much by default.
  • Several note that such mistakes remain common in mobile and web apps, especially when written quickly, cheaply, or by juniors without oversight.

Company practices and responsibility

  • Multiple users report the app has long been buggy: broken chats, performance problems, memory leaks, UX confusion.
  • There is debate over whether founders are non-technical or simply incompetent; either way, management is blamed for underinvesting in security and engineering.
  • Some point to public financial success as evidence they had the resources to fix this but chose not to.
  • The contractor-led 2023 rewrite is cited as a turning point where things became even buggier; unclear if backend was also replaced.
  • Strong sentiment that fines, regulatory enforcement, and possible criminal liability are needed; “they don’t need charity, they need to be fined.”

Disclosure process

  • Mixed views on the researchers’ long embargo: some praise their restraint; others argue that giving 6+ months for such egregious issues rewards negligence and should be shortened.
  • People wonder how many others discovered and exploited these flaws quietly; logs are suggested as the only way to know, but their status is unknown.

User attempts to protect themselves

  • Several commenters tried to delete their data after reading the report and found the deletion flow broken or impossible.
  • Others advocate never using exact personal data (e.g., birthdate) and treating all dating-app data as effectively public.

Broader dating-app ecosystem

  • Many see this as symptomatic of the entire for-profit dating space: few viable options, heavy data collection, weak security, misaligned incentives.
  • Ideas raised include open-source or federated, non-profit / B‑Corp alternatives, possibly using ActivityPub, though network effects and moderation are seen as major barriers.