🖥️ WSTG-CLNT: Client-side Testing

OWASP Web Security Testing Guide v4.2

By FixTheVuln Team Sources: OWASP WSTG v4.2
← OWASP WSTG Guide

Client-side vulnerabilities execute in the context of the user's browser and exploit the trust relationship between the browser and the web application. As modern applications shift more logic to the client side through JavaScript frameworks and single-page applications, the attack surface on the client has grown significantly. This category covers 13 tests ranging from DOM-based cross-site scripting and HTML injection to clickjacking, WebSocket testing, and browser storage security. These vulnerabilities are particularly relevant for modern JavaScript-heavy applications where client-side routing, template rendering, and data processing create new attack vectors that traditional server-side testing misses. For security testers, understanding the browser security model and same-origin policy is essential for finding these client-side vulnerabilities.

Difficulty: Intermediate 13 test cases

OWASP Top 10 Mapping

This testing category relates to the following OWASP Top 10 2021 categories:

A03A01

Quick Reference

Test ID Name CWEs Difficulty
WSTG-CLNT-01DOM-Based XSSCWE-79Intermediate
WSTG-CLNT-02JavaScript Execution TestingCWE-79Intermediate
WSTG-CLNT-03HTML InjectionCWE-79Intermediate
WSTG-CLNT-04Client-side URL RedirectCWE-601Intermediate
WSTG-CLNT-05CSS InjectionCWE-79Intermediate
WSTG-CLNT-06Resource ManipulationCWE-829Intermediate
WSTG-CLNT-07CORS TestingCWE-346, CWE-942Intermediate
WSTG-CLNT-08Cross Site FlashingCWE-79Intermediate
WSTG-CLNT-09Clickjacking TestingCWE-1021Intermediate
WSTG-CLNT-10WebSocket TestingCWE-346Intermediate
WSTG-CLNT-11Web Messaging TestingCWE-346Intermediate
WSTG-CLNT-12Browser Storage TestingCWE-922Intermediate
WSTG-CLNT-13XSSI TestingCWE-200, CWE-346Intermediate

Detailed Test Cases

WSTG-CLNT-01: DOM-Based XSS

Intermediate

DOM-based XSS testing checks whether client-side JavaScript reads data from attacker-controllable sources (URL hash, document.referrer, postMessage) and writes it to dangerous sinks (innerHTML, eval, document.write) without proper sanitization. This type of XSS occurs entirely in the browser.

Why it matters: DOM-based XSS is increasingly common in modern single-page applications and is invisible to server-side security controls because the payload never leaves the browser. Web application firewalls cannot detect or block DOM-based XSS, making client-side testing essential.

What to Check

  • Identify JavaScript sources that read from URL fragments, query parameters, or document properties
  • Map dangerous sinks in JavaScript (innerHTML, eval, document.write, jQuery.html())
  • Test if data flows from sources to sinks without sanitization
  • Check for DOM XSS in client-side routing and template rendering
  • Test postMessage handlers for origin validation and safe data handling
Tools: Burp Suite DOM Invader Browser Developer Tools DOMPurify testing Semgrep
CWE-79

WSTG-CLNT-02: JavaScript Execution Testing

Intermediate

This test checks whether an attacker can inject and execute JavaScript through the application's client-side processing. It focuses on contexts where user input is processed by JavaScript code and may be executed as code rather than treated as data.

Why it matters: JavaScript execution vulnerabilities allow attackers to run arbitrary code in the victim's browser context, enabling session hijacking, data theft, keylogging, and actions on behalf of the user. As applications rely more on client-side JavaScript, these attack vectors expand.

What to Check

  • Test for JavaScript injection through URL parameters processed by client-side code
  • Check for use of eval(), Function(), setTimeout/setInterval with string arguments
  • Test for injection through JavaScript template literals and string interpolation
  • Verify that user-controlled data is not used in dynamically generated script content
  • Check for unsafe JavaScript URL handling (javascript: protocol in links)
Tools: Burp Suite Browser Developer Tools ESLint security rules
CWE-79

