Learn the vocabulary of an attacker's script executing in a victim's browser as trusted code.
0 / 5 completed
1 / 5
At standup, a dev mentions an attacker's script being injected into a page and then executed in a victim's browser as if it were part of the trusted site's own code, because user-supplied input was rendered without proper escaping. What is this vulnerability called?
Cross-site scripting, or XSS, injects an attacker's script into a page so it executes in a victim's browser with the same trust and access as the site's own legitimate code, typically because user-supplied input was rendered into the page's HTML without being properly escaped first. SQL injection instead targets a database query's syntax, a different vulnerability class entirely, even though both stem from the same root cause of untrusted input being treated as executable syntax. This browser-side script execution is what lets XSS steal session cookies, hijack an account, or perform actions on the victim's behalf.
2 / 5
During a design review, the team requires every piece of user-supplied content to be HTML-escaped before it's inserted into a page's markup, converting characters like '<' into a safe encoded form. Which capability supports this?
HTML escaping ensures user-supplied text renders as plain visible text rather than being interpreted as executable HTML or script tags, since converting a character like '<' into its encoded form prevents the browser from treating it as the start of a new tag. Rendering user input directly with no escaping leaves the browser with no way to tell trusted site markup apart from untrusted user content, which is exactly the gap XSS exploits. This escaping-by-default approach is why most modern templating frameworks automatically escape output unless a developer explicitly opts out.
3 / 5
In a code review, a dev notices a component intentionally bypasses the framework's automatic escaping to render a piece of user-supplied text as raw HTML, so that any formatting tags the user typed will actually render. What does this represent?
This is a deliberately reintroduced XSS risk, since bypassing automatic escaping to let a user's formatting tags render also lets an injected script tag, or an event-handler attribute, execute exactly the same way any other markup would. A parameterized query is an unrelated defense from the SQL injection domain, not the XSS domain. This is exactly why any raw-HTML rendering path needs its own dedicated sanitization step, allowlisting only genuinely safe tags and attributes, rather than trusting the user's input to only ever contain harmless formatting.
4 / 5
An incident report shows an attacker's comment on a public page contained a script tag that executed in every visitor's browser and silently exfiltrated their session cookie, because the comment text was rendered as raw HTML with no escaping or sanitization applied. What practice would prevent this?
Escaping user-supplied text by default, or running any content that must support raw HTML through a dedicated sanitizer that strips dangerous tags and attributes, ensures an injected script tag in a comment can never actually execute in another visitor's browser. Continuing to render comment text as raw HTML with no escaping or sanitization at all is exactly what let the attacker's script run and exfiltrate cookies from every visitor in this incident. This escape-or-sanitize requirement is a baseline defense for any feature that renders user-generated content back to other users.
5 / 5
During a PR review, a teammate asks why the team runs user-generated HTML content through a dedicated sanitization library instead of just trusting a simple blocklist that strips out the literal string 'script' before rendering. What is the reasoning?
An attacker has many ways to get script to execute beyond a literal script tag, including an event-handler attribute like onerror on an image tag, or a javascript: URL in a link's href, none of which a blocklist searching only for the word 'script' would catch. A proper sanitizer instead allowlists a known-safe set of tags and attributes, rejecting or stripping anything not explicitly permitted, which is fundamentally more robust than trying to enumerate every dangerous pattern in advance. The tradeoff is the added dependency and configuration effort of a full sanitization library compared to a naive blocklist, but that tradeoff is well worth it given how easily a blocklist is bypassed.