How Public Dating Security Actually Works

The base model

The same request can be normal, abusive, or dangerous. Context decides which

In security, "I received a profile through an API" is not enough. We must establish who the profile was meant for, whether authentication existed, which fields were returned, whether a server rule was bypassed, and at what scale the request was repeated.

An open dating service is designed to show profiles to other participants. The server accepts a request, selects a suitable card, and returns a name, bio, city, interests, and published photos. That is useful functionality. The same request becomes a problem if it exposes private chats, payment records, internal fields, or content the user never published.

The data boundary

A public profile does not mean an entire account is public

A user publishes a profile in order to be discovered. A profile photo, display name, stated age, bio, and selected interests are therefore intended for other people in the service. Visibility is not a contradiction in this model. It is the purpose of publishing.

At the same time, the service holds data that is not intended for general viewing: access tokens, moderation history, payment records, internal signals, private conversations, and technical logs. The meaningful security boundary lies between these groups.

Calling an entire API response "personal data in the open" without examining its fields is like calling a shop window a breached warehouse. The window really is visible. That proves nothing about access to the stockroom.

Likes and open dating

Being able to like a known public profile is normal product behavior

Dating exists so people can discover one another and express interest. If a participant has already seen a public profile in the feed, a top list, search, or an internal link, the ability to react is logical. Whether the request comes from the official interface or another technical client, authority is still defined by the server.

The phrase "the API can like anyone" needs three qualifications. First, the target is an existing public profile, not access to someone else's account. Second, an authenticated user sends the request in their own name. Third, the action remains subject to server rules and limits.

Current Mimolet likes are limited by the server according to plan: 60, 250, 500, or 1,200 actions per day. The ability to reach a reaction route is therefore not the same as unlimited bulk action.

Public photos

If a photo is displayed, it can be saved. No social network can repeal that fact

To display an image, a server must deliver it to a browser or app. After delivery, a user can take a screenshot, record the screen, inspect the cache, capture the network response, or photograph the display with another device. This is not a Mimolet peculiarity. It is how public content works on Instagram, TikTok, Telegram, and ordinary websites.

A presigned URL is useful when access to the source object should expire. It complicates later reuse of the old link, but it cannot erase a downloaded file. Disabling the context menu hides a menu, not data. A watermark supports investigation but does not prevent copying. DRM raises the cost of video extraction but still cannot stop screen recording.

Honest security does not sell a physically impossible promise. It minimizes unnecessary disclosure, separates public and private data, makes bulk collection harder, and responds quickly to abuse.

Scraping without magical thinking

Automation cannot be eliminated. It can be made expensive, bounded, and visible

A script can reproduce user actions. The more public a service is, the more surfaces it offers for automation. Search engines crawl pages, analytics systems collect prices, marketing tools analyze social networks, and abusers imitate browsers. There is no universal "disable scraping" switch.

A rate limit reduces speed, but distributed collection uses many addresses and accounts. CAPTCHA filters simple scripts but harms accessibility and can be outsourced. Device binding helps but creates friction when phones change. Protection is therefore layered and proportional to actual risk.

"Automation is possible" does not imply "a private database was obtained." Data category, authority, speed, sample completeness, and the ability to bypass control budgets all sit between those statements. The Habr framing jumps over those steps and selects the most alarming label.

Terminology

IDOR begins with broken object authorization, not with the existence of an ID

IDOR occurs when changing an identifier gives a user an object they have no right to access. The important element is not the shape of the ID or the ability to edit a URL. It is the missing authority check.

If every participant is allowed to see a public profile, requesting that profile by a known identifier does not by itself prove IDOR. If the same technique reveals a hidden profile, someone else's chat, an unpublished file, or an internal field, the boundary has been crossed.

Subscriptions and product logic

Liking a known profile and revealing who liked you are not the same feature

Premium dating plans often provide incoming likes, advanced filters, priority, and larger limits. That does not mean the subscription sells the right to like a specific person. If a profile is already known through the public product, an ordinary reaction remains an ordinary reaction.

To prove a Premium bypass, a free user must obtain the paid result itself: a real identity in incoming likes, an original photo, bulk processing, or another gated capability. The existence of a general reaction route proves none of those outcomes.

The current free incoming-likes response in Mimolet does not reveal the real ID, name, or original photo URL. Bulk response verifies the subscription on the server. The claim should be evaluated against that current result, not against the superficial similarity of two buttons.

Sessions, devices, and bans

Multiple active sessions are normal. Session fixation is a specific attack

