Will It Vibe?Template variable rendered with the |safe filter
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 Django template renders a variable through the |safe filter, which turns off Django's automatic HTML autoescaping for that value. If the value ever contains attacker-controlled text (a comment, a profile field, a query param echoed into context), this is a direct stored or reflected XSS path. Heuristic: this check cannot know whether the value was sanitized upstream (for example with bleach), only that autoescaping is off here.
Why it matters
The |safe filter turns off Django's automatic HTML autoescaping for that one template variable. If the value it is applied to can ever contain attacker-influenced text (a user bio, a comment, a search term echoed back, anything reflected from a request), the browser will render any HTML or <script> tag in it exactly as written, which is stored or reflected XSS. This check cannot see whether the value was sanitized before it reached the template, only that escaping is off here, so confirm the actual source of the variable before assuming it is safe.
How to fix it
Remove |safe unless the value is genuinely trusted, static, or was already run through a real HTML sanitizer such as bleach or nh3 on the way into the template context. If some markup is legitimately needed (a WYSIWYG field, for example), sanitize it once at write time or render time with an allowlist-based sanitizer, and keep |safe only on the sanitized output, never on the raw field.
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