[SECURITY][MEDIUM] SAT bearer token cookie scoped to overly broad .osaas.io domain — cross-tenant token exposure

[LucasMaupin]

Summary

When running on the OSC platform, src/lib/sat.ts sets the Open Live Service Access Token (SAT) as a browser cookie with domain=.osaas.io. This domain scoping means every application on every *.osaas.io subdomain can read this cookie — including other tenant applications that share the platform. A malicious or compromised co-tenant application at attacker.osaas.io can access the Open Live SAT.

Combined with the existing non-HttpOnly status (the cookie is readable by JavaScript), any XSS vulnerability in any *.osaas.io application, or in Open Live Studio itself, can exfiltrate this token. A SAT grants full authenticated access to the Open Live API, including the ability to activate/deactivate productions, modify sources, and change PiP layouts — a significant operational risk for a live broadcast environment.

This is distinct from the previously filed and closed issue #22, which addressed missing JWT error handling and the HttpOnly flag directly. This issue is specifically about the overly broad cookie domain (.osaas.io vs the specific subdomain).

CVSS Score

6.1 (Medium) — CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N

Category

OWASP A02 — Cryptographic Failures / Sensitive Cookie Exposure

Affected File(s)

• src/lib/sat.ts:15 — const OSC_COOKIE_DOMAIN = '.osaas.io'
• src/lib/sat.ts:104-111 — document.cookie assignment using OSC_COOKIE_DOMAIN

Steps to Reproduce

1. Deploy Open Live Studio on OSC (e.g., at open-live-studio.tenant.osaas.io).
2. Authenticate — the SAT cookie is set with domain=.osaas.io.
3. From any other OSC tenant application on *.osaas.io (or via XSS anywhere on that domain), read document.cookie — the eyevinn-open-live.sat value is accessible.
4. Use the exfiltrated SAT to call the Open Live REST API directly.

Remediation

1. Remove the explicit domain attribute from the cookie to scope it to the current specific subdomain (browser default):

   // Before:
   `domain=${OSC_COOKIE_DOMAIN}`
   // After: omit the domain attribute entirely — browsers default to the current document's hostname

2. Preferred architectural fix: Have the OSC reverse proxy issue the SAT via a server-side Set-Cookie response header with HttpOnly; Secure; SameSite=Strict and the exact subdomain scope. This eliminates both the broad domain scope and the JavaScript readability.
3. Defence-in-depth: Validate the Origin header on all API requests server-side to reject cross-subdomain requests even if the cookie is presented.

References

• MDN Cookie domain attribute
• OWASP Session Management Cheat Sheet
• CWE-1004: Sensitive Cookie Without HttpOnly Flag
• Related closed issue: [SECURITY][MEDIUM] SAT JWT decoded without error handling; session cookie missing HttpOnly flag #22 (SAT JWT decoded without error handling; cookie missing HttpOnly)

---

Found by automated security audit on 2026-06-22

[LucasMaupin]

The SAT cookie is scoped to .osaas.io rather than the specific subdomain, which means any co-tenant app on the platform could read it. The fix involves an architectural call about where cookie scoping should live (client-side vs. a server-side Set-Cookie from the reverse proxy). Labelled bug and ready-for-dev. Security-engineer will take a look.

[LucasMaupin]

PR opened to address this: #36

The fix removes the explicit domain=.osaas.io attribute from the SAT cookie in src/lib/sat.ts. Without an explicit domain, the browser scopes the cookie to the current exact hostname (e.g. open-live-studio.tenant.osaas.io), so other co-tenant applications on *.osaas.io can no longer read it. isOnOsc() is unchanged.