Cross-Site Scripting (XSS) Testing

Reflected XSS fires from a crafted link and needs a victim to click it, so it pairs naturally with phishing. Stored XSS is worse: the payload sits in your database and runs for everyone who views the affected page, no link required. DOM-based XSS never touches the server at all, living entirely in JavaScript that writes untrusted data into the page. Each needs a different test, and a tool tuned for one commonly misses the others.

The same input can be safe in one place and dangerous in another. Reflected inside an HTML body it needs one payload, inside a tag attribute another, inside a block of JavaScript another again. We identify the exact context of each reflection and craft a payload that fits it, which is why we find the injections that a generic scanner, blind to context, reports as clean.

We map every input that ends up on a page: query parameters, form fields, headers, JSON values, filenames and anything rendered from the URL. Each is probed with a marker to see where and how it is reflected, and whether the output is encoded, partially encoded or passed straight through.

A reflection is only a vulnerability if it runs. We escalate from a harmless marker to a context-appropriate payload that proves script execution, using a benign proof rather than anything disruptive. For stored XSS we confirm which users would trigger it, because a payload that fires in the admin panel is a different severity from one that only affects the person who submitted it.

DOM analysis

DOM-based XSS needs the JavaScript read, not just the responses watched. We trace how the app moves data from sources like location.hash into sinks like innerHTML, and confirm the path an attacker controls. This is where framework apps hide their XSS, and where scanners are weakest.

Finding the injection is half the job. The other half is whether your defences would stop it in the real world.

Content Security Policy

A good CSP can neuter an XSS even when one exists. We review yours for the weaknesses that make it decorative: unsafe-inline, over-broad host allowlists, and JSONP endpoints on trusted domains that let an attacker load script anyway. Then we tell you exactly how to tighten it.

Filters and WAF

Input filters and web application firewalls give a false sense of safety when they block the obvious payloads and miss the creative ones. We test evasion so you learn whether the control is real protection or a speed bump.

If your session cookie lacks the HttpOnly flag, XSS reads it directly and hands the attacker the account. Even with HttpOnly, a script running in the page can act as the user: change the account email, add an attacker’s device, or fire off state-changing requests behind the scenes.

XSS can overlay a fake login prompt, log keystrokes, or rewrite what the page shows. In a banking or checkout flow the attacker does not need your password if they can alter the destination account in the browser after you have logged in.

The nastiest cases combine flaws. A stored XSS in a field an admin reviews runs with admin privileges, and from there it can perform any action the admin can, including creating new admin accounts. That single chain turns a “medium” input bug into full application compromise.

A plain-language read on whether your users’ sessions and your admin panel can be hijacked through the browser, and what that would cost you.

Each finding lists the injection point, the XSS type, the exact payload, the context, a CVSS score, business impact, reproduction steps and a specific fix, with output encoding and CSP guidance rather than a fragile blocklist.

After your team applies the fixes we re-test every finding at no charge and confirm the payload no longer executes, in every context where it fired.

Cross-site scripting sits within the OWASP Top 10 injection category, and our testing maps to it and to the relevant OWASP ASVS output-encoding requirements, giving your developers a recognised structure for the fixes.

PCI DSS requirement 6 names cross-site scripting among the flaws you must address, and ISO 27001, SOC 2 and GDPR expect demonstrable testing of applications handling sensitive data. The report and attestation letter are written to support these.

PHP, Java and .NET templates that echo variables without encoding are the classic reflected and stored vectors. We check each output point for the right context-aware encoding rather than trusting that the framework does it everywhere by default.

Modern frameworks escape by default, which lulls teams into complacency. The exceptions are the danger: dangerouslySetInnerHTML in React, bypassSecurityTrust in Angular, v-html in Vue. We audit each use of these against untrusted data, since they are where DOM XSS survives in an otherwise safe app.

Anywhere users submit formatted content, a sanitiser stands between them and stored XSS. We test that sanitiser hard, because a single allowed attribute or an unfiltered SVG can reopen the whole class of bug.