XSS testing that proves code execution
Cross-site scripting (XSS) is when your app renders attacker-controlled input as live code, so a script runs in another user's browser — stealing sessions, keystrokes or acting as them. Sintropyc tests reflected, stored and DOM-based XSS and proves each finding by executing script in a real browser, never by guessing from a reflected string.
The three kinds of XSS
XSS comes down to where the untrusted input enters and where it executes. All three end the same way — attacker JavaScript running with your user's session.
- Reflected — input in a request is echoed straight back into the page (a search term, an error message, a URL parameter)
- Stored — input is saved and served to other users later (a comment, a profile field, a support ticket); the most dangerous, because victims need no link to click
- DOM-based — the server is never involved; client-side JavaScript writes untrusted data into the page (
innerHTML,location.hash, a framework sink)
Why a reflected payload isn't proof
Most scanners flag XSS when their payload appears in the response. But a string in the HTML is not the same as a string that executes — modern frameworks escape by default, a Content-Security-Policy can block inline script, and the context (attribute, script, HTML) decides whether it runs at all. Reporting reflection as XSS is how scanners generate false positives.
Sintropyc only reports XSS it can actually fire — a real browser loads the page and the injected script runs (a controlled callback, a DOM change), captured as the proof. If it reflects but can't execute, it isn't reported as XSS.
How Sintropyc tests it
Sintropyc is an autonomous AI penetration testing agent. It signs in as real users across different roles, drives your product the way a customer would, and proves every finding with a working exploit — never a scanner guess. Each finding is checked by a human before it reaches you, comes with the exact fix, and is attacked again after you ship it to confirm it held.
For XSS, Sintropyc drives your app in a real headless browser, injects context-aware payloads across inputs and stored fields, and watches whether the script actually executes — including after a page reload for stored XSS and through client-side sinks for DOM XSS. The proof is the executed effect from a real channel, with the exact input and where it landed.
What you get
- Reflected, stored and DOM XSS tested across every input and rendered field
- Each finding proven by real script execution in a browser — no reflection-only guesses
- The exact sink and the encoding/CSP fix that closes it
- A retest after you ship the fix
Common questions
Do you test single-page apps (React, Vue, Svelte)?
Yes. Those frameworks escape by default, so most real XSS in them is DOM-based or via a dangerouslySetInnerHTML-style sink. Sintropyc drives the running app and finds the sinks that actually execute.
Won't a CSP stop XSS anyway?
A strong Content-Security-Policy raises the bar, but many are misconfigured (unsafe-inline, wildcard sources) or bypassable. Sintropyc tests whether your CSP actually blocks execution rather than assuming it does.
Is this safe to run against real users?
Yes. Payloads use controlled, benign callbacks that prove execution without harming users or data, and stored tests are cleaned up. Nothing destructive runs without your sign-off.