What actually happens when you open a website (and where security fits in)
Day 1 of our web security series: the journey from typing a URL to seeing a page, and the security checkpoints along the way.
You type cybersearch.in into your browser, press Enter, and a page appears in under a second. It feels instant, but a lot happens in that second. Every step is also a place where things can go right or wrong for your security.
This is Day 1 of Web Security, From the Ground Up, a daily series that starts with the basics and builds up to how real websites protect themselves. You don’t need any background. If you run a website, build one, or just want to understand what your browser is doing, start here.
Step 1: Finding the address (DNS)
Computers don’t find each other by names like cybersearch.in. They use numbers called IP addresses. So the first thing your browser does is ask, “What’s the number for this name?”
That question goes to the Domain Name System (DNS), which works like the internet’s phone book. Your device asks a DNS resolver, usually run by your internet provider or a service like Cloudflare or Google. The resolver finds the answer and sends back an IP address.
Why it matters for security: if someone tampers with that answer, your browser can be sent to the wrong server while the address bar still shows the right name. This is one reason the next steps, especially HTTPS, matter so much. We’ll cover DNS risks properly on Day 5.
Step 2: Opening a connection
With the IP address in hand, your browser opens a connection to the server, much like dialling a phone number and waiting for someone to pick up. On the modern web this connection is almost always wrapped in TLS, the technology behind HTTPS and the padlock icon.
During this “handshake” the server proves its identity with a certificate, a digital ID card issued by a trusted authority. Your browser checks three things:
- Is the certificate issued for this exact domain?
- Is it still valid and not expired?
- Was it signed by an authority the browser trusts?
If any check fails, you get the full-page “Your connection is not private” warning. That warning is your browser doing its job. Don’t click through it on a site where you log in or pay.
Step 3: Asking for the page (HTTP)
Once the secure connection is up, your browser sends a request. It’s a short, structured message that says, roughly: “Please give me the home page. I’m a Chrome browser, I understand these languages, and here are the cookies you gave me last time.”
The server replies with a response: a status code (200 means “here you go”, 404 means “not found”), some headers with instructions for the browser, and the page content itself.
The headers are where much of the website’s security lives. A well-configured server uses them to tell the browser things like:
- “Only ever talk to me over HTTPS.” (HSTS)
- “Only run scripts that come from these places.” (Content Security Policy)
- “Don’t let other sites put me inside a frame.” (frame protection)
You can’t see these as a visitor, but they quietly stop whole categories of attacks. We’ll go through them one by one later in the series.
Step 4: Building the page
The response usually contains HTML, the page’s structure. As your browser reads it, it finds references to more files: stylesheets, images, fonts, JavaScript. Each one is another request, sometimes to the same server and sometimes to others such as analytics services or CDNs.
A modern page can easily pull in 50 to 100 files. Every outside source is someone the website is trusting to run code or show content to its visitors. This is why careful sites limit what they load, and why “keep your dependencies updated” appears in every security checklist.
Step 5: Remembering you (cookies)
If you log in, the server gives your browser a cookie, a small token your browser sends back with every later request. It works like a wristband at an event: show it and you don’t need to buy a ticket again.
That also means whoever holds the wristband is “you” as far as the site is concerned. Protecting cookies is one of the most important jobs in web security. Sites do it with settings such as Secure (HTTPS only), HttpOnly (scripts can’t read it) and SameSite (don’t send it on requests started by other sites). Day 3 covers this in detail.
The whole trip, in one picture
| Step | What happens | The main security protection |
|---|---|---|
| 1. DNS | Name becomes an IP address | HTTPS checks catch wrong servers |
| 2. Connection | TLS handshake, certificate check | Certificates and the padlock |
| 3. Request/response | Browser asks, server answers | Security headers |
| 4. Building the page | Extra files loaded | Content Security Policy, updated libraries |
| 5. Sessions | Cookies keep you logged in | Secure cookie settings |
What you can do today
If you browse the web:
- Treat browser certificate warnings as a real stop sign on any site you log in to.
- Keep your browser updated. Most security fixes arrive silently through updates.
- Log out of important accounts on shared computers. That throws away the “wristband”.
If you run a website:
- Make sure every page loads over HTTPS and plain HTTP redirects to it.
- Check your site’s security headers with a free scanner such as securityheaders.com.
- Make a list of every third-party script your pages load, and remove the ones you don’t need.
Coming up next
Tomorrow, on Day 2, we’ll look closely at HTTP itself: what a request and response actually look like, what status codes mean, and how to watch this traffic yourself using your browser’s built-in developer tools.