{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/cross-site-scripting","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/cross-site-scripting/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/cross-site-scripting/"},"term":{"en":"Cross-site scripting (XSS)","da":"Cross-site scripting (XSS)"},"aka":{"en":["XSS"],"da":["XSS"]},"domain":["security"],"cluster":"application-security","layer":"application","status":"current","era":2000,"summary":{"en":"An attack that smuggles a harmful script into a web page, so it runs in the browser of everyone who visits the page.","da":"Et angreb, der smugler et skadeligt script ind på en webside, så det kører i browseren hos alle, der besøger siden."},"body":{"formal":{"en":"A flaw in a web application that places untrusted input into its pages without making it safe first; the web browser then runs that input as code with the same rights as the site's own code, so it can read what the user sees and act in their name.","da":"En fejl i en webapplikation, der sætter input udefra ind i sine sider uden først at gøre det ufarligt; webbrowseren kører så inputtet som kode med samme rettigheder som sitets egen kode og kan dermed læse, hvad brugeren ser, og handle i brugerens navn."},"plain":{"en":"Like a notice board where someone pins up a note that, when read aloud, makes the reader hand over their house keys - the board itself never checks what is pinned to it.","da":"Som en opslagstavle, hvor nogen hænger en seddel op, der får den, der læser den højt, til at udlevere sine husnøgler - tavlen tjekker aldrig, hvad der bliver hængt op."},"inPractice":{"en":"An attacker posts a comment with a hidden script on a municipality's public consultation page; every resident who opens the page while logged in unknowingly hands the attacker their session.","da":"En angriber skriver en kommentar med et skjult script på en kommunes høringsside; hver borger, der åbner siden, mens vedkommende er logget ind, giver uden at vide det angriberen sin session."},"whyItMatters":{"en":"The harmful code runs inside a site the visitor trusts, so the browser gives it the visitor's session and data; it remains one of the most often reported flaws in web applications.","da":"Den skadelige kode kører inde på et site, som den besøgende stoler på, så browseren giver den adgang til den besøgendes session og data; det er fortsat en af de oftest rapporterede fejl i webapplikationer."}},"deepDive":{"en":"XSS is classified by where the payload lives and where it is turned into code. Reflected XSS echoes input from the current request (a search term, an error parameter) back into the response. Stored XSS persists the payload in the application's data (comments, profile fields, support tickets) and serves it to every viewer, which is why it scales best for the attacker; the 2005 Samy worm on MySpace spread to over a million profiles this way. DOM-based XSS never touches the server's HTML: client-side JavaScript reads an attacker-controlled source such as location.hash or postMessage data and writes it into a dangerous sink such as innerHTML, document.write, eval or a javascript: URL. Mutation XSS (mXSS) exploits the difference between how a sanitizer parses markup and how the browser re-parses it after serialisation.\n\nThe root defence is contextual output encoding: the same value needs different escaping in an HTML body, a quoted attribute, a JavaScript string, a CSS value or a URL, and HTML-entity encoding is not sufficient inside a script block or an event-handler attribute. Modern template engines and frameworks (React JSX, Angular, Razor, Thymeleaf) auto-escape by default, so real-world XSS concentrates in escape hatches such as dangerouslySetInnerHTML, bypassSecurityTrustHtml, v-html and raw string templates. When rich HTML must be accepted, it goes through an allowlist sanitizer such as DOMPurify rather than a hand-written regex.\n\nContent Security Policy is the main defence-in-depth layer. A strict CSP uses per-response nonces or hashes with 'strict-dynamic' and disallows inline event handlers, which blocks most injected scripts even when encoding has failed; domain allowlists are routinely bypassed through JSONP endpoints and script gadgets on allowed CDNs. Trusted Types, first shipped in Chromium-based browsers, make DOM sinks reject plain strings, which turns DOM XSS into a type error. HttpOnly cookies stop script from reading the session cookie but do not stop the script from making authenticated requests on the victim's behalf, so they limit rather than prevent the damage.\n\nXSS is catalogued as CWE-79. It was its own OWASP Top 10 category until 2017 (A7), was merged into Injection in 2021 (A03) and remains under Injection as A05 in the 2025 edition. Input validation helps with narrowly typed fields, but it cannot be the primary control, because many legitimate values (names such as O'Brien, free text, markup in a CMS) contain the characters that matter in some output context.","da":"XSS inddeles efter, hvor payloaden ligger, og hvor den bliver til kode. Reflekteret XSS sender input fra den aktuelle forespørgsel (et søgeord, en fejlparameter) tilbage i svaret. Lagret XSS gemmer payloaden i applikationens data (kommentarer, profilfelter, supportsager) og serverer den for alle, der ser siden, og skalerer derfor bedst for angriberen; Samy-ormen på MySpace i 2005 spredte sig på den måde til over en million profiler. DOM-baseret XSS rører aldrig serverens HTML: JavaScript i klienten læser en kilde, angriberen styrer, fx location.hash eller postMessage-data, og skriver den ind i en farlig sink som innerHTML, document.write, eval eller en javascript:-URL. Mutation XSS (mXSS) udnytter forskellen på, hvordan en sanitizer parser markup, og hvordan browseren parser den igen efter serialisering.\n\nGrundforsvaret er kontekstafhængig output-encoding: den samme værdi skal escapes forskelligt i HTML-brødtekst, i en attribut i anførselstegn, i en JavaScript-streng, i en CSS-værdi eller i en URL, og HTML-entity-encoding er ikke nok inde i en script-blok eller en event handler-attribut. Moderne templatemotorer og frameworks (React JSX, Angular, Razor, Thymeleaf) escaper automatisk, så XSS i praksis samler sig i nødudgangene som dangerouslySetInnerHTML, bypassSecurityTrustHtml, v-html og rå strengskabeloner. Skal der tages imod rig HTML, sendes den gennem en allowlist-baseret sanitizer som DOMPurify frem for et hjemmestrikket regulært udtryk.\n\nContent Security Policy er det vigtigste ekstra forsvarslag. En streng CSP bruger nonces eller hashes pr. svar sammen med 'strict-dynamic' og forbyder inline event handlers, hvilket blokerer de fleste injicerede scripts, selv når encodingen har svigtet; domænebaserede allowlists omgås jævnligt via JSONP-endpoints og script gadgets på tilladte CDN'er. Trusted Types, som først kom i Chromium-baserede browsere, får DOM-sinks til at afvise almindelige strenge, så DOM-XSS bliver til en typefejl. HttpOnly-cookies forhindrer script i at læse sessionscookien, men ikke i at sende autentificerede forespørgsler i offerets navn, så de begrænser skaden uden at forhindre den.\n\nXSS er katalogiseret som CWE-79. Det var en selvstændig kategori i OWASP Top 10 frem til 2017 (A7), blev lagt ind under Injection i 2021 (A03) og ligger stadig under Injection som A05 i 2025-udgaven. Inputvalidering hjælper på snævert typede felter, men kan ikke være den primære kontrol, fordi mange legitime værdier (navne som O'Brien, fritekst, markup i et CMS) indeholder netop de tegn, der betyder noget i en eller anden outputkontekst."},"edges":[{"type":"requires","to":"cs/web-browser","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/web-application","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"security/sql-injection","why":{"en":"Both abuse input the site trusts too much, but SQL injection attacks the database on the server, while XSS attacks the visitor's browser.","da":"Begge misbruger input, som sitet stoler for meget på, men SQL injection angriber databasen på serveren, mens XSS angriber den besøgendes browser."},"confidence":"high","strength":"primary"},{"type":"causes","to":"security/session-hijacking","why":{"en":"A script running in the page can read the session cookie and send it to the attacker.","da":"Et script, der kører på siden, kan læse sessionscookien og sende den til angriberen."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"security/owasp-top-10","why":{"en":"Since the 2021 edition it is counted under the list's Injection category, which in the 2025 edition is A05.","da":"Siden 2021-udgaven hører det under listens kategori Injection, som i 2025-udgaven er A05."},"confidence":"high","strength":"normal"}],"depth":6,"sources":[{"title":"OWASP - Cross Site Scripting (XSS)","url":"https://owasp.org/www-community/attacks/xss/","tier":"reference","publisher":"OWASP"},{"title":"OWASP Cheat Sheet Series - Cross Site Scripting Prevention","url":"https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html","tier":"reference","publisher":"OWASP"},{"title":"OWASP Top 10:2025 - A05 Injection","url":"https://owasp.org/Top10/2025/A05_2025-Injection/","tier":"reference","publisher":"OWASP"}],"draft":true}