Lecture: Understanding Cookies in Web Development

Motivation: Why Cookies Matter

Hey everyone, welcome to today’s lecture! Today, we’re exploring cookies—those small pieces of data you’ve likely seen pop up in “accept cookies” banners. Cookies are key to how websites work, from keeping you logged in to remembering your preferences. In this course, we’re working toward authentication (logging in) and authorization (what you’re allowed to do), and cookies are a foundational step for that.

Picture this: You’re using a Blog application. You log in to read posts, or maybe you’re an admin editing them. How does the site remember you as you navigate? Without cookies, every page load would be a fresh start—pretty annoying, right? Cookies fix that by storing info on your device, acting like a memory tag for the site.

Ever wonder why you stay logged in after closing your browser? Or why a site “knows” you when you return? That’s cookies! But here’s a misconception: Some think cookies are just for tracking or ads. Not quite—they’re tools, and their use depends on the developer. Let’s dive in with our Blog application example and build it up step-by-step.

Section 1: What Are Cookies, Really?

A cookie is a tiny text file a website saves on your device through your browser. It’s like a note the site leaves itself, with a name, a value, and optional settings—like how long it lasts or who can access it.

Here’s a misconception to shake up: People often think cookies hold big personal details, like your email or password. Nope! They usually store simple stuff, like an ID. In our Blog application, when you visit as a guest, it might set:

• Name: visitor_id
• Value: guest456
• Purpose: Marks you as a guest browsing public posts.

That’s super basic—no login yet. We’ll expand this as we go!

Section 2: Setting Cookies with Next.js

Cookies are a collaboration between the browser (client) and server. Here’s the flow:

1. Server Sets a Cookie: Sends it via the Set-Cookie header.
2. Browser Stores It: Saves it locally.
3. Browser Sends It Back: Includes it in every request to the site.
4. Server Reads It: Uses it to recognize you.

In Next.js, we can use the cookies utility from next/headers to set and read cookies. Let’s set a cookie server-side for a guest in our Blog application:

// app/api/set-guest/route.js
import { cookies } from 'next/headers';

export async function GET() {
  cookies().set('visitor_id', 'guest456', {
    path: '/', // Available site-wide
    maxAge: 60 * 60, // 1 hour
  });
  return new Response(JSON.stringify({ message: 'Welcome, guest!' }), {
    status: 200,
    headers: { 'Content-Type': 'application/json' },
  });
}

When you hit this route, the server sets Set-Cookie: visitor_id=guest456; Max-Age=3600; Path=/. Your browser stores it, and every request after sends Cookie: visitor_id=guest456.

Now, on the client side, let’s set a cookie for user preferences (e.g., filtering posts by tag). In a React component:

'use client';
// app/components/SetPrefs.js
import { useEffect } from 'react';

export default function SetPrefs() {
  useEffect(() => {
    document.cookie = 'prefs=tag:tech; path=/; max-age=86400'; // 1 day
  }, []);

  return <p>Preferences set to tech posts!</p>;
}

The browser now has prefs=tag:tech alongside visitor_id. We’ll handle reading them next.

Section 3: Cookie Security and HttpOnly

Cookies need protection—otherwise, they’re vulnerable. A big player here is HttpOnly, which blocks JavaScript from accessing the cookie (e.g., document.cookie can’t see it). This guards against XSS (Cross-Site Scripting) attacks, where hackers try to steal cookies.

Let’s secure an admin login cookie in Next.js:

// app/api/login/route.js
import { cookies } from 'next/headers';

export async function POST() {
  // Imagine we verified username/password
  const sessionId = 'abc789xyz';
  cookies().set('session_id', sessionId, {
    path: '/',
    maxAge: 60 * 60, // 1 hour
    httpOnly: true, // No JS access
    secure: process.env.NODE_ENV === 'production', // HTTPS in prod
    sameSite: 'strict', // Blocks CSRF
  });
  return new Response(JSON.stringify({ message: 'Logged in!' }), {
    status: 200,
    headers: { 'Content-Type': 'application/json' },
  });
}

Security Features:

• HttpOnly: Keeps session_id safe from client-side scripts.
• Secure: Ensures HTTPS-only transmission (skip in dev, enforce in prod).
• SameSite=Strict: Prevents cross-site request forgery (CSRF).

General Security:

• Don’t store sensitive data (e.g., passwords)—use random IDs linked to server data.
• Set expiration to limit exposure if stolen.
• Always use HTTPS to encrypt traffic—unencrypted cookies are easy targets.

Section 4: Handling Cookies Client- and Server-Side

Let’s use cookies in our Blog application. First, server-side, verify an admin session:

// app/api/check-session/route.js
import { cookies } from 'next/headers';

export async function GET() {
  const cookieStore = cookies();
  const sessionId = cookieStore.get('session_id')?.value;
  if (sessionId === 'abc789xyz') { // Check against a DB in real apps
    return new Response(JSON.stringify({ message: 'Admin access granted' }), {
      status: 200,
      headers: { 'Content-Type': 'application/json' },
    });
  }
  return new Response(JSON.stringify({ message: 'Unauthorized' }), {
    status: 401,
    headers: { 'Content-Type': 'application/json' },
  });
}

Now, client-side, read and display the prefs cookie:

'use client';
// app/components/DisplayPrefs.js
import { useState, useEffect } from 'react';

export default function DisplayPrefs() {
  const [prefs, setPrefs] = useState('');

  useEffect(() => {
    const getCookie = (name) => {
      const value = `; ${document.cookie}`;
      const parts = value.split(`; ${name}=`);
      if (parts.length === 2) return parts.pop().split(';').shift();
    };
    setPrefs(getCookie('prefs') || 'No preferences set');
  }, []);

  return <p>Your post filter: {prefs}</p>;
}

In action:

1. Admin logs in → session_id=abc789xyz (HttpOnly, server-only).
2. User sets prefs=tag:tech → Client reads it to filter posts.

Advantages: Easy to manage state, secure with proper flags. Disadvantages: Small size limit (4KB), can be cleared, needs security care.

Conclusion: Key Takeaways

Let’s wrap up! Cookies power our Blog application—tracking guests, securing admins, and personalizing views. We set visitor_id server-side, secured session_id with HttpOnly, and handled prefs client-side.

Key Points:

• Cookies are name-value pairs shuttled between client and server.
• Use next/headers in Next.js or document.cookie on the client.
• Secure them with HttpOnly, Secure, and SameSite.

Pitfalls to Avoid:

• Don’t skip security—HttpOnly is critical for sessions.
• Avoid overloading cookies—keep data small and server-linked.

Next time, we’ll build on this for authentication and authorization. Questions? Let’s talk!