Explain what is meant by cookies and how they are used

Internet, the World‑Wide Web and the Web Browser

Internet vs. World‑Wide Web

• Internet: a global network of interconnected computers and devices that exchange data using standard protocols (TCP/IP, DNS, etc.).
• World‑Wide Web (WWW): a service that runs on the Internet. It uses the HTTP/HTTPS protocols to request and deliver web resources (HTML pages, images, scripts, …).

What is a URL?

A Uniform Resource Locator (URL) tells a browser where a resource is located and how to retrieve it.

HTTP vs. HTTPS

• HTTP – plain text protocol; data is sent unencrypted and can be read or altered by anyone on the network.
• HTTPS – HTTP layered on TLS/SSL; the connection is encrypted, providing confidentiality and integrity. Essential when cookies contain session identifiers or personal data.

Role of a Web Browser in Locating, Retrieving and Displaying a Page

1. User enters a URL.
2. Browser asks a DNS server to translate the domain name into an IP address.
3. Browser opens a TCP connection to the IP address (port 80 for HTTP, 443 for HTTPS).
4. Browser sends an HTTP (or HTTPS) request to the web server. If a cookie has previously been set for this domain/path, the request includes a Cookie header.
5. Server replies with a status line, response headers (including optional Set‑Cookie header) and the requested resource (HTML, CSS, JavaScript, images, …).
6. Browser stores any cookies received, then parses the HTML, applies CSS, executes JavaScript and finally renders the page for the user.

Request‑Response Flow with Cookies

User enters URL
   ↓ DNS lookup → IP address
   ↓ TCP (or TLS) connection
   ↓ HTTP/HTTPS request
      (Cookie header sent if a matching cookie exists)
   ↓ Server processes request
   ↓ Server response
      (Set‑Cookie header may be included)
   ↓ Browser stores/updates cookie
   ↓ Browser renders the page
    

Cookies – What They Are and How They Are Used

Definition

A cookie is a small (max ≈ 4 KB) piece of text that a web server asks a browser to store on the user’s device. On later requests to the same domain (and matching path), the browser automatically includes the cookie in the Cookie header, allowing the server to recognise the user and remember information about previous interactions.

Types of Cookies

• Session cookie: lives only while the browser (or the tab) is open. It is deleted automatically when the browser is closed. Typical use – temporary login session identifiers.
• Persistent cookie: stored with an explicit expiry date or Max‑Age. Survives browser restarts and is used for “remember‑me”, language preferences, or long‑term tracking.

Cookie Attributes

How Cookies Work – Example Exchanges

1. Session cookie (login)

HTTP response from server:
Set-Cookie: sessionId=7f9c3e2a; Path=/; Secure; HttpOnly; SameSite=Strict

Browser stores the cookie. On every subsequent request to example.com it sends:

Cookie: sessionId=7f9c3e2a

The server looks up sessionId in its database and knows which user is logged in.

2. Persistent “remember‑me” cookie

Set-Cookie: rememberMe=JohnDoe; Expires=Wed, 20 Dec 2026 12:00:00 GMT; Path=/; Secure; HttpOnly; SameSite=Lax

This cookie remains until the stated date, allowing the site to pre‑fill the login form or auto‑sign‑in on future visits.

Why Cookies Are Used (Advantages)

• Session management – keep users authenticated as they move between pages.
• Personalisation – remember language, theme, layout, or other preferences.
• Shopping carts – retain items added before checkout.
• Analytics & tracking – collect data on navigation patterns to improve site design.

Disadvantages and Security / Privacy Concerns

• Privacy – persistent cookies can be used to track a user across many sites.
• Session hijacking – if a cookie is intercepted on an unencrypted connection, an attacker can impersonate the user.
• Cross‑site scripting (XSS) – scripts that can read cookies without the HttpOnly flag may steal session identifiers.
• Cross‑site request forgery (CSRF) – browsers automatically send cookies with cross‑site requests, which can be abused unless SameSite is set appropriately.
• Storage limits – browsers typically allow about 20 cookies per domain, each up to 4 KB.

Best‑Practice Mitigations (Secure Cookie Use)

1. Use the Secure flag – ensures the cookie is only sent over HTTPS, protecting it from network eavesdropping.
2. Set HttpOnly – prevents JavaScript from accessing the cookie, reducing XSS risk.
3. Choose an appropriate SameSite value:
   • Strict – cookie sent only for same‑site navigation (strongest CSRF protection).
   • Lax – safe for most navigation while still blocking many CSRF attacks.
   • None – cookie sent with all requests; must be paired with Secure.
4. Store only a unique identifier in the cookie; keep personal data on the server side.
5. Use session cookies for short‑lived data and give persistent cookies a reasonable expiry date.
6. Provide clear information and obtain consent where required (e.g., GDPR cookie banner).

Linking Cookies to the Browser’s Role (Cambridge Syllabus Alignment)

The browser is responsible for:

• Saving cookies received via the Set‑Cookie header.
• Including matching cookies in the Cookie header of every subsequent HTTP/HTTPS request.
• Deleting session cookies automatically when the browser is closed.

This behaviour is an integral part of the “locate, retrieve and display” cycle described earlier, because the server’s response can depend on the cookie values sent with the request.

Suggested Diagram – Cookie Exchange Within the Page‑Load Cycle

User → enters URL
   ↓ DNS lookup → IP address
   ↓ TCP / TLS handshake
   ↓ HTTP/HTTPS request
      (Cookie header if a matching cookie exists)
   ↓ Server processes request
   ↓ HTTP/HTTPS response
      (Set‑Cookie header may be present)
   ↓ Browser stores/updates cookie
   ↓ Browser renders HTML, CSS, JS