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

Recall & Review

beginner

What is XSS and why is it important to prevent it in Flask templates?

XSS (Cross-Site Scripting) is a security issue where attackers inject harmful scripts into web pages viewed by others. Preventing XSS in Flask templates keeps users safe by stopping malicious code from running in their browsers.

beginner

How does Flask's Jinja2 template engine help prevent XSS by default?

Jinja2 automatically escapes special characters like <, >, &, and " in variables, turning them into safe HTML entities. This stops harmful scripts from running when user data is shown in templates.

intermediate

What does the Jinja2 filter |safe do, and why should it be used carefully?

The |safe filter tells Jinja2 not to escape the content, rendering it as raw HTML. Use it only when you are sure the content is safe, because it can open the door to XSS if used with untrusted data.

beginner

How can you safely include user input in Flask templates?

Simply pass user input as variables to the template without marking them safe. Jinja2 will escape them automatically, preventing scripts from running.

intermediate

What is a common mistake that can lead to XSS vulnerabilities in Flask templates?

A common mistake is using the |safe filter or disabling autoescaping on untrusted user input. This allows malicious scripts to run and can harm users.

What does Jinja2 do by default to prevent XSS when rendering variables?

A Converts variables to uppercase

B Runs user scripts safely

C Deletes user input

D Automatically escapes special characters

Jinja2 automatically escapes special characters like < and > to prevent scripts from running.

Which Jinja2 filter disables escaping and should be used with caution?

A |escape

B |safe

C |lower

D |strip

The |safe filter disables escaping and renders content as raw HTML.

If you want to display user input safely in a Flask template, what should you do?

A Pass user input normally and let Jinja2 escape it

B Disable autoescaping globally

C Use the |safe filter on user input

D Manually remove all HTML tags from input

Passing user input normally lets Jinja2 escape it automatically, preventing XSS.

What risk does using the |safe filter on untrusted user input create?

A Slower page loading

B No risk at all

C XSS vulnerability

D Data loss

Using |safe on untrusted input can allow malicious scripts to run, causing XSS.

Which of these is NOT a way to prevent XSS in Flask templates?

A Disable autoescaping globally

B Avoid using |safe on untrusted data

C Use Jinja2's automatic escaping

D Validate and sanitize user input

Disabling autoescaping globally removes protection and can cause XSS.

Explain how Flask and Jinja2 work together to prevent XSS attacks in templates.

Think about what happens when you put user data inside {{ }} in a template.

Describe a common mistake that can cause XSS vulnerabilities in Flask templates and how to avoid it.

Focus on filters and escaping settings.

Practice

1. What does Flask's template engine do by default to prevent XSS attacks when rendering variables inside {{ }}?

easy

A. It converts all text to uppercase.

B. It disables rendering of any user input.

C. It automatically escapes special HTML characters in the variable content.

D. It removes all spaces from the variable content.

Solution

1. Step 1: Understand Flask template variable rendering

   Flask templates use Jinja2, which escapes HTML special characters by default inside {{ }} to prevent scripts from running.

2. Step 2: Recognize the purpose of escaping

   Escaping converts characters like <, >, & into safe HTML entities, stopping malicious scripts from executing.

3. Final Answer:

   It automatically escapes special HTML characters in the variable content. -> Option C

4. Quick Check:

   Default escaping = safe output [OK]

Hint: Flask auto-escapes variables in {{ }} to block scripts [OK]

Common Mistakes:

• Thinking Flask disables all user input rendering
• Believing Flask changes text case automatically
• Assuming Flask removes spaces from variables

2. Which of the following is the correct way to safely display a user input variable named user_input in a Flask template to prevent XSS?

easy

A. {{ user_input|safe }}

B. {% raw user_input %}

C. {% safe user_input %}

D. {{ user_input }}

Solution

1. Step 1: Identify safe default rendering

   Using {{ user_input }} automatically escapes content, preventing XSS.

2. Step 2: Understand the risk of |safe filter

   The |safe filter disables escaping and should be used only with trusted content.

3. Final Answer:

   {{ user_input }} -> Option D

4. Quick Check:

   Use {{ variable }} without |safe for safety [OK]

Hint: Use {{ variable }} without |safe to keep escaping [OK]

Common Mistakes:

• Using |safe on untrusted user input
• Trying to use {% raw %} incorrectly
• Assuming {% safe %} is a valid Jinja2 tag

3. Given this Flask template snippet:

<p>User comment: {{ comment }}</p>

If the variable comment contains <script>alert('XSS')</script>, what will be the rendered HTML output?

medium

A. User comment: <script>alert('XSS')</script>

B. User comment:

C. User comment: &lt;script&gt;alert('XSS')&lt;/script&gt;

D. User comment: alert('XSS')

Solution

1. Step 1: Recognize Flask autoescaping behavior

   Flask escapes HTML special characters like < and > in variables inside {{ }}.

2. Step 2: Convert script tags to safe HTML entities

   The <script> tags become <script> in raw HTML, but browsers render them as <script> text, not executable code.

3. Final Answer:

   <p>User comment: <script>alert('XSS')</script></p> -> Option A

4. Quick Check:

   Escaped tags show as text, not scripts [OK]

Hint: Escaped script tags show as text, not run scripts [OK]

Common Mistakes:

• Thinking scripts run when escaped
• Confusing < with &lt;
• Assuming output removes tags completely

4. You see this Flask template code:

<p>Message: {{ message|safe }}</p>

What is the main problem with this code if message contains user input?

medium

A. It will cause a syntax error in the template.

B. It disables escaping, allowing XSS attacks if input is malicious.

C. It will remove all HTML tags from the message.

D. It automatically sanitizes the input, so no problem.

Solution

1. Step 1: Understand the effect of |safe filter

   The |safe filter tells Flask not to escape the content, rendering raw HTML.

2. Step 2: Recognize security risk with user input

   If message is user input, malicious scripts can run, causing XSS attacks.

3. Final Answer:

   It disables escaping, allowing XSS attacks if input is malicious. -> Option B

4. Quick Check:

   Using |safe on user input = security risk [OK]

Hint: Avoid |safe on user input to prevent XSS [OK]

Common Mistakes:

• Thinking |safe sanitizes input
• Believing it causes syntax errors
• Assuming it strips HTML tags

5. You want to display a user-submitted comment that may contain some safe HTML tags like <b> and <i>, but prevent any scripts or dangerous tags from running. Which Flask approach best achieves this?

hard

A. Sanitize the comment in Python code to allow only safe tags, then mark safe with |safe in template.

B. Use {{ comment|safe }} directly to allow all HTML.

C. Use {{ comment }} to escape everything, disallowing all HTML tags.

D. Use {% raw %}{{ comment }}{% endraw %} to render raw input.

Solution

1. Step 1: Understand the need for selective HTML allowance

   Allowing only safe tags requires cleaning input to remove scripts but keep tags like <b> and <i>.

2. Step 2: Use Python sanitization before rendering

   Sanitize the comment in backend code (e.g., with bleach library) to whitelist safe tags, then mark safe in template.

3. Step 3: Avoid unsafe direct |safe usage

   Directly using |safe without sanitization risks XSS.

4. Final Answer:

   Sanitize the comment in Python code to allow only safe tags, then mark safe with |safe in template. -> Option A

5. Quick Check:

   Sanitize first, then use |safe safely [OK]

Hint: Sanitize input in Python, then use |safe to allow safe HTML [OK]

Common Mistakes:

• Using |safe without sanitizing user input
• Escaping everything and losing desired formatting
• Using {% raw %} which disables escaping completely