“Safe” is a word that means two different things here, and confusing them is the most common mistake on the web.
Is the connection protected? That concerns the transit: nobody can read or alter what you exchange.
Is the site what it says it is? That concerns identity: you are really talking to who you think.
The first is settled by the padlock. The second is not — and the second is the one that counts more.
It puts into practice the recommendation browsing only over HTTPS.
The procedure, in the right order
Five seconds, three steps. The order matters because the first is the most decisive.
Step 1 — Read the domain name
It is the most important check, and it comes first.
The domain is the part sitting immediately before the first slash, and it is read from right to left, starting from the last part before that slash.
| Address | The real domain | Verdict |
|---|---|---|
https://www.bank.com/login | bank.com | Correct |
https://bank.com.secure-access.net/ | secure-access.net | Not the bank |
https://www.bank-com.net/ | bank-com.net | A different domain |
https://access.bank.com/login | bank.com | Correct: a legitimate subdomain |
The second row is by far the most widespread deception: bank.com appears in the address, but as part of another domain’s name. The practical rule: look at the two words immediately before the first slash.
Step 2 — Check the connection is encrypted
Look for https:// at the start, or the padlock symbol. If it is missing — or if the browser writes “Not secure” — enter nothing.
A detail worth knowing: many browsers today hide https:// because it is the norm, and instead show an explicit indication when it is missing. The absence of a warning is therefore the good case; it is the presence of a warning you have to notice.
Step 3 — Look at the context
Before typing anything sensitive, two quick questions: how did I get here? and what is it asking me for?
A site reached from a link in a message deserves more attention than one reached from your bookmarks. An unexpected request for credentials deserves more attention than a sign-in you started yourself.
What the padlock actually says
It is worth being precise, because it is the web’s most widespread misunderstanding.
| The padlock guarantees | The padlock does NOT guarantee |
|---|---|
| That the traffic is encrypted | That the site is honest |
| That nobody can read it in transit | That the site handles your data well |
| That nobody can alter it | That the site is the one you think |
| That the certificate is valid for that domain | That that domain is the right one |
The last row is the key. The certificate says: “this connection really is with secure-access.net“. It does not say whether secure-access.net is your bank — that is what you have to know.
Obtaining a valid certificate is now free and automatic, and that is a good thing because it made the web encrypted by default. But it also means almost every fraudulent site has the padlock, and it is why step 1 comes before step 2.
What to do when a warning appears
The browser shows a warning when something in the verification does not add up. The causes vary and not all are serious — but none should be bypassed without understanding.
| Warning | What it means | What to do |
|---|---|---|
| Expired certificate | The operator did not renew it | Enter no data; often carelessness, not an attack |
| Name mismatch | The certificate belongs to another domain | Stop: it is the most serious signal |
| Issuer not recognised | The certificate cannot be verified | Stop, unless it is a known corporate network |
| Connection not private | A generic wording of the above | Read the detail before deciding |
| Mixed content | The page is encrypted but includes elements in the clear | Enter no sensitive data |
The mistake to avoid is always the same: looking for the button to proceed anyway. It exists for specific technical cases, not for ordinary browsing.
There is one situation where the warning is nearly always benign: the sign-in page of a public network, which intercepts the first connection and can produce a warning. Even there, though, the rule holds: no other service’s credentials get entered on that page.
The settings to turn on once
Three configurations that shift the work from your manual checking to the browser.
HTTPS-only mode. In the privacy and security settings of every major browser. It blocks connections in the clear and asks for confirmation before proceeding. It is the single most useful setting in this unit.
Show the full address. Some browsers shorten the address, hiding the protocol and sometimes the subdomain. If there is an option to see the address in full, turn it on: it makes step 1 more reliable.
Automatic browser updates. Certificate verification depends on a list of recognised authorities that gets updated with the program. An old browser verifies less well.
The simplest way of not having to do this at all
There is a strategy that removes the problem at the root for the services that really count, and it is worth more than any checking technique: never reach those sites by typing or clicking.
Bookmark the critical services. Bank, main email, payment services, password vault. Once the correct address is saved, every later visit starts from there and step 1 is already done.
Use the official apps where they exist. An app has no address bar because it does not need one: the destination is fixed at installation. It is why a bank’s app is safer than the bank’s site opened from a link.
Never follow links to financial services. No bank needs you to arrive from a message. If a communication requires an action, you find it by signing in normally.
Be careful with paid search results. Searching a bank’s name on a search engine can return ads at the top bought by anybody. A bookmark avoids that too.
With those four habits, checking the domain remains necessary only for new and occasional sites — where a mistake costs far less.
The particular cases worth knowing
Home configuration pages. Routers, printers, cameras, connected devices: their interfaces often use unencrypted connections. It is not a mistake to be corrected — it is a limitation of those devices. The rule is to use them only from the local network, never remotely.
Applications that do not use the browser. An app shows no address bar, so there is nothing you can check directly. Here the trust moves upstream: install only from official stores and keep the apps updated.
Corporate networks that inspect traffic. Some organisations install a certificate of their own on devices, allowing encrypted traffic to be analysed for security reasons. It is a legitimate and declared practice, but it is useful to know: on a company device, encryption towards the outside may not be opaque to the organisation.
The most frequent objections
“I look at the padlock, that is enough for me.” The padlock is step 2. Without step 1 it only confirms you are talking securely to somebody you have not verified.
“Addresses are too long to read.” You do not need to read them all: you need the two words before the first slash. It is a two-second operation, and it becomes automatic within days.
“My browser already blocks everything.” It blocks unencrypted connections, which is step 2. No browser can know that bank-com.net is not your bank.
“I only use the app, not the browser.” A good choice for critical services — it is the simplest way to avoid the wrong-address problem entirely.
“If I get it wrong I will notice from the design.” That is not reliable: copying a site’s appearance takes a few minutes, and the good copies are indistinguishable. A domain cannot be copied — it is unique by definition.
“If something happens the bank will refund me anyway.” Protections exist, but they vary and they are not automatic: many depend on how promptly you report and on how the transaction happened. That is one more reason to do the check, not a reason to skip it.
The exercise that makes step 1 automatic
Reading a domain looks trivial until you try it on an address built to confuse. It is worth practising once, calmly, rather than under pressure in front of an urgent message.
The method in three moves.
- Find the first single slash after
https://. Everything after it does not count for this check. - Look at the two words before that slash, separated by a dot. Those are the domain.
- Ask yourself whether those two words are the ones you expect.
Try it on these.
| Address | The two words before the slash | Is it the site? |
|---|---|---|
https://www.example.com/customers | example.com | Yes |
https://example.com.verify-account.net/login | verify-account.net | No |
https://customers.example.com/login | example.com | Yes |
https://www.example-com.net/ | example-com.net | No |
https://example.com@different-site.net/ | different-site.net | No |
The last row uses a less known trick: the @ symbol in an address means everything before it is ignored. It is rare but it exists, and the two-words-before-the-slash rule exposes it anyway.
Done two or three times, this check takes less than two seconds and becomes a reflex — which is exactly what is needed, because the moment it counts is the moment you are in a hurry.
How this connects to the Cyber Welfare Framework
| Pillar | What this content contributes |
|---|---|
| Skills | Reading a domain from the right and telling it from the rest of the address |
| Awareness | Knowing the padlock certifies the connection, not the honesty |
| Secure Behaviour | Stopping at a warning instead of looking for how to proceed |
Reference level: FL2 — Beginner. The step to FL3 comes when reading the domain reliably precedes reading the padlock.
Summary
- The domain first, the padlock second. The order is the part that counts.
- The domain is read in the two words before the first slash.
- Almost every fraudulent site has the padlock: it is free and automatic.
- HTTPS-only mode moves the check from your eye to the browser.
One thing to do today. Turn on “HTTPS-only” mode in your browser. Then, the next time you open your bank’s site, read the domain out loud: it is the exercise that makes step 1 automatic.
Related content
- Browsing only over HTTPS — the recommendation this guide comes from
- Signs of an unprotected connection — what the browser shows and what it means
- How HTTPS works — why the certificate guarantees the domain and not the honesty
- Traffic interception — what this procedure prevents
Related resources
Short reads from the Resources section, for anyone who wants to stop on a single aspect:
Start with the first step: the Cyber Welfare Programme guides you free of charge, one recommendation at a time.



