Will It Vibe?dangerouslySetInnerHTML with a non-literal value
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 15 points from that category, once per scan, no matter how many places it turns up.
What it detects
dangerouslySetInnerHTML is given __html from a variable or expression rather than a string literal, a direct DOM XSS sink unless the value is sanitized.
Why it matters
dangerouslySetInnerHTML renders its __html string as live HTML, bypassing the escaping React normally applies. When that value is a variable or expression rather than a constant, any user-influenced content in it can inject scripts that run as your users. If the value is already run through a sanitizer this is safe; the rule cannot see that, so review each site.
How to fix it
Prefer rendering the value as normal text (JSX children) so React escapes it. When you genuinely need to render HTML (rich text, CMS output), sanitize it with DOMPurify.sanitize immediately before passing it to __html, and keep that sanitize call at the render site so it is obvious. Never build the HTML string by concatenating untrusted parts.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo