Will It Vibe?.html_safe applied to request-influenced content
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
.html_safe tells Rails a string needs no escaping and renders it verbatim. Called on a value built from params with no sanitize call anywhere on the same line, any HTML or script tag the client submits renders as-is: a direct stored or reflected XSS path.
Why it matters
.html_safe skips escaping entirely, so whatever the string contains renders as live HTML in the page. Applied to a value built from params, a client can submit a script tag or an event handler attribute and have it execute in every other user's browser who views that page: stored or reflected cross-site scripting.
How to fix it
Remove .html_safe from the params-derived value. If the field genuinely needs to allow a limited set of HTML tags (rich text, for example), run it through Rails' sanitize helper with an explicit tags/attributes allowlist first, and only call .html_safe on the sanitized result. If no HTML is actually needed, just let Rails escape it by default.
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