One SPA to rule the homepage and the dashboard feels efficient until XSS on a blog comment form sits on the same origin as the session cookie for billing.
Trust boundaries exist for a reason. Public content and authenticated product surfaces should differ in host, cookie scope, CSP, and deploy cadence.
Lobby and vault. Different rules.
Practical split
| Concern | Marketing | App |
|---|---|---|
| Host | www |
app |
| Cookies | minimal | strict; careful partitioning |
| Auth | none or light | full session |
| CSP | tighter on inline | may allow app needs |
| Deploy | content velocity | change control |
Shared design system: yes. Shared origin with powerful cookies: think hard.
SSO and handoff
Deep links from marketing to app should land on login with return URL validation against an allowlist. Open redirects are a classic own-goal.
Cookies and XSS blast radius
If a marketing CMS compromise can read the app session cookie, you have coupled two risk domains. Prefer host separation and cookie attributes (Secure, HttpOnly, appropriate SameSite, tight Domain).
Closing
Efficiency is not one origin for everything. Efficiency is clear boundaries that keep incidents small.
Need an auth boundary review for web + app? Start a project inquiry.
CSP and third parties
Marketing loves tags; apps love stricter CSP. Separate hosts make that tension manageable. On a shared host, every new tag is a security review of the entire product.
Session fixation and logout
Logout must clear app cookies completely. Marketing site should not resurrect app session state via shared parent domain cookies.
Threat model sketch
Assume CMS compromise, XSS on blog, malicious third-party tag. Ask what each can reach. That exercise usually justifies the split by itself.
Shared components, separate deploys
You can share a button library via packages while still deploying marketing and app on different schedules and hosts. Shared code is not the same as shared runtime trust.
Incident example
Marketing CMS plugin vulnerability → XSS → session cookie readable → account takeover. The postmortem that says “we needed a better plugin” misses the architectural miss: session cookies should not have been reachable from the CMS origin.
Cookie attribute checklist for app sessions
SecureHttpOnlySameSiteappropriate to your cross-site needs- Narrow
Domain(avoid parent domain unless required) - Short lived access tokens + rotating refresh where applicable
Marketing pages should not need the app session cookie at all.
Content Security Policy
Start strict on marketing: default-deny, allowlist scripts. Apps may need looser policies for richer UI — another reason not to share one policy document for both hosts.