mark_safe
detected BAN-B308 223 GROUP_TEMPLATE,
224 [
225 (
226 mark_safe('data-toggle="buttons"'), # noqa: S308 227 rtl_switch,
228 )
229 ], # Only one group.
205 gettext("Toggle text direction"),
206 rtl_name,
207 "rtl",
208 mark_safe('checked="checked"'), # noqa: S308 209 "RTL",
210 ),
211 (
172 name,
173 format_html(
174 'data-value="{}"',
175 mark_safe( # noqa: S308 176 value.encode("ascii", "xmlcharrefreplace").decode("ascii") 177 ), 178 ),
179 char,
180 )
244 name,
245 format_html(
246 'data-value="{}"',
247 mark_safe( # noqa: S308 248 value.encode("ascii", "xmlcharrefreplace").decode("ascii") 249 ), 250 ),
251 char,
252 )
424 errors.extend(self.format_result(results))
425 if errors:
426 return format_html_join(
427 mark_safe("<br />"), # noqa: S308428 "{}",
429 ((error,) for error in errors),
430 )
Use of mark_safe()
may expose cross-site scripting (XSS) vulnerabilities and should be reviewed.
mark_safe
explicitly marks a string as safe for (HTML) output purposes.
Django auto-escapes all output from template variable tags unless explicitly told not to. Use of mark_safe()
function implies that the parameter is safe for client-side output without Django's automatic string escaping. It's a legitimate way of defining strings that are intended to be interpreted as HTML.
Using mark_safe()
on an internally generated string is okay but becomes a security risk if used on unchecked user input.
Since this is an audit issue, some occurrences may be harmless here. The goal is to bring the issue to attention. Please make sure that the input string is trusted. If the occurrences don't seem to be valid, please feel free to ignore them.
When possible, use formathtml. It is safe as all arguments are passed through conditionalescape()
mark_safe("<b>%s</b> %s" % (user_input))
format_html("<b>%s</b>, user_input)