# Exercise 1: Diagnose a Cookie-Sharing and Cross-Tenant Bug

## Scenario

You work on `ShelfSpace`, a SaaS inventory platform. Two things happened this week:

1. **Support ticket #4471**: a customer says they log into `app.shelfspace.io` but their session doesn't carry over when they click through to `billing.shelfspace.io` — they have to log in again. Engineering set the session cookie with no `Domain` attribute at all:
   ```http
   Set-Cookie: session=xyz789; Path=/; Secure; HttpOnly; SameSite=Lax
   ```

2. **A near-miss caught in code review**: a teammate proposed fixing ticket #4471 by setting `Domain=herokuapp.com`, because `ShelfSpace`'s staging environments are all deployed as `<random-name>.herokuapp.com` subdomains and they wanted staging cookies to "just work" across every staging instance too. A senior engineer rejected the PR without much explanation beyond "that's a public suffix, don't."

3. **A third, unrelated observation**: `ShelfSpace`'s marketing site lives at `https://shelfspace.io` (no subdomain) and makes a `fetch()` call to `https://app.shelfspace.io/api/public-stats` to display a live customer counter. This works fine today with no CORS configuration on the API beyond `Access-Control-Allow-Origin: https://shelfspace.io`.

## Deliverables

Produce all of the following, in this file, below this line:

1. **Explain ticket #4471 precisely** — using the hostname/domain/eTLD+1 vocabulary from the theory file (section 1-4), state exactly why the session cookie set on `app.shelfspace.io` is not sent on requests to `billing.shelfspace.io`, and give the exact `Set-Cookie` header (with the correct attribute added) that fixes it.
2. **Explain why the senior engineer rejected `Domain=herokuapp.com`** — using the Public Suffix List / eTLD+1 concept from theory section 2 and 4, explain concretely what would go wrong if browsers allowed this, using a specific example of two unrelated parties both having `*.herokuapp.com` subdomains.
3. **Propose a real fix for the staging cookie-sharing goal** — given that `herokuapp.com` is a public suffix and can't be used, what would ShelfSpace actually need to do (e.g., in terms of what domain they'd need to deploy staging environments under) to legitimately share a cookie across all their staging instances? Be specific.
4. **Classify the marketing-site fetch as same-site, same-origin, both, or neither** — for the `shelfspace.io` -> `app.shelfspace.io` fetch call in point 3 of the scenario, state whether this is same-origin, same-site, both, or neither, using the precise definitions from theory section 5, and explain why the existing `Access-Control-Allow-Origin` header (a CORS mechanism) was necessary here even though the two hosts are same-site.

## Constraints

- Every claim must cite the specific theory section it's based on (e.g. "per theory §4...").
- Do not propose disabling `HttpOnly`, `Secure`, or `SameSite` as part of any fix — none of the three problems described require weakening those protections.
- Your answer to deliverable 3 must not suggest anything that would make ShelfSpace vulnerable to the same cross-tenant cookie leakage the senior engineer was rejecting in deliverable 2.