What is Cross-Site Scripting?

Cross-Site Scripting, abbreviated XSS, occurs when a web application places untrusted data into a page without encoding it for the correct output context. The browser then interprets that data as active HTML or JavaScript. The code runs with the origin and permissions of the affected website.

Reflected XSS returns the payload in the immediate response, stored XSS saves it for later visitors, and DOM-based XSS is created by unsafe client-side code. Attackers may manipulate page content, perform actions as the victim or access data available to JavaScript. HttpOnly cookies reduce one consequence but do not prevent XSS.

How can XSS be prevented?

• - Use automatic, context-aware output encoding and avoid raw HTML rendering.
• - Sanitize HTML with a proven allowlist when rich text is genuinely required.
• - Avoid dangerous browser APIs such as `innerHTML` for untrusted content.
• - Deploy a restrictive Content Security Policy as an additional layer, not the primary fix.

Code examples: server-side and DOM-based XSS

Vulnerable Blade template:

<!-- Renders external HTML without filtering -->
{!! $comment !!}

Safe text output:

<!-- Blade contextually encodes HTML characters -->
{{ $comment }}

DOM-based – vulnerable and safe:

// Vulnerable: the browser interprets the value as HTML
output.innerHTML = new URLSearchParams(location.search).get('name');

// Safe when text is all that is required
output.textContent = new URLSearchParams(location.search).get('name');

When rich text is required, textContent is insufficient; use a maintained HTML sanitizer with a narrow allowlist. URL, attribute and JavaScript contexts each require their own rules.

Why does the output context matter?

HTML text, attributes, URLs, CSS and JavaScript strings follow different parsing rules. Encoding that is safe in one context may be unsafe in another. The safest design keeps untrusted data out of executable contexts altogether.

Reflected, stored and DOM-based XSS

Reflected XSS occurs when data from the current request is inserted into the response without the right protection. Stored XSS persists the payload in a profile, comment or ticket and serves it to other users later. DOM-based XSS happens in the browser when JavaScript passes untrusted data to a dangerous DOM sink such as innerHTML. The categories may overlap; the important part is the data flow from its source to an executable context.

What can an XSS attack do?

The script runs in the security context of the affected site. It can alter visible content, perform actions as the signed-in user, manipulate forms or send readable data to an external server. An HttpOnly cookie cannot be read directly by JavaScript, but it does not stop requests made with the existing session. Stored XSS in a support or administration view is therefore particularly serious.

How is XSS tested?

A test follows input through server templates and client-side code to every output location. HTML text, attributes, URLs, JavaScript, CSS and DOM sinks require separate analysis. A simple marker only demonstrates reflection; a controlled context-specific proof confirms execution. Source review and browser instrumentation expose data flows that a scanner misses because they depend on complex interaction or delayed processing.

What role do CSP and cookie attributes play?

A strict Content Security Policy can block many payloads and make exploitation harder. It is a second line of defence, not a replacement for contextual encoding and safe DOM APIs. HttpOnly, SameSite and Secure attributes limit particular consequences. Together these controls reduce impact while the underlying XSS flaw still has to be removed from the output path.