EXERCISE 2 — Grepping a framework codebase for XSS
===================================================

WHAT TO GREP FOR:

  Framework escape hatches (auto-escaping OFF -> must sanitize):
    React:    dangerouslySetInnerHTML
    Vue:      v-html
    Angular:  [innerHTML] , bypassSecurityTrustHtml , bypassSecurityTrustUrl ,
              bypassSecurityTrustResourceUrl , bypassSecurityTrustScript ,
              bypassSecurityTrustStyle
    Svelte:   {@html
    Lit/others: unsafeHTML , unsafeSVG

  Raw DOM sinks (framework doesn't protect these at all):
    .innerHTML =        .outerHTML =
    document.write(     document.writeln(
    insertAdjacentHTML(
    eval(   new Function(   setTimeout("..."   setInterval("..."
    location = / location.href = / .src = / .href =   (with untrusted data)
    el.setAttribute('href'/'src', untrusted)   (javascript: scheme)
    jQuery: .html(  $(untrusted)   .append(untrustedHTMLstring)

  SSR / template-injection smells:
    server-side template strings interpolating user data into HTML or into a
    <script> JSON island; dynamic template compilation from user input.

WHY XSS REVIEW CONCENTRATES ON THESE (not every binding):
  - In React/Vue/Angular, ORDINARY interpolation ({x} / {{ x }}) is
    AUTO-ESCAPED and therefore safe by default. The overwhelming majority of
    template bindings cannot cause XSS because the framework encodes them for
    you (Chapter 6 done automatically).
  - That means the dangerous surface is NOT "every place data is shown" (the
    old, exhausting problem) but specifically the places where someone
    EXPLICITLY OPTED OUT of auto-escaping (the hatches) or stepped OUTSIDE the
    framework (raw DOM sinks). Those are greppable, finite markers.
  - So the audit reduces to: find every hatch/sink, and for each confirm the
    input is either trusted/constant or sanitized (DOMPurify) / scheme-checked.
    Far more tractable than auditing all output.

ONE NON-innerHTML SINK AUTO-ESCAPING DOESN'T COVER:
  - URL BINDINGS. Binding user-controlled data into an href/src (e.g.
    <a [href]="userUrl"> in Angular, <a href={userUrl}> in React) is NOT made
    safe by text auto-escaping, because the danger is the URL SCHEME, not HTML
    characters. A value like "javascript:alert(document.cookie)" has no
    HTML-special chars to escape, yet executes on click.
    -> Frameworks block SOME schemes (Angular sanitizes URLs; React warns/
       blocks javascript: in newer versions), but you should still VALIDATE
       the scheme against an allowlist (http/https/mailto) for untrusted URLs.
  - (Other uncovered areas: dynamic/spread props, SSR-injected JSON, and
    template injection.)

PRACTICAL CHECKLIST PER HIT:
  Is the input constant/trusted?  -> ok.
  Is it user-controllable?        -> sanitize (HTML sinks) or scheme-validate
                                     (URL sinks); otherwise it's an XSS bug.