Home / Attacks & tests / Client Side Testing
11 test cases
Client Side Testing
Client side testing examines code that runs in the visitor's browser and the boundaries the browser is asked to enforce. The server may be entirely correct and the application still be exploitable, because the decision that matters was taken after the response left the server.
What an attacker is trying to achieve
The attacker wants their code running in another user's browser, in the application's origin, where it inherits that user's session and everything the origin is trusted to do. Failing that, they want the browser to be persuaded to send data somewhere else, or to render the application inside a page they control.
Test cases
11 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
WEB-CLNT-01 DOM-Based Cross-Site Scripting
Objective — Determine whether client-side code takes attacker-controllable input and passes it to a sink that executes or renders it, without the server ever reflecting the value.
How it is tested — Identify sources the client reads — the URL and its fragment, storage, message events, referrer — and trace each through the bundles to the sinks it reaches. Submit markers through each source and observe the resulting DOM rather than the response body, since the response is identical in every case. Confirm execution in a browser, and include fragment-only payloads, which never reach the server at all.
Prerequisites — The client bundles, ideally unminified through source maps; a browser with a debugger; an authenticated session where sinks differ when logged in.
Indicators — Execution from a value that never appeared in a request the server saw; a source reaching a sink without sanitisation in the bundle; a fragment payload executing.
Coverage — WSTG-CLNT-01V5.3.3CWE-79
Depth — Manual The vulnerable path exists only at runtime in the browser; response-body scanning cannot see it.
WEB-CLNT-02 JavaScript Execution
Objective — Determine whether the application evaluates strings as code on the client, and whether any part of those strings can be influenced by input.
How it is tested — Search the bundles for dynamic evaluation constructs and for handlers assembled from concatenated strings. For each, trace whether any operand originates outside the code — from the URL, storage, a message, or a server response that carries user content. Submit markers into those origins and observe whether they are evaluated. Include configuration and feature-flag values delivered from the server, which are often interpolated into code.
Prerequisites — The client bundles; a browser debugger; the ability to influence the server-delivered values the client interpolates.
Indicators — A dynamic evaluation whose operand is externally influenced; a handler built by concatenation from user content; server-delivered configuration interpolated into executable context.
Coverage — WSTG-CLNT-02V5.2.4CWE-95
Depth — Manual Requires reading the client code; the request-response pair shows nothing.
WEB-CLNT-03 HTML and CSS Injection
Objective — Determine whether input can introduce markup or style into a page without achieving script execution, and whether that alone is enough to mislead or exfiltrate.
How it is tested — Submit markup and style fragments into fields whose script payloads are filtered, and establish what survives. Test whether injected markup can introduce form controls that submit elsewhere, overlay or relocate existing controls, or alter the text of a confirmation. Test whether injected style can select on attribute values and cause a request that discloses them, which extracts data without any script at all.
Prerequisites — A reflection or storage point where script is filtered but markup is not; a browser; a listener to receive style-triggered requests.
Indicators — Markup rendered rather than escaped; an injected control submitting to another destination; a confirmation's text altered; a style-triggered request disclosing an attribute value.
Coverage — WSTG-CLNT-03WSTG-CLNT-05V5.3.3CWE-80CWE-1021
Depth — Manual Scanners look for execution and treat surviving markup as harmless; judging whether it is harmless is the work.
WEB-CLNT-04 Client-Side URL Redirect
Objective — Determine whether the application can be made to send a visitor to a destination the caller chooses, lending the operator's domain to the attacker's page.
How it is tested — Identify every parameter carrying a destination — return, next, continue, callback and their equivalents in authentication flows. Substitute an external destination and observe whether the redirect occurs. Where a filter is present, test the forms that commonly defeat one: protocol-relative references, credential-style prefixes, hosts that merely begin or end with the allowed value, encoded separators, and redirects performed by client-side code rather than by a response header.
Prerequisites — A destination the tester controls; the parameter inventory; a browser to confirm client-side redirects.
Indicators — An external destination reached; a filter defeated by an alternative host form; a redirect performed by script from a value in the fragment.
Coverage — WSTG-CLNT-04V5.1.5CWE-601
Depth — Hybrid Simple cases automate; filter evasion and script-performed redirects are manual.
WEB-CLNT-05 Client-Side Resource Manipulation
Objective — Determine whether input controls which resource the client loads, allowing an attacker to introduce script, styles or content from a location they own into the application's origin.
How it is tested — Identify client-side code that builds a resource location from a value it reads — script and style sources, iframe destinations, worker and module locations, image and media sources. Substitute a location the tester controls and observe whether it is fetched and, more importantly, in what context it executes. Include locations assembled from server-supplied configuration.
Prerequisites — The client bundles; a host the tester controls; a browser; an authenticated session where the loaded resource inherits privilege.
Indicators — A tester-controlled location fetched by the client; script from that location executing in the application's origin; a worker or module loaded from outside.
Coverage — WSTG-CLNT-06V14.4.3CWE-829CWE-494
Depth — Manual The distinction that matters is the context the resource executes in, which requires observing the browser.
WEB-CLNT-06 Cross-Origin Resource Sharing
Objective — Determine whether the application's cross-origin policy allows a site the operator does not control to issue credentialed requests and read the responses.
How it is tested — Issue requests to authenticated endpoints with a range of origin values — unrelated hosts, prefix and suffix variants of the real origin, subdomains, and null — and record which are echoed as permitted and whether credentials are allowed alongside. Establish whether the policy is generated by reflecting the submitted origin, and whether it differs between endpoints. Confirm from a real second origin rather than by reading headers alone.
Prerequisites — An authenticated session; a second origin the tester controls; endpoints returning session-specific data.
Indicators — The submitted origin reflected without validation; credentials permitted with a permissive origin; a null origin accepted; a subdomain trusted that the operator does not fully control.
Coverage — WSTG-CLNT-07V14.5.3CWE-942CWE-346
Depth — Hybrid Header probing automates; proving a real cross-origin read requires a second origin.
WEB-CLNT-07 Cross-Site Flashing and Legacy Plugin Content
Objective — Determine whether legacy browser-plugin content remains served, and whether it or the policies supporting it still weaken the origin.
How it is tested — Search the application and its static assets for legacy plugin objects and the cross-domain policy files that accompany them. Where such content is served, establish what parameters it accepts and whether any reaches a navigation or scripting call. Regardless of whether current browsers still execute it, establish whether the permissive cross-domain policies left behind for it remain in place, since those continue to affect other clients.
Prerequisites — The static asset inventory; the policy files from configuration testing; no authenticated session required for most of it.
Indicators — Legacy plugin content still served; a permissive cross-domain policy retained for content no longer used; parameters reaching navigation or scripting calls within it.
Coverage — WSTG-CLNT-08WSTG-CONF-08V1.14.6CWE-942
Depth — Hybrid Discovery automates. The judgement is that a retired technology's permissive policy usually outlives the technology.
WEB-CLNT-08 Clickjacking and UI Redressing
Objective — Determine whether the application can be rendered inside a page the attacker controls, so that a victim's genuine interaction is captured by a different interface than the one they believe they are using.
How it is tested — Attempt to embed each sensitive view in a frame from a separate origin and establish whether framing is refused, by header or by policy directive. Where framing succeeds, determine whether an interaction with real consequence can be induced through an overlay. Check every sensitive route rather than the home page, since protection is frequently applied unevenly, and confirm in a browser rather than from headers alone.
Prerequisites — A second origin to host the framing page; a browser; the list of routes with consequential actions.
Indicators — A sensitive view framed from another origin; framing protection present on some routes and absent on others; a consequential action completed through an overlay.
Coverage — WSTG-CLNT-09V14.4.7CWE-1021
Depth — Hybrid Header checking automates; deciding which views carry consequence, and proving an interaction can be induced, does not.
WEB-CLNT-09 WebSockets
Objective — Determine whether a persistent socket applies the same authentication, authorisation and validation as the request-response surface, and whether it can be opened from another origin.
How it is tested — Establish a socket and enumerate the message types it accepts. Attempt to open one from a different origin and without a session, since the handshake is not subject to the same-origin policy and origin checking is frequently omitted. Send messages belonging to a higher privilege, messages out of the expected sequence, and malformed payloads. Determine whether authorisation is evaluated per message or only at handshake.
Prerequisites — A socket-using feature; accounts at more than one role; a client able to speak the protocol directly; a second origin.
Indicators — A socket opened from another origin or without a session; authorisation evaluated only at handshake; a privileged message accepted on a low-privilege socket.
Coverage — WSTG-CLNT-10CWE-346CWE-285
Depth — Manual Requires a client that speaks the application's own message protocol, which has to be learned first.
WEB-CLNT-10 Web Messaging
Objective — Determine whether messages passed between browsing contexts are sent to and accepted from only the origins intended.
How it is tested — Locate the message senders and listeners in the client bundles. For each sender, establish whether a specific target origin is named or a wildcard used, and whether sensitive data travels in the message. For each listener, establish whether the sender's origin is checked before the payload is used, and trace the payload to the sink it reaches. Send messages from a controlled origin to confirm.
Prerequisites — The client bundles; a browser; a page under the tester's control able to post messages to the application's context.
Indicators — A message posted to a wildcard target carrying sensitive data; a listener acting on a payload without checking origin; a payload from an unvalidated message reaching an executing sink.
Coverage — WSTG-CLNT-11CWE-346CWE-940
Depth — Manual Both halves are in the client code, and the vulnerable listener is frequently in a third-party bundle.
WEB-CLNT-11 Local and Session Storage
Objective — Determine what the application persists in browser storage, whether any of it is sensitive, and whether it survives the session that created it.
How it is tested — Inventory everything written to local storage, session storage and client-side databases across an authenticated session, and classify it. Establish whether session tokens, personal data or authorisation decisions are held there, since anything in storage is readable by any script that achieves execution in the origin. Confirm whether storage is cleared on logout, and whether values read back from it are trusted without revalidation.
Prerequisites — A browser whose storage can be inspected; an authenticated session that can be ended; an account with data worth classifying.
Indicators — Session or personal data in browser storage; storage surviving logout; an authorisation decision read from storage and trusted; storage values reaching a sink without revalidation.
Coverage — WSTG-CLNT-12V8.2.2V8.2.3CWE-922CWE-1004
Depth — Manual Classifying what a stored value means, and whether it is trusted on read, requires reading the code that uses it.
What we need from you
A real browser with developer tooling, since these defects are properties of execution rather than of the response text; the client-side bundles and their source maps where published; an authenticated session; and a second origin the tester controls for the cross-origin cases.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- WSTG-CLNT-01 — Testing for DOM Based Cross Site Scripting
- V5.3.3 — Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS.
- CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
- WSTG-CLNT-02 — Testing for JavaScript Execution
- V5.2.4 — Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.
- CWE-95 — Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
- WSTG-CLNT-03 — Testing for HTML Injection
- WSTG-CLNT-05 — Testing for CSS Injection
- CWE-80 — Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
- CWE-1021 — Improper Restriction of Rendered UI Layers or Frames
- WSTG-CLNT-04 — Testing for Client-Side URL Redirect
- V5.1.5 — Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.
- CWE-601 — URL Redirection to Untrusted Site ('Open Redirect')
- WSTG-CLNT-06 — Testing for Client-Side Resource Manipulation
- V14.4.3 — Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.
- CWE-829 — Inclusion of Functionality from Untrusted Control Sphere
- CWE-494 — Download of Code Without Integrity Check
- WSTG-CLNT-07 — Test Cross Origin Resource Sharing
- V14.5.3 — Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted domains and subdomains to match against and does not support the "null" origin.
- CWE-942 — Permissive Cross-domain Security Policy with Untrusted Domains
- CWE-346 — Origin Validation Error
- WSTG-CLNT-08 — Testing for Cross Site Flashing
- WSTG-CONF-08 — Test RIA Cross Domain Policy
- V1.14.6 — Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.
- WSTG-CLNT-09 — Testing for Clickjacking
- V14.4.7 — Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response headers.
- WSTG-CLNT-10 — Testing WebSockets
- CWE-285 — Improper Authorization
- WSTG-CLNT-11 — Test Web Messaging
- CWE-940 — Improper Verification of Source of a Communication Channel
- WSTG-CLNT-12 — Test Browser Storage
- V8.2.2 — Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data.
- V8.2.3 — Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.
- CWE-922 — Insecure Storage of Sensitive Information
- CWE-1004 — Sensitive Cookie Without 'HttpOnly' Flag
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.