Skip to content

[fix] Serve a Content Security Policy on portal responses#410

Open
St4NNi wants to merge 7 commits into
mainfrom
fix/portal-csp
Open

[fix] Serve a Content Security Policy on portal responses#410
St4NNi wants to merge 7 commits into
mainfrom
fix/portal-csp

Conversation

@St4NNi

@St4NNi St4NNi commented Jul 12, 2026

Copy link
Copy Markdown
Member

Closes #363

The portal was served without a Content Security Policy or related security headers.

Portal routes now carry a policy derived from what the portal actually loads, verified against the real portal build rather than copied from a template:

default-src 'self'; base-uri 'self'; object-src 'none'; frame-src 'none';
frame-ancestors 'none'; form-action 'self';
script-src 'self' 'wasm-unsafe-eval';
style-src 'self' https://fonts.googleapis.com;
img-src 'self' data:;
font-src 'self' data: https://fonts.gstatic.com;
connect-src 'self' <node S3 origin> <realm OIDC origins> <PORTAL_CSP_EXTRA_ORIGINS>

plus X-Content-Type-Options, Referrer-Policy and Cross-Origin-Opener-Policy.

'wasm-unsafe-eval' is required and is the only unsafe directive: the profile publisher hashes artifacts with a WebAssembly hashing library. It permits no JavaScript eval. There is no unsafe-inline and no unsafe-eval.

The connect origins are resolved per request from realm state rather than from environment variables, because a joined node serves the portal without any OIDC environment configuration. Extra origins, such as another node's S3 endpoint, come from PORTAL_CSP_EXTRA_ORIGINS.

The headers are scoped to the portal router. API routes stay free of an HTML oriented policy, and the ops probe endpoints are excluded because they serve metrics to scrapers rather than documents to a browser.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[fix] Portal Content Security Policy headers

1 participant