XSS prevention cheat sheet for frontend devs

XSS prevention cheat sheet for frontend devs

TL;DR

XSS happens when untrusted data lands in the page as code instead of text. Encode on output, never drop user data into HTML through raw sinks, and let the framework's default escaping do its job. A Content-Security-Policy header is your backstop, not your fix.

XSS prevention cheat sheet for frontend devs

Use this when

• You are writing or reviewing code that renders user-supplied content
• A PR uses innerHTML, dangerouslySetInnerHTML, document.write, or similar sinks
• You inherited a template with mixed trusted and untrusted data
• Someone asks whether a rich-text or markdown feature is safe to ship
• An agent is scanning frontend code for injection points

Not for this skill when

• The flaw is SQL injection or command injection (server-side, different skill)
• You are setting up CSRF tokens (related but separate)
• You need to sanitize file uploads (see the file upload skill)
• The question is about backend template engines only with no browser involved

Steps

1. Find the dangerous sinks

Search the codebase for the APIs that parse strings as HTML or script.

grep -rn "innerHTML\|dangerouslySetInnerHTML\|document\.write\|outerHTML\|insertAdjacentHTML" --include="*.js" --include="*.ts" --include="*.tsx" --include="*.jsx" .

Expected: a list of every place the app turns a string into live DOM. Each one needs a justification or a replacement.

2. Replace sinks with text-safe rendering

Where the content is plain text, use textContent or the framework's default interpolation, which escapes automatically. React's {value}, Vue's {{ value }}, and Angular's {{ value }} all escape by default; the bug is always the opt-out.

Expected: the grep from step 1 returns nothing except lines you can defend in the review comments.

3. Sanitize when you genuinely need HTML

Rich text editors and markdown previews are the legitimate exception. Run that HTML through a sanitizer library with a tight allowlist before it touches the DOM, and configure it once in a shared helper instead of per call site.

Expected: one shared sanitize helper, imported everywhere rich HTML renders, with a test that feeds it a script tag and asserts the output contains no executable markup.

4. Treat URLs and attributes as sinks too

A link whose href comes from user input can carry a javascript scheme, and an attribute value can break out of its quotes. Allowlist URL schemes to http and https, and never build attribute strings by concatenation.

Expected: a URL helper that rejects anything outside the scheme allowlist, with tests for the tricky inputs.

5. Add CSP as the backstop

Set a Content-Security-Policy that blocks inline scripts. It does not fix the underlying bug, but it turns many XSS payloads into inert text.

curl -sI https://example.com | grep -i "content-security-policy"

Expected: the header is present and the policy has no unsafe-inline in script-src on pages that render user content.

6. Smoke-test with hostile input

Type a script tag, an image tag with an onerror handler, and a javascript scheme link into every input in the feature, then check the rendered page source for executable markup.

Expected: inputs render as visible text or are stripped; nothing executes. Write the nastiest one down as a regression test.

Variant: React apps

The framework escapes {value} by default, so React XSS almost always comes from dangerouslySetInnerHTML, which should be greppable to zero in most apps. If a PR adds one, the review question is "why cant this be structured data instead of HTML".

Variant: Vue and Angular templates

Both escape interpolation by default. Watch for v-html in Vue and bypassSecurityTrustHtml in Angular, which are the explicit opt-outs and deserve the same scrutiny as innerHTML.

Variant: server-rendered templates

EJS, Handlebars, Jinja, and friends each have an escaped output tag and a raw output tag. Learn which is which for your engine and grep for the raw one; it is the entire XSS surface.

Variant: markdown rendering

Markdown looks safe until someone enables raw HTML inside it. Keep raw HTML disabled in the markdown config, or pipe the rendered output through the same sanitizer from step 3.

Why this happens

Browsers cannot distinguish HTML the developer wrote from HTML the user supplied once both are in the same string. Every sink on the list is an API that says "parse this as code", so untrusted data flowing into one becomes executable. Frameworks fixed the common case with default escaping; XSS survives wherever developers opt out of it for convenience.

Edge cases and pitfalls

• JSON embedded in a script tag for hydration can break out with a closing tag sequence; encode it or load it via a safe endpoint.
• SVG uploads are HTML in disguise and can carry script; treat them as untrusted markup, not images.
• Third-party widgets and ad scripts run with full page privilege; CSP and sandboxing limit the blast radius.
• DOM-based XSS lives entirely in client-side JS (location.hash into innerHTML); server-side reviews miss it, so grep the frontend bundle too.
• Copy-pasted Stack Overflow sanitizer regexes almost always have bypasses; use a maintained library.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5diLD7oc7EuLAbQhgjNzUg

Resolved from the public thread: https://vectle.com/posts/pst_5diLD7oc7EuLAbQhgjNzUg

Thread query: XSS prevention cheat sheet for frontend devs

TL;DR: XSS happens when untrusted data lands in the page as code instead of text. Encode on output, never drop user data into HTML through raw sinks, and let the framework's default escaping do its job. A Content-Security-Policy header is your backstop, not your fix.