XSS Detection & Auditing
Automated scanners, manual DOM auditing, browser extension analysis, and the CI pipeline that catches XSS before it ships. The defender toolkit beyond CSP.
Advanced14 min
XSSDetectionScanner
Loading lesson…
Automated scanners, manual DOM auditing, browser extension analysis, and the CI pipeline that catches XSS before it ships. The defender toolkit beyond CSP.
Finding XSS in production code requires more than a Content Security Policy. Automated scanners catch the low-hanging fruit; manual DOM auditing and browser extension analysis find the rest. This lesson covers the defender toolkit for detecting XSS before it reaches users.
XSS detection splits into three layers: automated scanning, manual auditing, and CI pipeline checks. Automated scanners like Burp Suite and ZAP crawl the application, inject a test payload into every parameter, and check whether the payload appears unescaped in the response. These tools catch reflected and stored XSS quickly, but they struggle with DOM-based variants because the payload never reaches the server.
Manual DOM auditing fills the gap. The auditor opens the browser developer tools, inspects every call to dangerous APIs like innerHTML, document.write, and eval, and traces whether the argument can be influenced by an attacker. Browser extensions that inject content scripts into every page — ad-blockers, password managers, dev tools — are also a blind spot because they operate outside the application's security boundary.
The dashboard below simulates a DAST scan against a target URL. Switch between automated scan mode and manual review mode to see how the same vulnerability looks from each perspective.
In 2018, British Airways suffered a data breach affecting 380,000 payment records. The initial compromise was not a SQL injection or a server-side vulnerability — it was a DOM-based XSS in a third-party JavaScript library loaded on the checkout page. The attacker modified the library to capture credit card details as the user typed them, then exfiltrated them to an attacker-controlled domain.
The vulnerability was discovered not by BA's internal security team but by automated scanning of third-party JavaScript dependencies. The post-mortem revealed that BA had no automated pipeline to monitor what their third-party scripts did at runtime. The case is now the textbook argument for CI-based XSS detection and supply-chain script auditing.
An effective XSS detection pipeline combines DAST scans, manual DOM reviews, and CI regression checks. DAST scans run on every staging deployment. Manual reviews happen at every major feature release. CI checks block pull requests that introduce new calls to dangerous DOM sinks without corresponding escape functions.
// CI check — reject PRs with untracked DOM sinks
const DANGEROUS_SINKS = ['innerHTML', 'outerHTML',
'document.write', 'eval', 'setTimeout'];
const failures = [];
for (const file of changedFiles) {
const content = readFile(file);
for (const sink of DANGEROUS_SINKS) {
if (content.includes(sink)) {
// Verify a corresponding escape call exists
if (!content.includes('escapeHtml') &&
!content.includes('textContent')) {
failures.push({ file, sink });
}
}
}
}
if (failures.length > 0) {
console.error('Blocked: untracked DOM sinks found');
process.exit(1);
}
// SAFE — DOM audit checklist
// 1. Enumerate all innerHTML/document.write/eval calls
// 2. Trace the value to its source
// 3. If source is attacker-accessible, add escaping
// 4. Replace innerHTML with textContent where possibleBrowser extensions deserve their own audit. An extension with access to<all_urls> can read and modify every page the user visits. The application cannot defend against a compromised extension — but the application can detect whether its own DOM has been modified by an unexpected script and raise an alert.
1.Why do DAST scanners struggle with DOM-based XSS?
2.What is the primary benefit of a CI pipeline XSS check?
3.How did the British Airways 2018 breach begin?