claude agent, operated by paul@keymail.devoperated by paul@keymail.devsession 1b69e34c · claude-code/2.1.288 · DOCS-T1
Found by the 2026-10-03 tenant-isolation audit. Checked against the live Public Suffix List that day.
oncarlos.com is not on the PSL, so every tenant (<app>.<sqid>.oncarlos.com) shares one registrable domain. That means:
A tenant can set Domain=oncarlos.com cookies that other tenants' apps receive (cookie tossing, session fixation).
Browsers treat requests between tenants as same-site, so SameSite cookies don't protect against CSRF from another tenant.
The platform's gate cookie is already safe: it is MAC-bound to host and hash, and gate.go:115-124 tries every cookie with that name.
The fix is a PSL entry, *.oncarlos.com in the private section, so each account's <sqid>.oncarlos.com becomes its own site. That needs a _psl TXT record on oncarlos.com and a pull request to github.com/publicsuffix/list. Both are outward-facing, so each needs operator approval under the production-infrastructure rule. Inclusion takes weeks and can't easily be undone. A side effect is that Let's Encrypt rate limits then count per account rather than for the whole domain. Platform names that live directly under oncarlos.com (for example woodstar-relay.bdm.oncarlos.com) are covered by the same wildcard.
Every self-hosted deployment has the same problem with its own apps domain; the docs should tell operators to do this.
claude agent, operated by paul@keymail.devoperated by paul@keymail.devsession 1b69e34c · claude-code/2.1.288 · DOCS-T1
Correction and a check (2026-10-04):
Which rule.*.oncarlos.com makes <sqid>.oncarlos.com the public suffix, so each app (<app>.<sqid>.oncarlos.com) is its own site, not each account. That is the stricter choice, and the one I'd recommend: apps in one account are separate trust domains too. An account that wants cookies shared across its apps can use a custom domain. The alternative is the plain rule oncarlos.com, which makes each <sqid>.oncarlos.com one site and lets apps in an account share cookies.
Nothing in the platform relies on a shared cookie. No http.Cookie in the platform sets a Domain attribute (checked on main 78fc8d40), so a PSL entry does not break any platform cookie. Tenant apps that set Domain=oncarlos.com themselves would lose it, which is the point.
Status. Paul is in favour in principle. The DNS record and the PSL pull request are waiting on his explicit go-ahead.
claude agent, operated by paul@keymail.devoperated by paul@keymail.devsession 1b69e34c · claude-code/2.1.288 · DOCS-T1
Tracked under #247 (tenant isolation before Carloku takes outside tenants).
claude agent, operated by paul@keymail.devoperated by paul@keymail.devsession 1b69e34c · claude-code/2.1.288 · DOCS-T1
Update, 2026-10-06. Pre-requisites done:
oncarlos.com renewed to 2029-08-01;
abuse@ and psl@carloku.com forward to the operator (carloku-infrastructure PR #5, applied, MX/SPF live);
the abuse contact is in carloku.com's footer (c0123a7, live).
The PSL pull request is drafted and lint-clean (*.oncarlos.com under "Carloku", between Canva and Carrd) but not submitted. The PSL template states that inclusion is considered only for projects with at least 2,000–3,000 distinct users, and asks for the count. Carloku has a few dozen accounts, so it would be closed. The draft is ready for when Carloku clears that bar; the renewal, forwards and footer stay.
Platform mitigation in the meantime (being built): the edge rewrites a tenant response's Set-Cookie whose Domain reaches beyond the app's own account namespace (Domain=oncarlos.com, or another account's <sqid>.oncarlos.com) into a host-only cookie. That closes cookie tossing between accounts. Same-site CSRF between accounts stays open until the PSL entry lands.
amadan