XSS prevention in templates in Django - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is XSS and why is it a security risk in web applications?

XSS (Cross-Site Scripting) is when attackers inject harmful scripts into web pages viewed by others. It can steal data, hijack sessions, or harm users. Preventing XSS keeps websites safe and users protected.

beginner

How does Django's template system help prevent XSS by default?

Django auto-escapes variables in templates, turning special characters like < and > into safe codes. This stops harmful scripts from running when data is shown on pages.

intermediate

What does the Django template filter safe do, and why should it be used carefully?

The safe filter tells Django not to escape the content, showing it as raw HTML. Use it only when you trust the content, because it can open doors for XSS if used with unsafe data.

intermediate

Why should user input never be marked safe without validation in Django templates?

User input can contain harmful scripts. Marking it safe without checking lets attackers run code on users' browsers. Always validate or escape user data to keep the site secure.

beginner

Name two best practices to prevent XSS in Django templates.

1. Let Django auto-escape variables by default.<br>2. Avoid using <code>safe</code> filter on untrusted data.<br>Bonus: Use Django forms and validators to clean user input.

What does Django do by default to protect templates from XSS?

A Automatically escapes variables

B Disables JavaScript on pages

C Encrypts all template data

D Removes all HTML tags

Django automatically escapes variables in templates to prevent harmful scripts from running.

Which Django template filter disables escaping and shows raw HTML?

A safe

B escape

C clean

D strip

The 'safe' filter tells Django to render content as raw HTML without escaping.

Why is it risky to mark user input as safe in Django templates?

A It slows down page loading

B It can allow XSS attacks

C It hides the content

D It breaks the template syntax

Marking user input as safe without validation can let attackers run harmful scripts (XSS).

Which of these is NOT a good practice to prevent XSS in Django?

A Using Django's auto-escaping

B Validating user input

C Using Django forms for input cleaning

D Using the safe filter on all user data

Using 'safe' on all user data is unsafe and can cause XSS vulnerabilities.

If you want to display trusted HTML content in Django templates, what should you do?

A Remove all HTML tags

B Escape the content manually

C Use the safe filter

D Convert HTML to plain text

Use the 'safe' filter only when you trust the HTML content to display it without escaping.

Explain how Django templates prevent XSS attacks by default and when you might need to override this behavior.

Think about how Django treats variables in templates and what happens if you tell it not to escape.

List best practices to safely handle user input in Django templates to avoid XSS vulnerabilities.

Focus on how to treat user data before showing it on a page.

Practice

1. What does Django do by default to protect against XSS attacks when rendering variables in templates?

easy

A. It disables rendering of any user input.

B. It automatically escapes variables to prevent malicious code execution.

C. It requires manual escaping of variables in every template.

D. It converts all variables to uppercase before rendering.

Solution

1. Step 1: Understand Django's default template behavior

   Django templates automatically escape variables to prevent malicious scripts from running in the browser.

2. Step 2: Compare options with this behavior

   Only It automatically escapes variables to prevent malicious code execution. correctly states this automatic escaping feature, while others describe incorrect or unrelated behaviors.

3. Final Answer:

   It automatically escapes variables to prevent malicious code execution. -> Option B

4. Quick Check:

   Default escaping = It automatically escapes variables to prevent malicious code execution. [OK]

Hint: Remember: Django escapes variables automatically unless told otherwise [OK]

Common Mistakes:

• Thinking you must manually escape variables always
• Believing Django disables user input rendering
• Assuming variables are transformed instead of escaped

2. Which of the following is the correct way to mark a variable as safe (not escaped) in a Django template?

easy

A. {{ variable|escape }}

B. {{ variable|strip }}

C. {{ variable|safe }}

D. {{ variable|clean }}

Solution

1. Step 1: Identify the filter that marks content safe

   The safe filter tells Django not to escape the variable, rendering HTML as-is.

2. Step 2: Check other filters

   escape escapes content, strip and clean are not standard Django filters for safety.

3. Final Answer:

   {{ variable|safe }} -> Option C

4. Quick Check:

   Use safe filter to disable escaping = {{ variable|safe }} [OK]

Hint: Use '|safe' to show trusted HTML without escaping [OK]

Common Mistakes:

• Using '|escape' which does the opposite
• Confusing '|strip' or '|clean' as safety filters
• Forgetting to mark trusted content safe explicitly

3. Given the template code:

{{ user_input }}

and the user input is <script>alert('XSS')</script>, what will be rendered in the browser?

medium

A. <script>alert('XSS')</script> shown as text

B. executed as script

C. An error message about unsafe content

D. Nothing will be shown

Solution

1. Step 1: Understand default escaping of variables

   Django escapes user input by default, so HTML tags are shown as text, not executed.

2. Step 2: Apply this to the given input

   The script tags will be converted to safe text entities and displayed literally.

3. Final Answer:

   <script>alert('XSS')</script> shown as text -> Option A

4. Quick Check:

   Escaped input shows tags as text = <script>alert('XSS')</script> shown as text [OK]

Hint: Default escape shows tags as text, not scripts [OK]

Common Mistakes:

• Thinking the script runs automatically
• Expecting an error instead of safe output
• Assuming nothing is shown for unsafe input

4. You see this template code:

{{ comment|safe }}

but users report XSS attacks. What is the likely problem?

medium

A. The template engine is disabled.

B. The escape filter is missing.

C. The template variable is not wrapped in quotes.

D. The safe filter is used on untrusted user input.

Solution

1. Step 1: Analyze the use of the safe filter

   Using safe on user input disables escaping, allowing scripts to run if input is malicious.

2. Step 2: Identify the cause of XSS

   Applying safe to untrusted input is unsafe and causes XSS vulnerabilities.

3. Final Answer:

   The safe filter is used on untrusted user input. -> Option D

4. Quick Check:

   Unsafe use of safe filter = The safe filter is used on untrusted user input. [OK]

Hint: Never use '|safe' on untrusted user input [OK]

Common Mistakes:

• Assuming escape filter fixes safe misuse
• Thinking quotes affect XSS protection
• Believing template engine disables XSS automatically

5. You want to display user comments that may contain safe HTML tags like <b> and <i>, but prevent scripts. Which approach best prevents XSS while allowing these tags?

hard

A. Sanitize the comment in the backend to allow only safe tags, then use {{ comment|safe }}.

B. Use {{ comment|safe }} directly in the template.

C. Escape the comment with {{ comment|escape }} and then use |safe.

D. Store comments as plain text and never allow any HTML tags.

Solution

1. Step 1: Understand the need to allow some HTML safely

   Allowing safe tags requires cleaning input to remove dangerous scripts but keep allowed tags.

2. Step 2: Choose the correct method

   Sanitizing backend input to whitelist safe tags then marking safe in template is the secure way.

3. Step 3: Evaluate other options

   Using {{ comment|safe }} directly risks XSS by trusting raw input; combining |escape and |safe misuses filters; disallowing all HTML prevents desired formatting.

4. Final Answer:

   Sanitize the comment in the backend to allow only safe tags, then use {{ comment|safe }}. -> Option A

5. Quick Check:

   Backend sanitize + safe filter = Sanitize the comment in the backend to allow only safe tags, then use {{ comment|safe }}. [OK]

Hint: Clean input backend, then mark safe in template [OK]

Common Mistakes:

• Trusting raw user input with safe filter
• Misusing escape and safe filters together
• Disallowing all HTML when some is needed