Will It Vibe?mark_safe() wraps dynamic 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
mark_safe() is called with something other than a single static string literal (an f-string, concatenation, .format(), or a bare variable), telling Django's template layer to render that value without escaping. Applied to anything derived from user input, this is a direct XSS sink; applied to a fixed literal it is harmless, which is exactly the distinction this check draws.
Why it matters
mark_safe() tells Django's template engine to render a string without HTML-escaping it. Called on a fixed, developer-written literal that is harmless; called on anything built from a variable, an f-string, concatenation, or .format(), it is a direct XSS sink the moment any part of that value can be influenced by a user or external system.
How to fix it
For dynamic content, stop calling mark_safe() directly on it. If the string needs to include user data inside markup, build it with django.utils.html.format_html(), which escapes each interpolated argument automatically while still letting you write the surrounding HTML literally. If the content is genuinely pre-sanitized rich text, sanitize it with bleach/nh3 immediately before marking it safe, and keep that sanitization call next to the mark_safe() so the two never drift apart.
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