The address bar comes before the buy button.

Check the actual destination

In our made-up case, Harbor’s verified domain is harbor.example, and its documented login is login.harbor.example. Names ending in .example are reserved for teaching. There is no service to visit here.

Take the address https://login.harbor.example/account apart. The https part describes an encrypted connection. The hostname, login.harbor.example, identifies the destination. The /account part is a path within that destination.

Now look at https://harbor.example.help.example/account. The hostname belongs under help.example in this case. Adding the familiar words harbor.example on the left has not made it Harbor’s documented login.

In https://help.example/harbor.example, the destination is help.example. The familiar name appears after the slash, in the path. It is like writing a shop’s name on a door inside a different building.

Compare the whole hostname with the supplied route. A copied logo, familiar word, or encrypted connection is not enough. Even the correct domain does not prove that the service or your device has never been compromised.

For a real service, establish its genuine route independently first. Then check the full address before entering information. Domain endings can have several parts, so “read only the last two words” is not a universal rule. If the route remains unclear, stop before using it.

Protect signing in and recovering access

Where a password is required, make it long and unique to that account. A password manager can help create and store it. Protect the email account that can reset the password too; it is another way into the financial account.

Add a second kind of sign-in check. This is multifactor authentication, or MFA. When supported, phishing-resistant passkeys or security keys offer stronger protection against fake sign-in pages.

A passkey lets your device or password manager prove control of a sign-in credential without you typing a reusable password. A security key is a physical device used for a sign-in check. These methods check the real site involved, rather than simply asking you to type a code into whichever page is open.

An authenticator app generates changing codes without relying on your phone number. But a fake page can still trick you into typing a valid code. SMS texts have another risk: an attacker may take over your phone number, sometimes called SIM swapping.

Prefer stronger methods when available. If SMS is the only extra factor offered, it is generally better than a password alone. Also check how the account is recovered when a device or sign-in method is lost.

Keep backup codes and a supported spare recovery method protected. Check that a replacement works before removing the old method. Some services also offer withdrawal allowlists or waiting periods, which limit destinations or delay changes. They are extra controls, not replacements for protecting login and recovery.

A separate email address may reduce unwanted exposure. It still needs strong protection. An attacker who cannot pass the normal login may try the reset process instead.

Read the order itself before confirming

Reaching the correct service is the first check. Next read the exact asset, amount, quoted price, fee, and order type. The right website can still carry out an order you did not mean to place.

A market order tries to trade at available prices. A large sale may reach lower buy offers, as in the earlier example. The first price on screen is not a promise for the whole amount.

A limit order sets a price boundary. That can protect the limit you specified, but the order may never fill. Neither order type decides whether the asset fits your finances or reasons for investing.

A purchase schedule is another decision tool. It reduces how often you choose a buying time, but it cannot guarantee a profit or make an unsuitable asset suitable.

Match every part of the transfer

Suppose a service accepts a token on Network A. Your wallet shows the same token symbol on Network B. That does not mean the service can credit a deposit on Network B, even if the address looks the same.

Get the instructions from the intended recipient through a verified route. Match the exact asset, supported network, and full address. Some services also require a memo or destination tag, an extra label that identifies which customer should receive the deposit.

Compare those details with the action you are approving. Use the trusted display on a hardware signer where available. Check the amount, fee, and minimum deposit too; a missing memo or too-small deposit can create a separate problem.

A small test that respects those costs and minimums can limit the amount at risk from a mistake. Confirm that the intended account actually received it. Then recheck the larger transfer from the beginning, because its address, network, or other details may have changed.