Cross-site scripting

02Where the string lands

The owned source gets two paragraphs by their id values, literal and parsed. It puts the same string into each through a different property. In <b>tea</b>, <b> opens a bold element and </b> closes it. textContent keeps those characters visible; innerHTML interprets them as tags. The <i>lane</i> activity uses italic tags instead.

Use textContent for untrusted text in this paragraph. If an application intentionally supports HTML, it needs suitable sanitization and controls for that context. Output encoding must fit the specific insertion context; HTML text escaping is not a universal answer for script or URL contexts. A Content Security Policy can reduce some consequences but does not replace safe handling at the sink.

Reflected XSS returns submitted input in the response to the same interaction. Stored XSS saves the input and later serves it to a reader. DOM-based XSS concerns a client-side script handling data unsafely; these descriptions can overlap. Sanitization removes or rewrites unsafe markup according to a policy when HTML is intentionally allowed. Content Security Policy is a browser-enforced set of restrictions on resources and code execution.

03Predict the lane string

Read the evidence before comparing with the activity rubric. Do not open the file in a browser for this checkpoint.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Desk note</title>
</head>
<body>
  <p id="literal"></p>
  <p id="parsed"></p>
  <script>
    var note = "<b>tea</b>";
    document.getElementById("literal").textContent = note;
    document.getElementById("parsed").innerHTML = note;
  </script>
</body>
</html>

Predicted display.

The string in the script is the ten characters < b > t e a < / b > with the letters of tea between the tags.
textContent assignment: the literal paragraph shows those characters, including the angle brackets.
innerHTML assignment: a browser that parses HTML would show the word tea in bold and would not show the tags.
That parsed display was not observed.

Activity string, different from the script: <i>lane</i>
Predicted literal display: the characters <i>lane</i>
Predicted parsed display: the word lane in italic.

1. Read the activity string on the text card. Write the characters.
2. Write the predicted literal display and the predicted parsed display.
3. Check: the literal display is the characters <i>lane</i>. The parsed display would be the word lane in italic, and it was not observed. The tea string is the worked example.
4. Stop. Do not paste a third-party script into the page.

04Optional challenge

From the two words reflected and stored, say which one fits a note that was saved and later shown, and which fits a note that comes back only in this response. The rubric is those two placements. About ten minutes.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

String value: <b>cedar</b>
P: paragraph.textContent receives that string.
Q: paragraph.innerHTML receives that string.
Rule: textContent keeps characters as text; innerHTML parses HTML markup.
No browser rendering or script execution was observed.

The product requirement is to display every caller character literally in a paragraph.
The handler currently assigns caller text to paragraph.innerHTML.
The application does not need user-authored HTML formatting.

06Explain your evidence

Optional written self-check: explain one decision using the supplied case. No tool run is required.

Check your explanation: predict both receiving properties on the same harmless string; locate the insertion boundary; choose the sink for literal text; distinguish predictions from observed rendering and avoid claiming arbitrary script execution.