Challenge 3: Escaping vs raw — Solution

<%= @bio %>
<%= raw(@bio) %>

# How each renders in the browser, given @bio = "<b>Bold</b> claim":
#
# <%= @bio %> renders as literal, visible text on the page:
#     <b>Bold</b> claim
#   The angle brackets are escaped to HTML entities (&lt;b&gt;) internally,
#   so the browser displays the tags themselves as plain text rather than
#   interpreting them -- nothing is bolded, the user sees the raw markup
#   characters.
#
# <%= raw(@bio) %> renders as actual, interpreted HTML:
#     Bold claim
#   with "Bold" genuinely bold, because raw() tells Rails to skip escaping
#   entirely and send the string straight to the browser as real markup.
#
# Which to use for genuinely untrusted, user-submitted content: <%= %>
# (plain, escaped) -- always. raw() should only ever be used for content
# you, the developer, generated or fully trust (values baked into the
# app), never for anything a user typed into a form. Using raw() on
# user-submitted content is exactly the XSS vulnerability the completed
# XSS security course covered -- a user could submit
# "<script>...</script>" instead of "<b>Bold</b>" and have it execute in
# every other visitor's browser.

=begin
Notes:
- This challenge deliberately uses safe example content ("<b>Bold</b>
  claim") to demonstrate the rendering difference clearly, but the
  chapter's real point is about untrusted input -- the same raw() call
  applied to a malicious <script> tag from a form submission would
  actually execute that script for anyone viewing the page.
- The default, <%= %>, being safe is exactly why Rails' escaping is
  described as "secure by default" rather than "secure if the developer
  remembers to escape."
=end