Swipe, Match… Leak: Unauthenticated Phone-Number Exposure in the InPerson Dating App

Executive Summary

#

InPerson (inperson.social) is an Israeli dating app whose entire premise is discretion — its own tagline promises “everything is anonymous; no one will know that you liked them.” While browsing the app as a genuine user, I noticed that this promise was broken at the most fundamental level.

Every user’s profile photos were stored in cloud storage inside a folder named after that user’s phone number. That folder name — the raw phone number — was exposed directly in the page’s client-side source, retrievable with nothing more than a browser’s built-in developer tools. No account, no authentication, and no meaningful technical skill were required to harvest the phone numbers of the very people the app was showing you.

Crucially, the numbers were exposed at the profile-display stage — before the person being viewed had seen you back, and long before either side pressed “like.” The leak even reached visitors who had not registered at all: a new user is shown a handful of profiles before being asked for any details, and the phone numbers were already extractable at that point.

On a dating platform — where users share personal information specifically to meet strangers, and where anonymity is the product — a real-time, unauthenticated phone-number leak is a serious safety issue, not merely a privacy one. Exposed numbers can be used for extortion, harassment, and targeting.

Context matters. Data-breach severity is highly context-dependent. A leaked phone number from a pizza-delivery site is a problem; the same number leaked from a dating platform — where users expect discretion — is a safety risk. Every leak here is unauthenticated, real-time, and trivially automatable.

Threat Model & Attack Surface

#

The exposure sat on an entirely unauthenticated surface:

• Profile photos served from cloud storage using a path keyed on the user’s phone number
• That path — and therefore the phone number — present in the client-side source and network traffic
• Profiles (and thus numbers) shown before any mutual interaction or “match”
• The onboarding flow displaying sample profiles to visitors before requiring registration

This is not an edge case reachable only by authenticated, matched users — it is the default browsing experience, available to anonymous visitors.

Technical Finding

#

When a user registered and uploaded a photo of themselves, the image was stored in cloud storage inside a directory whose name was the user’s phone number. Each account’s media was effectively addressed by its owner’s phone number.

The problem: that directory name was exposed verbatim in the page’s client-side source. Photos were served from Google Cloud / Firebase Storage, and the object path embedded the account’s phone number (in full international format, 972…) as the folder name. Rendering a profile required referencing its photos, and referencing its photos meant emitting the storage path — phone number included. Anyone viewing a profile could open developer tools (available in every browser, no special tooling required) and read the number directly:

https://storage.googleapis.com/<project>.appspot.com/profile-images/972XXXXXXXXX/main_<timestamp>.jpg
                                                     └──────┬──────┘
                                               the folder is the user's phone number

Because profiles are presented during ordinary browsing — and during the pre-registration preview shown to brand-new visitors — the phone numbers were retrievable:

1. Before the viewed user had any awareness they were being shown to the viewer.
2. Before any “like” or match occurred between the two parties.
3. Without the viewer holding an account at all.

Impact. An anonymous party could collect the phone numbers of single men and women actively seeking connection, tied to their dating profiles and photos. Given the platform’s purpose, that data is directly usable for extortion, harassment, and targeting — precisely the outcomes a dating app’s anonymity guarantee is supposed to prevent.

Root Cause

#

1. Identity used as a storage key. The user’s phone number — a piece of sensitive PII — was used as the human-visible identifier for their media directory. Sensitive identifiers must never double as object keys that surface in client-facing paths.
2. Sensitive data leaking through the client. Rendering a profile exposed the underlying storage path, so a value that should never reach the browser was emitted into the page source.
3. No access-control boundary on the media layer. Photo references (and their embedded numbers) were served without any check tying them to an authorized, matched relationship.

Remediation Recommendations

#

Immediate

• Stop using phone numbers (or any PII) as storage keys or directory names; use opaque, random identifiers (e.g. UUIDs).
• Never emit internal storage paths to the client; serve media through short-lived, signed URLs that carry no identifying information.
• Enforce authorization on media access so photos are only retrievable within a legitimate, mutual context.

Long-Term

• Conduct a professional security review by a human expert, not automated scanning alone.
• Treat phone numbers and profile linkage as high-sensitivity data across the whole architecture.
• Maintain a working, monitored security-contact channel (see disclosure note below).

Disclosure Timeline

#

• 12 August 2026 — Discovered the exposure while using the app as a genuine user; identified the issue immediately upon opening a profile. Reported it to InPerson the same day via email and LinkedIn, and independently flagged it to TheMarker.
• 12–18 August 2026 — No substantive response from the company through my direct channels.
• 18 August 2026 — InPerson claimed the issue had been fixed.
• 25 August 2026 — TheMarker published its report (after reaching the project’s manager directly for comment). Israel’s Privacy Protection Authority confirmed it had opened an administrative supervisory process.

InPerson later acknowledged that the security-contact email listed in its own privacy policy was not active — a reminder that responsible disclosure depends on a working channel on the other end. In its statement, the company said the flaw was fixed and verified, that it had run a broader round of tests, and that it “takes any such finding very seriously.”

Post-Publication: The Fix Was Incomplete

#

Following publication, further review — by both TheMarker and myself — showed the initial remediation was partial. The specific photo-folder path had been addressed, but the underlying pattern (treating identity as a public identifier, and trusting the client to enforce privacy) persisted in other parts of the product.

The follow-up findings fell into three buckets:

• Identity still used as a key. Some records continued to expose the user’s phone number as the account identifier, rather than an opaque ID — the same root cause, surfaced through a different path.
• Event registration data. A data path serving event/registration details exposed registrants’ personal information (name, phone, photo) more broadly than intended. (This one was subsequently addressed by the vendor.)
• The “anonymous” model was only skin-deep — and still is. The app’s core promise is that likes are private and identities stay hidden until there is a mutual match. In practice, a data path backing the “people who liked you” view returns full profile details regardless of that anonymous state — name, photo, age, bio, relationship intent, and, for phone-registered accounts, the phone number — and a request parameter intended to limit the response can be adjusted to return complete PII. Tellingly, the server’s own response carries a field marking the list as reveal: "anonymous" — the backend knows these identities are supposed to be hidden, labels them as such, and then ships every liker’s full record anyway. The privacy guarantee is enforced by the interface choosing not to display the data, not by the server withholding it.

In keeping with responsible-disclosure practice, this write-up deliberately withholds the exact endpoints, parameters, storage identifiers, and proof-of-concept for any issue that is not yet confirmed remediated — the goal is to document the failure pattern and its impact, not to hand anyone a working recipe against real users. Full technical specifics will be published here once the vendor confirms each fix.

The broader lesson: a security fix that patches the one path a researcher happened to name — without addressing the architectural root cause — leaves the same class of exposure live everywhere else it appears.

Press Coverage

#

This research was reported by TheMarker (Haaretz Group) in Ran Bar-Zik’s Captain Internet column:

👉 On the InPerson dating site, “everything is anonymous” — except the users’ phone numbers (TheMarker, 25 August 2026 — Hebrew)

Closing Thoughts

#

A dating app’s core promise is discretion; here, the architecture quietly broke that promise for every user. The lesson is the same one that runs through much of my work: sensitive identity data must never be used as a lookup key or leak through the client. When it does, “anonymous” becomes a marketing line rather than a security property.

The responsible-disclosure friction in this case — an unmonitored security inbox, no reply until the press intervened — is also worth flagging. Good-faith reporters need a channel that actually reaches someone.

If you’d like to discuss this research or related security topics, you can reach me on LinkedIn.