Challenge 3: Demonstrate Auto-Escaping — Possible Solution
====================================================================

# catalog/views.py

from django.shortcuts import render

def escaping_demo(request):
    dangerous_value = '<script>alert("xss")</script>'
    return render(request, "catalog/escaping_demo.html", {"value": dangerous_value})

<!-- catalog/templates/catalog/escaping_demo.html -->

<h2>Escaped (default):</h2>
<p>{{ value }}</p>

<h2>Unescaped (|safe):</h2>
<p>{{ value|safe }}</p>

WHAT EACH VERSION ACTUALLY SENDS TO THE BROWSER
--------------------------------------------------
{{ value }} — the escaped version — sends this literal HTML source:

    <p>&lt;script&gt;alert(&quot;xss&quot;)&lt;/script&gt;</p>

The browser displays this as plain, inert TEXT on the page:

    <script>alert("xss")</script>

It looks like a script tag when read, but it is NOT one — the angle
brackets and quotes were converted to HTML entities (&lt;, &gt;, &quot;),
so the browser's HTML parser never recognizes it as a real <script>
element at all. Nothing executes.

{{ value|safe }} — the unescaped version — sends this literal HTML source:

    <p><script>alert("xss")</script></p>

The browser's HTML parser sees a genuine <script> tag here and executes
its contents immediately — the alert() popup actually fires. If
`dangerous_value` had come from user input (a comment, a profile bio, a
search query) rather than a hardcoded string, this is a textbook stored or
reflected XSS vulnerability, exactly as covered in the XSS course.

WHY THIS IS DANGEROUS OUTSIDE OF TRUSTED CONTENT
---------------------------------------------------
`|safe` doesn't mean "this value IS safe" — it means "trust me, don't
check this value, output it exactly as given." Using it on anything that
ultimately traces back to user input (directly or indirectly) removes
Django's one built-in defense against exactly this class of attack. The
XSS course's guidance applies directly: `|safe` should only ever be used
on content that has already been through a real sanitization step (e.g. a
DOMPurify-equivalent pass on the server), never applied reflexively to
make a rendering error go away.

WHY THIS WORKS
--------------
- Auto-escaping is Django's DEFAULT behavior for every template variable —
  no configuration or explicit filter is required to get the safe
  behavior; you have to deliberately opt OUT with `|safe` (or the
  {% autoescape off %} block tag) to lose that protection.
- The escaping happens at the exact moment a variable is inserted into
  the rendered HTML — it converts the five HTML-significant characters
  (<, >, ", ', &) into their entity equivalents, which is precisely what
  neutralizes markup without needing to strip or reject the original
  string content.