Exercise 2: Why |safe Is Used on page.body — Possible Solution ==================================================================== WHY PLAIN {{ page.body }} WOULDN'T WORK ------------------------------ Per this chapter, {{ page.body }} alone would auto-escape any HTML markup stored inside page.body, turning real tags like

into visible, literal text (<p>) on the rendered page instead of actually being interpreted as HTML - not what's wanted, since page.body genuinely stores real HTML content that needs to render as such. WHY |safe FIXES THAT ------------------------------ |safe disables Django's default auto-escaping for that specific output, allowing the stored HTML to render as actual markup rather than escaped text. WHY THIS SPECIFIC USE IS CONSIDERED ACCEPTABLE ------------------------------ Per this chapter, |safe is only appropriate here because of exactly where page.body's content comes from - it's written exclusively by the authenticated site admin (Chapter 9's own admin authentication), never submitted directly by an anonymous visitor through a public form. Applying |safe to content that a random visitor could actually type in and submit would reopen the exact cross-site-scripting (XSS) risk that Django's own auto-escaping exists specifically to prevent - the safety of |safe here depends entirely on trusting the source of the data, not on the filter itself being inherently harmless. WHY THIS WORKS AS AN ANSWER ------------------------------ It correctly explains what |safe does (disables auto-escaping) and why plain output would be wrong here (it would escape real HTML into visible text), and correctly identifies the trusted-admin-only source of page.body as the specific reason this particular use of |safe doesn't reintroduce an XSS risk.