WSTG-CLNT-03: HTML Injection

Intermediate

HTML injection testing checks whether user input can be used to inject arbitrary HTML content into the page. While similar to XSS, HTML injection focuses on modifying page structure and content (defacement, phishing forms) even when script execution is prevented by Content Security Policy.

Why it matters: HTML injection can be used for phishing attacks by injecting fake login forms, for content spoofing to damage reputation, and for social engineering by modifying page content. Even when CSP blocks script execution, injected HTML can still manipulate what users see and interact with.

What to Check

  • Test input fields for HTML tag injection that modifies page structure
  • Inject fake login forms to test phishing potential
  • Check if HTML injection can override or hide legitimate page content
  • Test for HTML injection in error messages, search results, and user profiles
  • Verify that Content-Security-Policy prevents escalation to script execution
Tools: Burp Suite Browser Developer Tools Manual testing
CWE-79

WSTG-CLNT-04: Client-side URL Redirect

Intermediate

This test checks whether the application performs client-side redirects based on user-controllable input without proper validation. Open redirects can be used in phishing attacks by making malicious URLs appear to originate from the trusted application domain.

Why it matters: Open redirects allow attackers to create convincing phishing URLs using the trusted application's domain. Victims see the legitimate domain in the link and trust it, but are redirected to a malicious site. This can also be chained with other vulnerabilities like OAuth token theft.

What to Check

  • Test URL parameters used for redirects (redirect, url, next, return, goto)
  • Check if JavaScript-based redirects validate the destination URL
  • Test for redirect bypass techniques (protocol-relative URLs, URL encoding, backslash)
  • Verify that redirect destinations are validated against a whitelist
  • Test for open redirect in OAuth flows and login return URLs
Tools: Burp Suite Browser Developer Tools Custom redirect payloads
CWE-601

WSTG-CLNT-05: CSS Injection

Intermediate

CSS injection testing checks whether user input can be injected into style contexts to manipulate page appearance, exfiltrate data through CSS selectors, or in older browsers, execute JavaScript through CSS expression() functions.

Why it matters: CSS injection can be used to exfiltrate sensitive data (like CSRF tokens) through attribute selectors and background URL techniques, phish users by overlaying fake content, and in some cases execute JavaScript. It is often overlooked because it seems less dangerous than XSS.

What to Check

  • Test if user input is reflected in style attributes or CSS blocks
  • Try injecting CSS that modifies page layout to overlay phishing content
  • Test CSS-based data exfiltration using attribute selectors and external URL references
  • Check for CSS injection in user-customizable themes or profile styling
  • Verify that user input in style contexts is properly sanitized
Tools: Burp Suite Browser Developer Tools Custom CSS payloads
CWE-79

WSTG-CLNT-06: Resource Manipulation

Intermediate

This test checks whether an attacker can manipulate the resources loaded by the client-side application, such as JavaScript files, CSS stylesheets, images, or iframes. This includes testing for subdomain takeover of CDN resources and manipulation of resource URLs through user input.

Why it matters: If an attacker can control which resources the application loads, they can inject malicious JavaScript through compromised or attacker-controlled resources. This is particularly relevant when applications load resources from user-controlled URLs or domains vulnerable to takeover.

What to Check

  • Identify user-controlled parameters that influence loaded resource URLs
  • Test if script, stylesheet, or iframe sources can be manipulated through URL parameters
  • Check for Subresource Integrity (SRI) on externally loaded scripts and stylesheets
  • Verify that CDN or third-party resource domains are not vulnerable to takeover
  • Test if the application validates resource origins before loading them
Tools: Burp Suite Browser Developer Tools Subresource Integrity checker
CWE-829

WSTG-CLNT-07: CORS Testing

Intermediate

Cross-Origin Resource Sharing (CORS) testing evaluates whether the application's CORS policy allows unauthorized cross-origin access to sensitive data. Overly permissive CORS configurations can allow any website to read authenticated responses from the application's API.

