Will It Vibe?Jinja autoescaping disabled for a variable
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A template applies the |safe filter, or wraps a value in Markup(), to what looks like a variable rather than a string literal. Both disable Jinja2's automatic HTML escaping for that value, so if it can ever contain user input this is cross-site scripting. Heuristic: the scan cannot see whether the variable actually holds attacker-controlled data.
Why it matters
Jinja2 automatically HTML-escapes {{ }} expressions so a value like <script>alert(1)</script> renders as inert text. The |safe filter and Markup() both turn that protection off for the specific value they wrap, so if that value can ever contain user input (a comment, a profile field, a query parameter reflected into the page) the browser executes it as real markup, which is cross-site scripting.
How to fix it
Remove |safe or Markup() from any value that is not a fixed, developer-authored string, and let Jinja2's default escaping handle it. If the value genuinely needs to render as HTML (rich text from a trusted editor), sanitize it first with a library such as bleach that strips dangerous tags and attributes, and only mark the sanitized result safe.
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