Most important security feature to enable via headers is Trusted Types.
Trusted Types disallows using APIs dynamically evaluating or loading JavaScript. This largely prevents client-side remote code execution vulnerabilities (XSS).
Static site design + strong CSP does the rest.
Conversation
Possible to make Trusted Types policies to trust sanitizers. It should be avoided. Stick to proper APIs for DOM manipulation, etc.
If you avoid dynamic HTML/JS parsing/loading you can use trusted-types 'none' to disallow this. Same concept as disallowing 'unsafe' blocks in Rust.
2
5
Replying to
Modify DOM via APIs for creating and modifying nodes in a structured way rather than outputting HTML and rendering it dynamically. Send this kind of content in a much simpler, structured non-HTML format and turn it into DOM nodes. Doesn't mean having to parse Markdown in browser.
1
Replying to
It's not dangerous but it seems inefficient to ship a Markdown parser rather than essentially sending an AST from after parsing and converting that into a tree of DOM nodes with simpler code.
1
It's much safer this way since you cannot have code execution (XSS, etc.) via bugs in how you implement converting Markdown to HTML, since you aren't converting Markdown to HTML. You can't somehow end up injecting scripts/styles via APIs with proper Trusted Types + CSP setup.
1
1
Replying to
You would have to directly / explicitly make the mistake by setting specific styles or modifying the DOM in a way that could cause it. Setting things up this way with proper Trusted Types + CSP prevents dynamic JS, CSS, HTML, etc. just dynamic DOM without scripts, etc.
1
You could set up a sandboxed same-origin frame for the content in order to explicitly sandbox it from the UI.
There's a Content-Security-Policy sandbox directive for this kind of thing. You can have a properly sandboxed nested frame.