BaitPath

How to confirm the app you downloaded and the site you opened are real

An imitation site does not need to fool you for long. It needs about fifteen seconds — the gap between the page loading and you typing a password.

Case file cover: high-contrast geometric composition of layered rectangles and a cut band
File A-03 cover is a programmatic geometric composition.

Most advice on this topic is a list of things fakes do. That list is endless and you will not carry it around. The approach here is the opposite: establish one reference point you trust, and measure everything against it.

Start by fixing the real one in place

Verification needs a reference. If you locate the site fresh every time, you take the risk of getting it wrong every time.

So the first move is not learning to spot fakes — it is pinning down the genuine one while you are calm and nothing is urgent. Reach the official site by a route you trust, read the domain, and bookmark it. From the official site, follow its link to the app store listing and note the developer name. From the official site, find the support entry point and bookmark that too.

Do this once and the daily cost of verification drops to zero, because from then on you arrive by bookmark and never type the name into a search box again.

One maintenance note: re-verify after a long gap. Platforms occasionally change domains or move account functions, and a bookmark saved two years ago may now redirect somewhere you have never checked. Once a year, or after any redirect you did not expect, walk the checks again.

Reading a domain: right to left, last two segments

Only the top-level domain after the final dot, plus the segment immediately before it, determine who owns the address. Everything to the left is subdomain, and subdomains can be set to absolutely anything by whoever controls the domain.

A neutral example: in login.example.com, ownership rests with example.com and login is just a label. In example.com.attacker-site.net, ownership rests with attacker-site.net — the familiar-looking part at the front is entirely subdomain and has no connection to the real example.com.

Two more things to watch. Hyphenated variants that read naturally at a glance. And characters from other scripts that render nearly identically to Latin letters — which is exactly why a visual scan is not enough and why a bookmark beats reading every time.

The habit that matters

Click into the address bar so the full URL is shown rather than the shortened display version, then read from the right. Most people read left to right, see the brand name first, and stop. That reading order is precisely what the attack is built around.

Why reading it carefully is not enough

Domain reading works, but it has a known limit: some characters from other writing systems render almost identically to Latin letters. A domain built with one of those substituted in can be visually indistinguishable at normal text size, and no amount of care fixes that, because your eyes are being given correct information about the wrong thing.

Browsers have defences here — many will display a suspicious internationalised domain in its encoded form rather than its pretty form, precisely so the substitution becomes visible. But coverage differs between browsers and between top-level domains, so it is not something to rely on.

There are two related tricks that need no special characters at all. Hyphenated variants read naturally at a glance and are entirely legitimate domains that someone else owns. And plausible extra words — a brand name followed by something like "-login" or "-wallet" — look like infrastructure rather than deception.

What this actually implies

Visual inspection is a filter, not a proof. It catches clumsy fakes and it is worth doing, but the only method that is not defeated by clever rendering is arriving somewhere you already established as correct.

Which is why the bookmark is not a convenience here — it is the actual control. Everything else on this page exists for the situations where you do not have one yet.

The sponsored slot at the top of a results page can be bought, and it has been a primary impersonation channel for years. Visually it sits very close to the organic results underneath.

Two details make it worse than it sounds. First, people search for a platform precisely when they need it, which is often when something is already going wrong and patience is short. Second, searching for support contact details is a particularly exposed case — you are actively looking for someone to talk to, which is what makes it the most concentrated channel for the pattern described in how fake support finds you.

The durable fix is not learning to identify ads. It is removing the search step entirely by arriving from your own bookmark.

App stores: check the developer, not the icon

The app name, icon and screenshots are the easiest parts of a listing to copy. The developer name is the part that is bound to an account.

So the check is: open the listing, find the developer or provider field, tap through, and look at what else that developer publishes. A legitimate exchange's developer account publishes a small coherent set of things. An imitation developer account often publishes an unrelated assortment, or nothing else at all.

Ratings and review counts are not identity evidence — both can be manufactured, and a high rating on the wrong listing tells you nothing useful.

The hard rule: never install a trading app from outside an official app store. An installer offered on a web page, a file sent in a chat, a configuration profile, or wording like "the latest version has to be downloaded from our site" — that route bypasses the store's developer verification and is the main distribution channel for imitation apps.

Checking on a phone is harder, and worth knowing why

Most of the advice above was written for a desktop browser. On a phone, three of the checks get meaningfully weaker, and it is worth knowing which ones before you rely on them.

The address bar is truncated. Mobile browsers show a shortened form, often just the registrable domain, and sometimes hide it entirely once you scroll. That truncation is normally helpful, but it means the full URL is not in front of you unless you tap into the bar deliberately.

Certificate details are buried or unavailable. Some mobile browsers offer no practical way to inspect the certificate at all. The fifth check on our list is frequently just not available to you.

In-app browsers are the worst case. Opening a link from inside a messaging or social app usually loads it in that app's own browser view, which may show a minimal address bar or none, and provides none of the usual controls. You are being asked to trust a page while the tools for checking it have been removed, and links arriving in messaging apps are exactly the ones most worth checking.

What to do instead on a phone

  • Never act on a link inside an in-app browser. Use the share menu to open it in your real browser, or better, close it and go via your bookmark.
  • Prefer the official app over the mobile site for anything involving credentials. The app's identity was checked once at install time.
  • Keep the bookmark on your home screen. On mobile it does more work than on desktop, because the alternatives are weaker.

What the padlock actually proves

This is the single most common misreading

The padlock means the connection between you and that server is encrypted. It does not mean the company is real. Certificates that assert only control of a domain are freely available, and an imitation site gets one as easily as anyone else — same padlock, same appearance.

Put bluntly: if the other end is an impostor, encryption has only guaranteed that your password reached them without interference.

There is a narrower thing a certificate can help with: you can open the certificate details and confirm the name it was issued to matches the address bar. That is worth doing as a supporting check, and a browser warning about a certificate is always a stop signal. But it sits below domain reading in usefulness, not above it, which is why it comes last here rather than first.

If you want these steps as something you can tick off while looking at a page, the official source checklist turns them into five items with a saveable summary. It runs in your browser and sends nothing anywhere.

Compressed to one line: arrive from something you saved yourself, and search results stop mattering. Everything else here is a fallback for the occasions when you did not.

Common questions

Does the padlock icon mean a site is genuine?

No. The padlock means traffic between you and that server is encrypted. It says nothing about who operates the server. Impersonation sites obtain certificates as easily as anyone else and display the same padlock. Encryption guarantees your password arrives safely, including at the wrong destination.

How do I read a domain correctly?

Right to left, checking only the last two segments: the top-level domain after the final dot, and the segment immediately before it. Everything to the left of those is subdomain and can be set to anything, including a string that looks exactly like a brand you know.

Are search results safe to click?

The sponsored slot at the top can be purchased and has been a primary impersonation channel for years, while looking almost identical to organic results. The durable fix is not learning to spot ads — it is arriving from your own bookmark so the entry point is never in question.

What should I check on an app store listing?

The developer or provider name, not the app name or icon — those are the easiest parts to copy. Tap through to the developer and see what else they publish. Ratings and review counts are not identity evidence either.

Is it safe to install an app from a link someone sent me?

No. Installing from anywhere other than an official app store bypasses the store's developer verification, and that route is the main distribution channel for imitation trading apps. Wording like the latest version must be downloaded from our site is the standard pretext.