fix(auth): P0 tenant-isolering för internal-token (verifierad tenant) #494
sax3l
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: admin/0pt#494
Reference in New Issue
Block a user
P0 — tenant-isolering för internal-token-anrop
Fynd (2026-11-07):
POST /api/0pt/canonical/factsmedX-Internal-Tokenochtenant_id=999999999999999999gav HTTP 201 och skrev data i en annan tenant.Orsak:
middleware.tsinternal-token-grenen returneradenext()utan att sättax-0pt-verified-tenant.assertTenantMatchesVerifiedblev därför en no-op.Fix: sätter
x-0pt-verified-tenantfrånX-0pt-Internal-Tenant(ellerINTERNAL_TENANT_ID), och varnar när ingen tenant kan verifieras.Bevis: bogus-tenant-data (1 relation, 2 facts, 3 entities) städades bort och verifierades 0 kvar. Efter fix ska samma anrop nekas.
Åtgärd krävs: merge + deploy av 0pt-api. Ingen dataändring i övrigt.
The first revision of this fix copied a CLIENT header (X-0pt-Internal-Tenant) or a single INTERNAL_TENANT_ID into x-0pt-verified-tenant. That is not an authorization source: any holder of the shared internal token could still name any tenant, leaving the original cross-tenant write reachable through a different header. - INTERNAL_SERVICE_TENANTS (server env) is now the only tenant authority for the X-Internal-Token principal; empty => no authority (fail closed, 403). - Middleware strips inbound x-0pt-verified-{tenant,sub} and the service scope header on every path, including the dev escape hatch. - x-0pt-verified-service-tenants carries the allowlist; the tenant guard checks membership and denies anything outside it. - POST /api/0pt/quality/bridge-run now runs the same tenant guard as canonical/facts (it auto-provisions tenant-scoped rules). - 16 new regression tests; auth + cross-tenant + canonical + bridge suites 87/87; tsc --noEmit clean.Säkerhetsgranskning (P0) — 2026-11-07
Verdikt på första revisionen (
849e7ae): BLOCKERAD. Klientheadern var behörighetskälla.Vad som var fel
req.headers.get('x-0pt-internal-tenant') ?? process.env.INTERNAL_TENANT_IDkopierades rakt in ix-0pt-verified-tenant. Vem som helst med den deladeX-Internal-Tokenkunde därmed välja tenant i en request-header — samma cross-tenant-skrivning som fixen skulle stänga, bara via ett annat fält.POST canonical/facts tenant_id=999999999999999999hade fortfarande gett 201.X-0pt-Internal-Tenantär klientkontrollerad och därmed inte en behörighetskälla (krav 2 och 4).INTERNAL_TENANT_IDsom global fallback band inte tjänsten till en verifierad identitet eller ett per-route-scope; en enda miljövariabel blev "alla tenants".req.headersorörda — en klient-konstrueradx-0pt-verified-tenant/x-0pt-verified-subkunde passera på alla vägar som inte skrev över dem (bl.a. dev-läget).POST /api/0pt/quality/bridge-runtartenant_idur body och auto-provisionerar tenant-scopade regler — den saknade helt tenant-guard.Rättad implementation (
b97ad0b, samma PR)INTERNAL_SERVICE_TENANTS(server-env, kommaseparerad allowlist) är nu enda källan till tenant-auktoritet förX-Internal-Token-principalen. Tom/osatt ⇒ ingen tenant-auktoritet ⇒ tenant-scopade skrivningar nekas med 403 (fail closed). Tenant-lösa maskinrutter (evidence-outbox/dispatch, er/candidates, search/definitions) påverkas inte.x-0pt-verified-tenant,x-0pt-verified-subochx-0pt-verified-service-tenantspå alla vägar (intern token, session, Bearer, dev-läge) innan den sätter dem själv.x-0pt-verified-service-tenantsbär allowlisten;assertTenantMatchesVerifiedkontrollerar medlemskap och nekar allt utanför scope. En (1) allowlistad tenant sätts även somx-0pt-verified-tenantså befintliga single-tenant-kontroller fortsätter fungera.ensureBaselineRules.X-0pt-Internal-Tenantär uttryckligen inte ett kontrakt och läses aldrig.tests/auth/internal-token-tenant-scope.test.ts): förfalskad header ignoreras/stripas, tom scope ⇒ 403, cross-tenant ⇒ 403, inom scope ⇒ OK, Bearer/dev oförändrat.tests/auth+0pt-cross-tenant-routes+canonical-facts+quality-bridge= 87/87 gröna;tsc -p tsconfig.check.json --noEmitren.Krav 1–10
INTERNAL_SERVICE_TENANTS+ ruttlistaassertAuthConfigSafeorörd; strip även i devb97ad0bRekommendation
Merge först efter ägargodkännande, och sätt
INTERNAL_SERVICE_TENANTS=379976258701823235(t_0pt) i prod-secreten innan deploy. Utan den variabeln nekar den interna principalen tenant-scopade skrivningar (avsiktligt fail closed) — det ska vara ett medvetet driftval, inte en överraskning.Ingen merge har utförts av agenten. Ingen produktionspåstående utan deploy-SHA + positiva/negativa HTTP-tester efter release.
Uppföljning — rättad implementation pushad (
b97ad0b)Den blockerade klientheader-varianten är ersatt. Sammanfattning av läget nu:
Vad som ändrats
INTERNAL_SERVICE_TENANTS(server-env) är enda tenant-auktoriteten förX-Internal-Token. Tom lista ⇒ ingen auktoritet ⇒ tenant-scopade skrivningar 403.x-0pt-verified-tenant,x-0pt-verified-subochx-0pt-verified-service-tenantspå alla vägar innan den sätter dem själv.assertTenantMatchesVerifiedkontrollerar medlemskap i service-scope och failar stängt på tom scope.POST /api/0pt/quality/bridge-runfick samma guard (saknades helt).X-0pt-Internal-Tenantläses aldrig och är inte ett kontrakt.Verifierat lokalt
tests/auth/internal-token-tenant-scope.test.ts: 16 tester (förfalskad header ignoreras/stripas, tom scope 403, cross-tenant 403, inom scope OK, Bearer/dev oförändrat).tests/auth+0pt-cross-tenant-routes+canonical-facts+quality-bridge= 87/87.tsc -p tsconfig.check.json --noEmitren.CI: körningar 422444–422447 är köade/pågående på
b97ad0b(runners upptagna). Ingen merge utförd — väntar på ägargodkännande och grön CI.Driftföreberedelse: sätt
INTERNAL_SERVICE_TENANTS=379976258701823235(t_0pt) i 0pt-prod innan deploy. Utan den nekar den interna principalen tenant-scopade skrivningar (avsiktligt fail-closed).