Template XSS Protection Disabled

When an HTML attribute value is unquoted, it can lead to parsing issues or security vulnerabilities such as injection attacks. Quoting attribute values is a best practice to ensure integrity and security.

See the following template example:

If username includes spaces or special characters, it may break the HTML structure or lead to unexpected behavior.

When using template variables in href attributes, there’s a risk of allowing JavaScript URIs, which can lead to Cross-Site Scripting (XSS) vulnerabilities. HTML escaping doesn’t mitigate this risk because it doesn’t validate the URI scheme itself.

See the following template example:

If user_input contains "javascript:alert('XSS')" it could execute a script.

Because a javascript: URI is the whole of the residual risk, the variable is only reported when it can supply the URL’s scheme — that is, when it opens the attribute value. A variable that lands further in, after a {% url %} tag, a literal path, a ? or a #, cannot introduce one: the scheme is already decided, and the engine’s own escaping turns " into " so the value cannot break out of the attribute either.

Even in scheme position, an expression the application generates cannot carry one, so it is not reported: get_absolute_url (Django’s convention for a model’s canonical path, a reverse()`d route), `request.path, and a primary key or _id, which is an integer.

When placing template variables directly into a JavaScript block, there’s a risk of code injection, which can lead to XSS vulnerabilities. HTML escaping doesn’t protect against this risk because JavaScript can execute without relying on special HTML characters.

If user_input contains malicious code like alert('XSS');, it can execute in the context of your page.

These filters mark a string or sequence as safe, preventing it from being auto-escaped in a Django template.

A plain {{ value|safe }} in a template file is not reported when every value the views render it with is safe as markup: the author’s text, or configuration the rule trusts (see Configuration).

A variable is also settled by what holds its value. On a model instance a view renders — X.objects.get(…​), X.objects.filter(…​).first(), get_object_or_404(X, …​), an element of X.objects.filter(…​) — a field the model declares a number, a date or a UUID, a validated slug, and the url of a FileField are not reported in an href. A read of the settings or of the configuration administrators edit is safe in an href and under |safe. Configuration is told by where the module imports it from, never by a name alone: the settings module (from django.conf import settings); the configuration libraries administrators edit — config from django-constance, global_preferences_registry.manager() from django-dynamic-preferences, get_solo() on a django-solo SingletonModel, for_request()/for_site()/load() on a Wagtail BaseSiteSetting or BaseGenericSetting; a function of the project every return of which is one of those reads; and the accessors the trusted_config_accessors property lists. A project object or function that merely has a configuration-like name (config, get_config()) is not configuration. A value fetched from a remote feed or catalogue is still reported:

Using the {% autoescape off %} block within your templates disables the automatic HTML escaping feature, allowing content to be rendered as raw HTML. This can be useful for certain scenarios but poses significant security risks if not handled carefully.

In this example, any HTML in user_input would be rendered directly without escaping.