For a cross-site scripting fix, check that the encoding matches where the value lands: HTML body, attribute, JavaScript, CSS or URL. OWASP says browsers parse each context differently, so the wrong encoding can leave the hole open or break the page. Prefer framework defaults over custom code.
Why context matters
The OWASP Cross Site Scripting Prevention Cheat Sheet states that each variable in the user interface should pass through an output encoding function, and that many methods exist because browsers parse HTML, JavaScript, URLs and CSS differently. It adds that using the wrong method may introduce weaknesses or harm functionality.
An AI assistant sees code, not always the full rendering path. It may add a generic escape call that works for one context and fails in another.
Match the fix to the context
| Where the value is placed | What to check in the fix |
|---|---|
| Between HTML tags | Framework auto-encoding is on, or an HTML encoder is used |
| Inside an HTML attribute | Attribute encoding, with attribute values quoted |
| Inside a script block or event handler | Avoid putting untrusted data there at all, or use JavaScript encoding |
| Inside CSS | Avoid or use CSS encoding |
| In a URL | URL encoding, plus validation of the scheme |
Treat this as a review prompt rather than a complete rulebook, and read the cheat sheet for the details in your stack.
Steps to review the suggestion
- Find the sink. Where does the value reach the page? Name the context.
- Prefer the framework. OWASP advises starting with your framework's default output encoding. A fix that bypasses it with a raw HTML insertion call deserves a close look.
- Check for unsafe sinks. Assigning untrusted text to a property that parses HTML is a common pattern. If HTML must be allowed, the cheat sheet shows sanitizing it with a maintained library first.
- Do not accept a header as the whole fix. The cheat sheet lists sole reliance on a Content Security Policy as an anti-pattern. A policy is a useful extra layer, not a replacement for encoding.
- Test with a payload. Send a script-like string through the real page and confirm it renders as text.
Common ways AI fixes go wrong
- Escaping on input and storing the result, then encoding again on output, which can produce double encoded text.
- Stripping angle brackets and calling it done, which does not cover attribute or script contexts.
- Fixing one template while sibling templates keep the same pattern.
The second point is reasoning rather than a quote from a source, so confirm it in your own testing.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a scan of a running web app reports findings from the outside, which is a useful second check after a fix lands in staging.
Safeguard offers code scanning and dynamic scanning, plus fix pull requests that are off by default. A reviewer still confirms the context, because the right answer depends on your templates.
Quick check
Is HTML sanitization the same as output encoding?
No. Encoding turns characters into harmless text. Sanitization removes unsafe markup from HTML you intend to allow. Use each where it fits.
Does a Content Security Policy fix an XSS finding?
It adds a layer, but OWASP lists sole reliance on it as an anti-pattern. Fix the encoding too.
Sources
Last reviewed: 19 October 2026.
