---
{
  "title": "Cross-site scripting",
  "summary": "Untrusted content can become executable code in another user’s browser.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    8
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Web Security Testing Guide",
      "url": "https://owasp.org/www-project-web-security-testing-guide/"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Cross-site scripting occurs when untrusted content is handled in a way that allows browser-side code execution in an application context. Reflected, stored, and DOM-based cases describe different paths. Defenses include context-appropriate output encoding, safe rendering APIs, and sanitization where rich content is required. Content Security Policy can add a layer but does not replace correct handling. Demonstrations belong in authorized labs.

## In practice

A note renderer displays a submitted string as text instead of inserting it into an unsafe HTML execution context.

## A common misunderstanding

One encoding rule is not safe for every HTML, attribute, URL, JavaScript, or CSS context.

## Check your understanding

What is the central defensive distinction?

**Think it through:** Treat untrusted content as data, and use safe APIs or appropriate encoding for its actual output context.

## Follow content into the browser

A fictional community site displays learner biographies in a profile, a search result, and a moderator dashboard. The same biography reaches three rendering paths. A safe profile renderer does not establish that the dashboard is safe, especially if it uses an older rich-text component. Review the final browser operation at every destination rather than assuming a single input filter protects the whole journey.

Stored XSS describes content retained for later display. Reflected XSS involves content returned in a response associated with a request. DOM-based XSS concerns unsafe client-side handling. These descriptions can overlap; they help locate the data flow rather than providing mutually exclusive labels for every application. What matters for remediation is identifying the source, transformation, and unsafe rendering operation.

The effect is broader than reading a cookie. Browser code running in the application's origin may interact with page data or make permitted authenticated requests. An HttpOnly cookie limits direct script access to that cookie, but does not make arbitrary script execution harmless. Authorization and sensitive-operation confirmation still matter.

## Demonstrate text handling safely

In a local sample page, submit a harmless string containing angle brackets and inspect whether it appears as literal text or becomes an element. Compare a framework's ordinary text rendering with an explicitly unsafe HTML insertion feature. Explain why the product would need a sanitizer if it intentionally supports formatted biographies.

A good finding names the affected renderer and who can supply the content. Include whether another user must visit a page, whether the content persists, and the permissions available in that context. Retest every affected display location after the fix. The lesson is to preserve a clear boundary between user content and application behavior throughout rendering.

## Keep exploring

- [[injection]]
- [[web-architecture]]
- [[dvwa]]
- [[sessions-and-cookies]]