XSS Prevention for Django

mark_safe() marks the returned content as "safe to render." This instructs the template engine to bypass HTML escaping, creating the possibility of a XSS vulnerability.

Recommendation: If needed, use in combination with format_html() and review each usage carefully. Create an exemption with # nosem.

Code example:

mark_safe(html_content)

References:

• mark_safe() documentation
• Bandit Check B703 - Django mark_safe()
• format_html() documentation

The SafeString class is how Django determines which variables should be escaped and which should not. Elements passed to mark_safe() are returned as a SafeString. Invoking SafeString directly will bypass HTML escaping which could create a XSS vulnerabliity.

Recommendation: Prefer mark_safe() if necessary.

Code example:

SafeString(f"<div>{request.POST.get('name')}</div>")

References:

• Filters and auto-escaping in Django
• SafeString documentation

Registering a filter with is_safe=True indicates to Django that the filter absolutely does not introduce any unsafe HTML characters. The value returned from the filter will be marked as "safe" when the input is also marked "safe". Generally, this is acceptable, but if you cannot be certain the filter is safe, it may introduce a XSS vulnerability.

Recommendation: Prefer mark_safe() if necessary.

Code example:

@register.filter(is_safe=True)
def myfilter(value):
  return value

References:

• Custom filters and auto-escaping

The __html__ magic method is used by the Django template engine to determine whether the object should be escaped. If available, the value returned by the method will not be escaped and could introduce a XSS vulnerability.

Recommendation: Prefer mark_safe() if necessary.

Code example:

class RawHtml(str):
  def __html__(self):
    return str(self)

References:

• conditional_escape() documentation
• conditional_escape() source code

The html_safe() decorator adds the __html__ magic method to the supplied class. The added __html__ magic method will return the exact string representation of the class (e.g., str(self)). Because objects with the `__html__ method are not escaped, this could create a XSS vulnerability.

Recommendation: Prefer mark_safe() if necessary.

Code example:

@html_safe
class RawHtml(str):
  pass

References:

• html_safe() documentation

Writing results directly to HttpResponse or similar classes bypasses the Django template engine. This also bypasses the HTML escaping built into the template engine and creates the possibility of a XSS vulnerability. Use render() with a template instead.

Recommendation: Use render()

Code example:

return HttpResponse("Hello, " + name)

References:

• Django Book - Security: XSS
• Example of XSS via HttpResponseBadRequest
• HttpResponse subclasses

Autoescaping can be globally disabled in Django settings. This should never be done if you are rendering HTML; now, every response returned to the user will need to be audited to ensure it is free of XSS vulnerabilities.

Recommendation: Do not globally disable escaping. If HTML escaping is necessary, use mark_safe().

Code example:

TEMPLATES = [
  {
    ...,
    'OPTIONS': {'autoescape': False}
  }
]

References:

• Django template settings documentation

Setting autoescape=False in a template context will disable HTML escaping for that template. Any data rendered in that template could be a XSS vulnerability.

Recommendation: Use mark_safe() if necessary

Code example:

response = render(request, "index.html", {"autoescape": False})

References:

• Context source code
• Template.render() documentation
• render_to_string() documentation
• render() documentation

The | safe filter marks the content as "safe for rendering." This has the same effect as mark_safe() in Python code. This will permit direct rendering of HTML and create a possible XSS vulnerability.

Recommendation: Use mark_safe() in Python if necessary.

Code example:

{ { name | safe } }

References:

• | safe filter documentation

The | safeseq filter marks the content as "safe for rendering." This has the same effect as mark_safe() in Python code. This will permit direct rendering of HTML and create a possible XSS vulnerability.

Recommendation: Use mark_safe() in Python if necessary.

Code example:

{{ names | safeseq | join:", " }}

References:

• | safeseq documentation

The {$ autoescape off %} block disables autoescaping for whole portions of the template. Disabling autoescaping allows HTML characters to be rendered directly onto the page which could create XSS vulnerabilities.

Recommendation: Use mark_safe() in Python if necessary.

Code example:

{% autoescape off %}

References:

• autoescape block documentation

Unquoted template variables rendered into HTML attributes is a potential XSS vector because an attacker could inject JavaScript handlers which do not require HTML characters. An example handler might look like: onmouseover=alert(1). HTML escaping will not mitigate this. The variable must be quoted to avoid this.

Recommendation: Always use quotes around HTML attributes.

Code example:

<div class="{{ classes }}"></div>

References:

• Flask cross-site scripting considerations

Template variables in a href value could still accept the javascript: URI. This could be a XSS vulnerability. HTML escaping will not prevent this. Use url_for to generate links.

Recommendation: Use url_for to generate links.

Code example:

<a href="{{ link }}"></a>

References:

• Flask cross-site scripting considerations

Template variables placed directly into JavaScript or similar are now directly in a code execution context. Normal HTML escaping will not prevent the possibility of code injection because code can be written without HTML characters. This creates the potential for XSS vulnerabilities, or worse.

Recommendation: Use the json_script template tag and read the data in JavaScript using the element ID.

Code example:

<script>var name = {{ name }};</script>

References:

• Template engines: Why default encoders are not enough
• Safely including data for JavaScript in a Django template
• json_script documentation