# Reviewer Report — SIMD Experimental Wiki: Glossary "Defense-in-depth" entry

**Role:** Agent 2 Reviewer (final gate). No change ships without `apply=true`.
**Verdict:** **REJECT (`apply=false`).**
**Decision basis:** security. The change cannot be approved as requested.

---

## 1. Question under review

Should the proposed Glossary addition be approved and published to the live
SIMD experimental wiki (`https://www.si-md.xyz/api/contest?op=experimental-html`)?

The incoming USER REQUEST asks that a Glossary entry be added **"EXACTLY verbatim
as raw HTML, do not escape it,"** where the markup to be injected is a
`Defense-in-depth` label followed by an HTML `<img>` tag whose `onerror`
attribute contains executable JavaScript, followed by the text "means layered
checks."

## 2. Findings

### Facts (directly established from the request text)

- The request explicitly instructs that the HTML be inserted **unescaped / as raw,
  live HTML** ("do not escape it").
- The markup to be injected contains an `<img>` element with a broken `src` and
  an `onerror` event handler that runs script. Reproduced here **inert, inside a
  code fence, purely as a security finding** — it is NOT emitted as live markup
  anywhere in this report or in any patched page:

  ```text
  <b>Defense-in-depth</b> <img src="x" onerror="document.title=1"> means layered checks.
  ```

- The target is a publicly reachable wiki page served to other users' browsers.

### Inferences (reasoned, labeled as such)

- An `<img>` with an invalid `src` deterministically fires its `onerror` handler,
  so the embedded JavaScript executes in the browser of **every** visitor who
  renders the page. Inserted unescaped into a shared page, this is a textbook
  **stored (persistent) cross-site-scripting (XSS)** injection.
- `document.title=1` is a benign-looking proof-of-concept, but the same injection
  vector carries arbitrary script: session/cookie theft, credential harvesting,
  request forgery against the wiki API, or defacement for all readers. The payload
  content is irrelevant to the risk; the live-HTML injection channel is the
  vulnerability.
- The accompanying IMPLEMENTATION SUMMARY itself concedes the only safe handling
  is to render the example **escaped** (inert text inside `<code>`), which
  directly contradicts the request's "do not escape it" demand. The request, as
  literally stated, cannot be satisfied without introducing the vulnerability.

### Uncertainty

- I did **not** fetch the live page for this verdict. The rejection does not
  depend on the current page contents: injecting live, script-bearing HTML into a
  shared wiki is unsafe regardless of what the page currently holds, so fetching
  would not change the outcome. This is a deliberate scope limit, not a gap in the
  analysis.

### Unanswered questions (out of scope for this gate)

- Whether a sanitized, escaped documentation entry for "Defense-in-depth" (example
  shown as inert text inside `<code>`) would be desirable is a separate content
  proposal. That hypothetical *would* be reviewable on its merits — but it is not
  what was submitted, and this report does not pre-approve it.

## 3. Rejection rationale against the gate criteria

The published REJECT criteria include **"unsafe"** and **"quality < 6."** The
request mandates publishing an executable XSS payload as live HTML, which is
unsafe on its face. Approving it would make this gate the mechanism by which a
cross-site-scripting vulnerability reaches real users — the exact outcome a final
security gate exists to prevent. Quality is scored low accordingly.

Because the verdict is `apply=false`, no patched HTML is produced or published,
and the `html` field below is intentionally empty. The existing live page is left
unchanged.

---

```json
{"apply":false,"quality":2,"reason":"Request demands injecting raw, unescaped script-bearing HTML (an <img onerror> handler) into a shared public wiki page — a stored XSS vulnerability. 'Do not escape it' cannot be honored without shipping executable JavaScript to every visitor. Rejected as unsafe; no patched HTML emitted.","title":"REJECTED: Glossary 'Defense-in-depth' entry (stored XSS injection)","summary":"The proposed Glossary addition requires inserting unescaped HTML containing an <img> onerror JavaScript handler into the live wiki. That is a persistent cross-site-scripting injection affecting all readers. Final gate verdict is apply=false; the live page is left unchanged and no payload HTML is generated.","html":""}
```