A user may sign in from a phone, browser, and Telegram Web. Each context receives a session. Several working tokens do not show that an attacker forced a victim to use a session identifier already known to the attacker. Without that mechanism, the session fixation label is incorrect.

Rigid IP binding is not a universal baseline control either. Mobile addresses change between towers, CGNAT groups thousands of people, and VPNs switch exit nodes. Such a check creates mass false logouts and offers little protection against an attacker on the same network.

The meaningful test is whether a blocked account can continue protected actions. The current Mimolet API checks blocked status on every authenticated request. The decision is made by the server, not merely by the screen to which the user is redirected.

Historical code and the current product

A technical article becomes stale when it continues to present removed routes as today's architecture

The first publication bases much of its story on several PHP files and a negative offset. Those entry points no longer serve the product. Current Mimolet uses a different API with mandatory authentication and server-side checks.

Today's 404 responses do not rewrite history or prove the state of a particular day in the past. They prove something narrower: those old routes cannot describe the current product. A current conclusion requires testing the current architecture.

From a network response to a business fantasy

An API does not reveal contracts, accounting, advertisers, or bank accounts

The number of collected profiles does not reveal monthly active users. Telegram channel subscribers do not reveal app activity. An LLC registration address does not establish a tax violation. Network traffic cannot expose advertising contracts that do not exist.

Nevertheless, the publication combines these unrelated numbers into a story about ad sales, "unofficial accounts," investors, and intentionally weak security. None of those conclusions came from access to contracts, bank records, accounting, or company analytics.

A technical test can prove a server response. Without additional sources, it cannot prove an owner's motive, movement of money, or an advertiser relationship.

Scores, icons, and authoritative presentation

CVSS measures a specific vulnerability through a vector. It is not a scale of textual emotion

A CVSS score is built from formal parameters: network reachability, complexity, required privileges, user interaction, and impact on confidentiality, integrity, and availability. A verifiable score includes the complete vector and exact exploitation conditions.

The source text places "criminal prosecution," "loss of advertisers," and "payment blocking" next to self-assigned numbers. These claims are not CVSS parameters and do not automatically follow from a technical observation. The forecast of lost advertisers is especially revealing for a product that never sold advertising.

Legal classification also depends on the data involved, processing mode, operator actions, and applicable law. Writing "violation" under a table does not turn a private opinion into a regulator or court decision.

A verifiable example from the second post

The Exim banner exposed a base version, but the author treated it as the full Ubuntu revision

The sequel used Exim 4.97 Ubuntu as evidence of CVE-2026-45185. That is insufficient on Linux distributions because security fixes are often backported without changing the upstream base version. The external banner does not expose the Ubuntu package suffix.

Ubuntu's official security page states that the fix for Ubuntu 24.04 entered package 4.97-4ubuntu4.5. That revision was installed on the server on May 14, followed by .6 on June 3. The post appeared on June 27. The claim of a vulnerable version was therefore wrong on its publication date.

Research quality

A large dump does not replace minimal proof, and AI-style writing does not replace verification

A bug can usually be demonstrated with minimal reproduction using the researcher's own or purpose-built test data. Downloading thousands of profiles does not prove the mechanism more strongly. It only increases the amount of other people's data held by the researcher and the consequences of the researcher's own actions.

The publication contains visible signs of generation or heavy AI editing: repeated severity and business-impact matrices, mechanical analogies, emoji risk levels, formulaic summaries, and confident conclusions where sources are missing. This does not prove a specific model, but it helps explain why the format feels stronger than the evidence.

What matters today

Real Mimolet security is measured by current boundaries, not archived drama

No live service ever finishes security work. Limits are refined, anti-bot signals grow stronger, legacy routes are removed, and authorization rules receive regression tests. But an endless pursuit of impossible absolute protection should not replace the business reality of an open product.

• Current profile and feed routes require authentication and return 401 without login.
• The cited legacy routes and diagnostic file have been removed and return 404.
• Blocked-user status is checked on every API request.
• Likes are limited by the server, not only by the interface.
• Free incoming likes do not reveal real IDs, names, or original media paths.
• Anonymous S3 listing is disabled, and new media names are not based on Telegram IDs.
• A displayed public photo remains saveable because otherwise it could not be displayed.

The precise formula is simple: public content is a product model, an API is a transport, scraping is a scale risk, and a vulnerability is a demonstrated bypass of a specific boundary. Mixing these concepts is useful for sensation and useless for security.