flawopen.com/Cross-Site Scripting/JavaScript
Imagine a guestbook where visitors write a public note. Stored XSS is like someone writing a note that isn't just text — it's a hidden trick that makes the guestbook page itself start doing things, like stealing the next visitor's login session, the moment anyone opens the page to read it.
Cross-site scripting happens when untrusted input is rendered into a page without proper output encoding. In JavaScript, the most direct route is element.innerHTML — assigning a string to it parses that string as HTML, including any <script> tags or event-handler attributes it contains.
In 2005, an 19-year-old user exploited a stored XSS flaw on MySpace to create the "Samy" worm — a script that added itself to every profile that viewed it, infecting over a million profiles within about 20 hours and forcing MySpace offline to contain it. It remains one of the most-cited demonstrations of how quickly stored XSS can self-propagate.
Source: widely documented in security industry retrospectives — see References below.// comment text parsed as HTML
function renderComment(el, comment) {
el.innerHTML =
`<p>${comment}</p>`;
}
// comment text inserted as plain text
function renderComment(el, comment) {
const p = document.createElement('p');
p.textContent = comment;
el.appendChild(p);
}
textContent inserts a string as literal text — the browser never parses it as markup, so a <script> tag inside comment is displayed as visible characters, not executed. innerHTML can't offer this guarantee, because parsing the string as HTML is exactly what it's designed to do.
JSX expressions like {comment} are escaped automatically. dangerouslySetInnerHTML exists specifically to opt out of that — the name is a deliberate warning, and it should be treated as one.
$(el).html(comment) has the exact same parsing behavior as el.innerHTML = comment — jQuery adds no protection here, despite feeling like a "safer" abstraction.
document.write(userInput) and setting location.href or an href/src attribute from unvalidated input (including a javascript: URI) are both real XSS sinks that don't involve innerHTML at all.
True for standard template/JSX interpolation — false for explicit raw-HTML escape hatches (dangerouslySetInnerHTML, Vue's v-html).
Any value rendered into the DOM counts — a URL query parameter echoed into a search results header, a filename shown after upload, a value read from localStorage that another script wrote.
grep -rn "\.innerHTML\s*=" --include="*.js" --include="*.ts" .
grep -rn "dangerouslySetInnerHTML\|v-html" --include="*.jsx" --include="*.tsx" --include="*.vue" .
grep -rn "document.write(" --include="*.js" .
Same underlying shape — untrusted data mixed into a command's structure without encoding — but the target and damage differ: SQL injection targets the database, XSS targets other users' browsers.
Yes, when the sanitizer runs on the untrusted string immediately before assignment and is kept up to date — the risk returns if sanitization is skipped for any code path or the library is misconfigured to allow script-bearing tags/attributes.