Why it matters: Misconfigured CORS can allow an attacker's website to make authenticated requests to the target application and read the responses, effectively bypassing the same-origin policy. This can expose user data, tokens, and sensitive API responses to malicious third-party sites.

What to Check

  • Test if Access-Control-Allow-Origin reflects the requesting origin without validation
  • Check if Access-Control-Allow-Credentials is true with a wildcard or reflected origin
  • Test for origin validation bypasses (null origin, subdomain matching, regex flaws)
  • Verify that CORS is not configured on endpoints that return sensitive data
  • Test pre-flight request handling for proper origin validation
Tools: Burp Suite curl Custom scripts CORS Misconfig Tester
CWE-346 CWE-942

WSTG-CLNT-08: Cross Site Flashing

Intermediate

Cross-site flashing testing checks whether Flash applications (SWF files) on the server can be exploited to execute JavaScript, perform cross-domain data theft, or redirect users. While Flash is largely deprecated, legacy SWF files may still be hosted and exploitable.

Why it matters: Legacy Flash files left on servers can still be exploited even though Flash Player is no longer supported by major browsers. Vulnerable SWF files can be used through specialized browser plugins or targeted environments where Flash is still available, and their mere presence indicates poor asset management.

What to Check

  • Search for SWF files hosted on the application server
  • Decompile discovered SWF files and review for user-controlled input handling
  • Test for FlashVars injection that can alter SWF behavior
  • Check if SWF files use ExternalInterface for JavaScript communication
  • Verify that any remaining SWF files are necessary and not exploitable
Tools: JPEXS Flash Decompiler SWFScan Burp Suite Google Dorking for SWF files
CWE-79

WSTG-CLNT-09: Clickjacking Testing

Intermediate

Clickjacking testing checks whether the application can be loaded in a frame or iframe by a malicious site. If so, an attacker can overlay the application with transparent layers to trick users into clicking on actions they did not intend, such as changing settings or making purchases.

Why it matters: Clickjacking can trick users into performing any action available in the application including changing account settings, making purchases, transferring funds, or granting permissions. Users believe they are interacting with the attacker's page but are actually clicking on the hidden target application.

What to Check

  • Check for X-Frame-Options header (DENY or SAMEORIGIN)
  • Verify Content-Security-Policy frame-ancestors directive
  • Test if the application can be loaded in an iframe from a different domain
  • Check for JavaScript frame-busting code and test if it can be bypassed
  • Create a proof-of-concept clickjacking page to demonstrate the vulnerability
Tools: Burp Suite Clickbandit Custom HTML PoC Browser Developer Tools
CWE-1021

WSTG-CLNT-10: WebSocket Testing

Intermediate

WebSocket testing evaluates the security of WebSocket connections used for real-time communication. This includes checking authentication, authorization, input validation, and origin validation on WebSocket endpoints, which often lack the security controls applied to HTTP endpoints.

Why it matters: WebSockets maintain persistent connections and often bypass HTTP security controls including WAFs, CSRF protections, and rate limiters. Since WebSocket messages are not bound by the same-origin policy after the initial handshake, insecure implementations can be exploited for cross-site attacks.

What to Check

  • Check if WebSocket connections validate the Origin header during the handshake
  • Test if authentication is required and verified for WebSocket connections
  • Verify that authorization is enforced on WebSocket messages, not just connection establishment
  • Test WebSocket message content for injection vulnerabilities (XSS, SQL injection)
  • Check if the WebSocket connection uses the secure wss:// protocol
Tools: Burp Suite OWASP ZAP WebSocket testing wscat Custom scripts
CWE-346

WSTG-CLNT-11: Web Messaging Testing

Intermediate

Web messaging testing checks the security of the postMessage API used for cross-origin communication between windows and iframes. Insecure implementations may accept messages from any origin or send sensitive data without verifying the recipient's origin.

Why it matters: The postMessage API allows cross-origin communication by design, making it a powerful but dangerous feature. If event listeners do not validate message origins, any website can send messages to the application. If the application sends sensitive data via postMessage without checking the target origin, data can be stolen.

