Cross-Site Scripting
Cross-Site Scripting, or XSS, happens when attacker-controlled data runs as browser code on a trusted site.
Another example
A forum post contains `<img alt="" onerror=…>`. A safe template inserts it as text, cleans the small allowed set of Markdown, blocks harmful URLs, and enforces CSP. A regression test checks HTML, attribute, URL, CSS, and JavaScript contexts separately.
Main parts
- 01Untrusted source
- 02Interpreter context and unsafe sink
- 03Encoding/sanitization boundary
Use it when
Encode untrusted output for its exact context and use safe DOM APIs. If HTML is allowed, clean it with a strict allowlist and add CSP as another defense.
Do not use it when
One escape function does not fit every context. Input checks or CSP alone cannot make every unsafe place safe.
Name used in code
contextual output encoding + safe sinks + HTML sanitization + CSP Before you ship
Work only within an explicitly authorized and isolated defense test. Check the trust boundary, inert regression case, mitigation, and handling of secrets and personal data. Check redacted detection signals, safe failure, incident owner, recovery, and rollback. Never test a real target.
Outcome: Assess and mitigate the risk from Cross-Site Scripting. Do not implement, enable, or use the attack. User context: A forum post contains `<img alt="" onerror=…>`. A safe template inserts it as text, cleans the small allowed set of Markdown, blocks harmful URLs, and enforces CSP. A regression test checks HTML, attribute, URL, CSS, and JavaScript contexts separately. Risk or control to address: Cross-Site Scripting. Why it applies: Encode untrusted output for its exact context and use safe DOM APIs. If HTML is allowed, clean it with a strict allowlist and add CSP as another defense. Classification boundary: One escape function does not fit every context. Input checks or CSP alone cannot make every unsafe place safe. Safety requirements: Test only in an isolated space with explicit permission. Use inert, harmless inputs. Protect secrets and personal data. Name the trust boundary and record the mitigation. Operational safeguards: Set up detection and logs that hide sensitive data. Name the incident owner. Define a safe failure mode and rollback before release. Acceptance criteria: A defensive regression test fails before the mitigation and passes after it. No real target, secret, or personal data is used. Monitoring and rollback are verified. Evidence and limits (evidence boundary): It is official for that source. Other platforms or teams may use the term in another way. Unknowns to confirm: Authorized scope, affected assets, data class, threat actor, incident owner, and rollback limits.
Check this request
Review the current use of Cross-Site Scripting. Definition: Cross-Site Scripting, or XSS, happens when attacker-controlled data runs as browser code on a trusted site. Release checks: Work only within an explicitly authorized and isolated defense test. Check the trust boundary, inert regression case, mitigation, and handling of secrets and personal data. Check redacted detection signals, safe failure, incident owner, recovery, and rollback. Never test a real target. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.