If you’re getting into backend or API development, cookies can seem like small, mysterious pieces of data floating around in your browser. But once you understand their purpose and behavior, they reveal themselves as one of the simplest and most effective mechanisms for managing state and user sessions on the web.

In this blog, we’ll break down cookies in a clear and practical way—how browsers store and send them, how developers configure them, what each security flag means, and how to implement them correctly in a Go (Golang) API. This will give you both the conceptual understanding and the hands-on skills needed to work with cookies confidently in real-world applications.

---

What Exactly Is a Cookie? (Casual Explanation)

A cookie is basically a small piece of text your browser stores for a website.

Think of it like:

“A note your browser saves, and automatically hands back to the server every time you visit.”

A cookie is always a name–value pair, for example:

username=krish
theme=dark
session_id=abc123xyz

That’s it.
Simple, tiny text — but extremely powerful.

---

The Anatomy of a Cookie

A cookie is not restricts to name and value, It has attributes that define how long it lives, where it can be sent, and how secure it is.

Here’s a real cookie header:

Set-Cookie: sessionId=xyz123;
            Path=/;
            Domain=example.com;
            Max-Age=3600;
            Secure;
            HttpOnly;
            SameSite=Lax

Now, what are these ?..

🍪 Cookie Components Explained

✔ 1. Name–Value Pair

The actual data.

Example:

Set-Cookie: theme=dark

✔ 2. Expiration / Max-Age

Controls how long the browser keeps the cookie.

• Max-Age → lifetime in seconds (preferred)

• Expires → exact date

Example:

Max-Age=3600  // lasts for 1 hour

If you don’t specify expiration → session cookie (deleted when browser closes).

✔ 3. Path

Controls which URL paths can access the cookie.

Path=/           → cookie sent everywhere
Path=/api/auth   → only for specific subpaths

✔ 4. Domain

Controls which subdomains can receive the cookie.

Domain=example.com       → available to all subdomains
Domain=api.example.com   → restricted to only api subdomain

✔ 5. Secure

Tells browser:

“Only send this cookie over HTTPS.”

Secure

This protects your cookie from being stolen on insecure networks.

✔ 6. HttpOnly

Tells browser:

“JavaScript CANNOT read this cookie.”

So scripts cannot do:

document.cookie

This protects against XSS attacks.

HttpOnly

✔ 7. SameSite Policy

Controls whether cookies can be sent during cross-site requests.

This protects against CSRF.

SameSite has three modes:

🔵 SameSite=Lax (default)

Cookies are sent:

• On normal navigation

• On GET requests

• But NOT on cross-site POST/PUT/DELETE

Example:

SameSite=Lax

Use case:

• Login redirects

• Most websites

🟢 SameSite=Strict (strongest protection)

Cookies are never sent in cross-site requests.

Example:

SameSite=Strict

Good for:

• Banking

• Highly sensitive dashboards

Bad for:

• OAuth

• Payment gateways

• External SSO

🔴 SameSite=None (requires Secure)

Allows cross-site cookies, but requires:

SameSite=None; Secure

Use case:

• Payment gateways

• OAuth flows

• Embedded widgets

• Third-party APIs

Third-Party Cookies Explained (The Controversial Ones)

A third-party cookie is a cookie set by a website inside another website.

Example:
You visit news.com, which loads an ad.com iframe → ad.com sets a cookie.

Browsers now restrict these heavily:

✔ Chrome → CHIPS (Partitioned Cookies)

Third-party cookies must use:

SameSite=None; Secure; Partitioned

✔ Safari → ITP (Intelligent Tracking Prevention)

Third-party cookies expire after ~7 days.

✔ Firefox → First-Party Isolation (also tor sharing the same)

Every site has isolated cookie storage.

This is why most trackers stopped working post-2021.

What is a Partitioned Cookie?

Simply,

A partitioned cookie is a special type of third-party cookie that Chrome introduced to protect privacy. Normally, a third-party cookie (like one set by an iframe or embedded widget) can track you across different websites.
Partitioned cookies fix this by isolating the cookie per top-level site.

Meaning:

• If widget.com is loaded inside news.com, it gets its own cookie.

• If the same widget.com is loaded inside blog.com, it gets a different cookie.

• The two cookies cannot see each other.

So third-party features like payment frames, chat widgets, login boxes, etc., still work — but tracking users across websites becomes impossible.

To create one, the cookie must include:

SameSite=None; Secure; Partitioned

That’s it — a partitioned cookie is just a privacy-safe third-party cookie that is isolated per website so it cannot be used for cross-site tracking.

As a Developer: How You Should Set Cookies in Go (Golang)

Go makes cookie handling very clean.

You use the built-in http.Cookie struct.

✔ Setting a Cookie (simple)

http.SetCookie(w, &http.Cookie{
    Name:  "username",
    Value: "krish",
})

✔ Setting a Secure session cookie (recommended)

http.SetCookie(w, &http.Cookie{
    Name:     "sessionId",
    Value:    "abc123xyz",
    Path:     "/",
    HttpOnly: true,
    Secure:   true,
    SameSite: http.SameSiteLaxMode,
    MaxAge:   3600, // 1 hour
})

This is safe for almost all applications.

✔ Setting a cookie with SameSite=None (for cross-site use)

http.SetCookie(w, &http.Cookie{
    Name:     "token",
    Value:    "123",
    Path:     "/",
    Secure:   true,
    HttpOnly: true,
    SameSite: http.SameSiteNoneMode,
})

✔ Creating a Partitioned Cookie (Chrome’s CHIPS)

Go doesn’t yet expose the Partitioned attribute,
so you add it manually:

cookie := &http.Cookie{
    Name:     "chip_session",
    Value:    "xyz456",
    Path:     "/",
    Secure:   true,
    HttpOnly: true,
    SameSite: http.SameSiteNoneMode,
}

w.Header().Add("Set-Cookie", cookie.String()+"; Partitioned")

Reading a Cookie in Go

cookie, err := r.Cookie("sessionId")
if err != nil {
    fmt.Println("cookie missing")
}
fmt.Println(cookie.Value)

Deleting a Cookie in Go

You “delete” by setting a negative MaxAge:

http.SetCookie(w, &http.Cookie{
    Name:   "sessionId",
    Value:  "",
    Path:   "/",
    MaxAge: -1,
})

Browser-Specific Rules Developers Must Know

✔ Chrome

• Third-party cookies require Partitioned

• Blocking all third-party cookies by default

✔ Safari

• Aggressive expiration

• Third-party cookies die fast

✔ Firefox

• First-Party Isolation

• Each site has its own cookie silo

✔ Brave

• Blocks third-party cookies completely

This means your backend needs proper SameSite rules,
especially if you use OAuth, Stripe, Razorpay, Google Login, etc.

Final Thoughts: Cookies Look Complicated — They’re Just Misunderstood

Cookies are:

• Small text

• Sent automatically

• Controlled by attributes

• Powerful for authentication

• Dangerous if misconfigured

As a backend developer, you MUST always set:

HttpOnly; Secure; SameSite=Lax

And for cross-site API integrations:

SameSite=None; Secure

And for modern Chrome compatibility:

Partitioned (for third-party cookies)

Once you understand these rules, cookies become one of the most reliable, secure ways to manage user sessions.