What to Check

  • Identify all postMessage event listeners in the application's JavaScript
  • Check if event listeners validate the origin of incoming messages
  • Test if sending crafted messages from a different origin triggers application functionality
  • Verify that postMessage calls specify the target origin (not '*')
  • Check if postMessage data is used in dangerous sinks without sanitization
Tools: Browser Developer Tools Burp Suite Custom JavaScript PMHook
CWE-346

WSTG-CLNT-12: Browser Storage Testing

Intermediate

Browser storage testing examines what data the application stores in localStorage, sessionStorage, IndexedDB, and cookies. Sensitive data stored in browser storage is accessible to any JavaScript running on the same origin and may persist longer than intended.

Why it matters: Data in browser storage is accessible to any JavaScript on the same origin, making it vulnerable to XSS attacks. localStorage persists indefinitely unless explicitly cleared, meaning sensitive data like tokens or personal information can be extracted long after the user session ends.

What to Check

  • Review localStorage and sessionStorage for sensitive data (tokens, PII, credentials)
  • Check if session tokens are stored in browser storage instead of httpOnly cookies
  • Verify that sensitive data is cleared when the user logs out
  • Check IndexedDB for cached sensitive data from API responses
  • Test if stored data is encrypted or if plaintext sensitive values are accessible
Tools: Browser Developer Tools Burp Suite StorageExplorer extensions
CWE-922

WSTG-CLNT-13: XSSI Testing

Intermediate

Cross-Site Script Inclusion (XSSI) testing checks whether sensitive data is exposed through JavaScript files or JSONP endpoints that can be included by an attacker's page. If authenticated JavaScript responses contain user-specific data, an attacker's page can read this data by including the script.

Why it matters: XSSI allows an attacker's website to steal sensitive data by including authenticated JavaScript endpoints as script sources. Because script inclusion is not restricted by the same-origin policy, the attacker's page can read any data embedded in the JavaScript response, including CSRF tokens, user data, and API keys.

What to Check

  • Identify JavaScript endpoints that return different content based on authentication
  • Check for JSONP endpoints that include sensitive user data in the callback
  • Test if authenticated JavaScript responses contain user-specific information
  • Verify that Content-Type headers prevent script inclusion of non-JavaScript responses
  • Check if the X-Content-Type-Options: nosniff header prevents MIME type sniffing
Tools: Burp Suite Browser Developer Tools Custom HTML PoC
CWE-200 CWE-346

Relevant Certifications

The following certifications cover client-side testing concepts:

CEHOSCPGWAPT

Frequently Asked Questions

What is the difference between reflected/stored XSS and DOM-based XSS?

Reflected and stored XSS involve the server including malicious input in the HTTP response. DOM-based XSS occurs entirely in the browser when client-side JavaScript reads data from an attacker-controllable source (like the URL fragment) and writes it to a dangerous sink (like innerHTML) without sanitization. DOM-based XSS never reaches the server, making it invisible to server-side security controls and WAFs.

What is clickjacking and how does it affect users?

Clickjacking (UI redressing) tricks users into clicking on something different from what they perceive by loading the target application in a transparent iframe overlaid on a malicious page. The user thinks they are clicking buttons on the attacker's page but are actually interacting with the hidden target application. This can lead to unintended actions like changing settings, making purchases, or granting permissions.

Why is browser storage (localStorage, sessionStorage) a security concern?

Browser storage is accessible to any JavaScript running on the same origin, which means XSS vulnerabilities can read all stored data. Storing sensitive data like session tokens or personal information in localStorage is risky because it persists even after the browser is closed and has no equivalent of cookie security flags (HttpOnly, Secure). Sensitive data should use httpOnly cookies rather than browser storage.

CyberFolio

Mastering web security testing? Showcase your skills.

Build a free, shareable cybersecurity portfolio that highlights your certifications, projects, and skills.

Build Your Portfolio →

Related WSTG Categories

WSTG-INFO
Information Gathering WSTG-CONF
Configuration and Deployment Management WSTG-IDNT
Identity Management WSTG-ATHN
Authentication Testing
← Back to Home ← All WSTG Categories