* feat: isolate the raw-app editor preview when the app opts into sandboxing
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix: gate job reads from a sandboxed editor preview like the deployed app
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix: send a plain user in a sandboxed raw app's startup message
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* chore: pin ui_builder to d3fdb70
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* fix: serve the raw-app preview shell sandboxed, load a blob copy in the editor
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix: give the preview shell the deployed app wrapper's sandbox flags
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* fix(frontend): keep crawlers off the login page
Every page on the hub links to /user/login with itself in `rd`, so a crawler
sees one login URL per hub page — 4,311 of them in Search Console, all
rendering this same form and flagged as duplicates without a canonical. Nothing
about a login page belongs in an index, on any instance.
Mark the page noindex, as public_run already is, and ship a robots.txt that
keeps crawlers out of /user/ and /api/. The frontend is embedded as static
assets with an index.html fallback, which is why /robots.txt answered with the
app shell until now; a real file in static/ is served as itself.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(frontend): let crawlers fetch the login page so the noindex is seen
robots.txt disallowed /user/, which stopped a crawler fetching /user/login at
all — and a page that is never fetched never shows its noindex. The two halves
cancelled: the URLs would have moved from "duplicate" to "blocked" rather than
out of the index.
Drop the disallow, keeping /api/. And since the app is client-rendered, the
meta tag only exists after a render pass; send X-Robots-Tag on /user/* from
serve_path as well, which a crawler sees on the first fetch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* fix(apps): make public apps opt into cross-origin isolation via wm_coep
Public app pages served at /public/* and custom paths /a/* were not
getting the COEP/COOP/CORP headers, so they were blocked when embedded
as an iframe inside a cross-origin-isolated page (e.g. another raw app,
which sets Cross-Origin-Embedder-Policy: require-corp). A nested
document loaded into a require-corp context must itself set COEP for
the iframe to load.
Rather than applying the isolation headers to all public pages (which
would also force COEP on classic apps and break subresources without
CORP, e.g. external image URLs or embeds), public apps now opt in via
a `wm_coep` query param on the embed URL:
<iframe src="https://<domain>/public/<ws>/<secret>?wm_coep=on">
The app publish drawer gains a URL/Embed toggle: "URL" shows the plain
shareable link (param-free), "Embed" shows a ready-to-copy iframe
snippet with wm_coep baked in, so the flag is discoverable exactly when
embedding and absent otherwise.
`wm_coep` is consumed internally and stripped from the app `query`
context so it doesn't collide with app-defined params. Only params we
own are stripped (an explicit set), not the whole `wm_` prefix.
Fixes GIT-884
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* nit
* nit
* fix(apps): only bake wm_coep into embed snippet for raw apps
AppEditorHeaderDeploy is shared by the classic (AppEditorHeader) and raw
(RawAppEditorHeader) deploy drawers. The embed snippet unconditionally
appended ?wm_coep=on, which for a classic/low-code app forces COEP
require-corp on the document and breaks no-CORP cross-origin subresources
(external <img> in AppImage/AppStatCard/AppNavbar, {@html} embeds in
AppHtml, CDN import() in AppCustomComponent) — the exact regression the
opt-in design avoids.
Add a `rawApp` prop (default false); the raw header passes rawApp. The
flag is appended only for raw apps; classic apps get a plain iframe
snippet, and the wm_coep helper text is shown only for raw apps.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* fix: add CORS headers to static assets for iframe context sharing
Add Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, and
Cross-Origin-Resource-Policy headers to static assets served by the backend
to match the vite preview config. This enables the TypeScript worker to work
correctly when ui_builder is loaded in an iframe.
Fixes#7453
Co-authored-by: windmill-internal-app[bot] <windmill-internal-app[bot]@users.noreply.github.com>
* fix: add CORS headers only for /apps_raw paths and force reload on navigation
- Only add Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, and
Cross-Origin-Resource-Policy headers for /apps_raw/ paths (not all static assets)
- Add frontend navigation handler to force page reload when navigating from
non-apps_raw paths to /apps_raw/add or /apps_raw/edit
- This ensures the TypeScript worker works correctly while avoiding CORS issues
for external iframe embeds in other parts of the app
Co-authored-by: Ruben Fiszel <rubenfiszel@users.noreply.github.com>
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
* fix: also reload when navigating from /apps/get_raw/ to apps_raw editor
When viewing a raw app at /apps/get_raw/, the cross-origin isolation
headers are not present. Force a page reload when navigating from
this path to /apps_raw/add or /apps_raw/edit to ensure the headers
are fetched from the server.
Co-authored-by: Ruben Fiszel <rubenfiszel@users.noreply.github.com>
* Update +layout.svelte
---------
Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Co-authored-by: windmill-internal-app[bot] <windmill-internal-app[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Ruben Fiszel <rubenfiszel@users.noreply.github.com>
Co-authored-by: Ruben Fiszel <ruben@windmill.dev>
* feat: add optional CSP headers when ENABLE_CSP_HEADERS is set
- Add middleware to conditionally set Content-Security-Policy headers
- Check for ENABLE_CSP_HEADERS environment variable
- Apply secure default CSP policy suitable for web applications
- Follows existing middleware patterns in codebase
Resolves#6031🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Ruben Fiszel <rubenfiszel@users.noreply.github.com>
* perf: optimize CSP headers with lazy_static and add configurability
- Cache CSP_ENABLED and CSP_POLICY using lazy_static to avoid env var lookups on every request
- Add comprehensive documentation to add_csp_headers middleware function
- Make CSP policy configurable via CSP_POLICY environment variable
- Maintain backward compatibility with secure default policy
- Implement proper error handling for custom CSP policy values
Co-authored-by: Alexander Petric <alpetric@users.noreply.github.com>
* refactor: conditionally add CSP middleware layer instead of NO-OP
- Use .option_layer() to only add CSP middleware when ENABLE_CSP_HEADERS is set
- Remove runtime conditional check from add_csp_headers function
- Improve performance by avoiding unnecessary middleware execution when disabled
Co-authored-by: Ruben Fiszel <rubenfiszel@users.noreply.github.com>
* refactor: conditionally add CSP middleware layer instead of NO-OP
Remove CSP_ENABLED variable and instead check if CSP_POLICY is not empty.
This eliminates the need for a separate enable flag and simplifies the logic
to just check if a meaningful CSP policy is configured.
- Remove CSP_ENABLED lazy_static variable
- Simplify CSP_POLICY to use unwrap_or_default()
- Update conditional middleware logic to check !CSP_POLICY.is_empty()
- Update documentation to reflect new behavior
Co-authored-by: Ruben Fiszel <rubenfiszel@users.noreply.github.com>
* refactor: conditionally add CSP middleware layer instead of NO-OP
Move CSP headers from general middleware stack to static assets only.
CSP headers are only relevant for browsers consuming static content,
not for API endpoints.
Changes:
- Add CSP headers directly to static asset responses in serve_path()
- Remove CSP middleware from general middleware stack
- Remove unused add_csp_headers middleware function
- Maintain same CSP_POLICY environment variable configuration
Co-authored-by: Alexander Petric <alpetric@users.noreply.github.com>
* fix: conditionally compile CSP header imports with static_frontend feature
Fixes unused import errors by wrapping HeaderValue and CSP_POLICY imports
with #[cfg(feature = "static_frontend")] to match their usage context.
Co-authored-by: Alexander Petric <alpetric@users.noreply.github.com>
* refactor: move CSP lazy static block to static_assets.rs
- Move CSP_POLICY lazy static from lib.rs to static_assets.rs for better encapsulation
- Remove crate-level import since CSP_POLICY is now local to static_assets module
- Maintain same functionality with proper feature gating for static_frontend
Co-authored-by: Ruben Fiszel <rubenfiszel@users.noreply.github.com>
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Ruben Fiszel <rubenfiszel@users.noreply.github.com>
Co-authored-by: Alexander Petric <alpetric@users.noreply.github.com>
* fix(backend): set http security headers (vol.1)
* (vol.2) minimal *working* content security policy
* (vol.3) set csp only if https and if hosted on cloud
* improve generics
* get CLOUD_HOSTED from extension
* remove X-XSS-Protection
rationale as per: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection
* conditionally set all security related http headers