What Is XSS?

At a glance

XSS commonly results from unsafe input handling, output encoding or DOM operations. CSP can restrict some exploit paths but cannot replace code-level fixes.

When untrusted content becomes page script

Cross-Site Scripting occurs when an application places untrusted data into HTML, attributes, URLs, CSS or JavaScript without context-appropriate handling. The script executes in the victim's browser under the target origin and may read page data, act as the user or alter the interface.

Reflected XSS incorporates data from the current request; stored XSS saves malicious content for later visitors; DOM-based XSS occurs when frontend code sends untrusted data to dangerous browser APIs. Their entry points and persistence differ, but all involve data flowing from a source to an executable sink.

From input sources to execution sinks

• Sources include URL parameters, forms, rich text, messages, third-party APIs, postMessage and local storage. Traditional input boxes are only part of the surface.
• Output encoding must match HTML text, attributes, JavaScript strings or URLs. A universal character-replacement rule cannot protect every syntax boundary.
• Sinks such as innerHTML, document.write, eval and dynamic script URLs can interpret data as code. Safe DOM APIs and automatic template escaping reduce exposure.
• HttpOnly restricts direct script access to a cookie. CSP and Trusted Types narrow exploitation paths, but none replaces repair of the underlying data-flow flaw.

Why rich text and frameworks need special care

Rich-text features deliberately permit some HTML, so encoding everything is not sufficient. Use a maintained sanitizer and strict allowlist, considering SVG, MathML, URL schemes and browser parsing differences. Recombining sanitized output or moving it into another parsing context can reintroduce danger.

Modern frameworks escape ordinary template values by default, but escape bypasses, server rendering, third-party components and direct DOM access can still introduce XSS. Review actual data flows rather than assuming React, Vue or CSP makes a site immune.

Practical use and interpretation

Public responses reveal defensive clues such as CSP, cookies and scripts. Missing CSP cannot establish XSS. Stronger evidence requires a specific input reliably reaching an executable context.

Distinguish a missing protective layer from a confirmed injection flaw. With insufficient evidence, vulnerability status remains unknown. Potential impact depends on session privileges, accessible data and triggering conditions.

Points to consider

Missing CSP means one browser-side protection is absent; it does not prove an XSS vulnerability.

Frequently asked questions

Can CSP completely stop XSS?

No. Strong policies restrict many exploit paths, but policy errors, permitted sources and application logic may allow bypasses. Fix the root cause.

Can automatically escaping frameworks still have XSS?

Yes. Escape-bypass APIs, dangerous DOM operations, rich text, third-party components and server templates can introduce it.

Does HttpOnly prevent XSS?

It blocks direct script reads of that cookie, but injected script may still perform actions as the user or read other page data.