Svelte / Advanced: rendering, resources and release evidence / Lesson 15

Untrusted markup, uploads and security boundaries

Review each input sink and public output with its own trust and resource contract.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Separate escaped markup, raw HTML, browser origin policy and domain permission.
Define bounded upload intake, private storage and safe error disclosure.

Escaping is contextual and raw HTML is a capability

Ordinary Svelte text interpolation and {@html} have different trust requirements. Raw markup can introduce executable or misleading content unless a reviewed content pipeline permits it. A homemade replace call is not a complete HTML sanitizer. Scoped CSS limits selector reach under compiler rules; it is not a security sandbox or a guarantee that arbitrary injected markup is safe. URL, style, attribute and script contexts also have different parsing rules. Keep untrusted titles as text and validate links and destinations according to their own contracts rather than assuming one string validation protects every sink.

Separate intake, inspection and publication

The synthetic policy note keeps uploads private until authorized review and assigns storage keys on the server. A caller-supplied filename or MIME label does not prove actual content type or safety. Bound bytes, parts, field count and temporary storage before buffering can grow without limit. Define cleanup for rejected or interrupted partial intake, not only for a successful action handler. The JSON is not an installed parser configuration and no file is received. A real implementation must match adapter/runtime capabilities and the business content policy without promoting an arbitrary size threshold into universal advice.

json Synthetic bounded-upload policy

{"intake":"synthetic-only","storage":"private-quarantine","keyOwner":"server","limits":["bytes","parts","fields","temporary-space"],"cleanup":"rejection-and-interruption","publication":"after-domain-approval"}

The record applies no parser or storage setting and accepts no file. It lists independent requirements for review.

Browser origin checks and current authority are different controls

Kit’s form/action protections and configuration need exact-version review, but no origin control replaces authentication and object permission. CORS controls browser reading and is ignored by many non-browser clients. Cookie attributes, CSRF protections and trusted proxy/origin reconstruction have separate purposes. Do not disable origin checks or broaden every allowed origin to hide a deployment mismatch. External URL fetching also exposes server network authority, so prefer approved capabilities or a reviewed destination/redirect/size/deadline policy. This course performs no network scan or private-target probe and does not implement a credential or cryptographic protocol.

Project known safe failures instead of source exceptions

The local mapper recognizes one validation code and returns a generic category for every unknown error. It does not trust an arbitrary status property or expose a private source message. A real action can return structured expected field problems through fail, while unexpected errors follow Kit’s safe error handling and internal correlation. This test is ordinary JavaScript, not a handleError hook or an HTTP response. A safely formatted failure also cannot establish that a source write rolled back. Preserve logical operation identity and reconcile uncertain effects separately from public error presentation.

javascript Complete offline public-error projection

function safeError(error){return error?.code==="INVALID_TITLE"?{code:"INVALID_TITLE"}:{code:"INTERNAL_ERROR"};}
console.assert(safeError({code:"INVALID_TITLE"}).code==="INVALID_TITLE");
console.assert(JSON.stringify(safeError({status:200,message:"private-source"}))==='{"code":"INTERNAL_ERROR"}');

Known validation stays specific and unknown private details are omitted. No Kit error hook or action is executed.

Use maintained boundaries and honest verification

Review dependency security advisories, safe headers, CSP, body limits and server-only imports using the project’s authorized process. A public environment prefix or returned load data can disclose a secret even when the source module itself is private. Verify allowed and denied cases, partial upload cleanup and exact public error fields with safe synthetic data. This course parses the policy and runs only safeError; it does not apply CSP, receive files, sanitize HTML, authenticate requests or assess a deployed site. Real security verification must target the exact adapter/compiler versions and an authorized environment, with no invented scan or successful integration claim.

Common errors and fixes

Untrusted text is inserted through {@html}

Why it happens: A raw-markup capability was treated like ordinary escaped interpolation.
How to fix it: Use text or a reviewed content/sanitization pipeline appropriate to the source.
Prevent it next time: Test actual output contexts rather than a string replacement alone.

A filename determines a private server path

Why it happens: Caller metadata was promoted into storage authority.
How to fix it: Use server-controlled identifiers and explicit authorized publication.
Prevent it next time: Test path-like input without accessing arbitrary files.

A generic error exposes private source details

Why it happens: Raw exceptions became the public response model.
How to fix it: Return known safe categories and retain detail internally under controls.
Prevent it next time: Assert exact public keys and secret-message omission.

Check your understanding

1. Does scoped CSS make arbitrary raw HTML safe?

Show worked solution

No. Selector scoping is a styling behavior, not a sanitization or script-execution boundary. Keep untrusted data as text unless an appropriate reviewed content pipeline permits markup, and verify the actual output context. A styling feature cannot replace source and audience policy.

2. Why is an origin check not complete action authorization?