Many teams believe that cross-site scripting, or XSS, is a problem of the past. Modern frameworks promise built-in protections, and developers often assume the browser will handle the rest. The reasoning sounds logical: if React auto-encodes output, XSS can’t happen. However, XSS prevention doesn’t work on assumptions; it works on visibility.
We’ve learned that XSS prevention is about maintaining continuous control over the browser environment where your application runs. A practical next step is understanding exactly where XSS happens in modern applications and why your current defenses likely have gaps.
What you will learn in this article:
- What cross-site scripting (XSS) means and why it still matters
- How XSS bypasses modern framework protections
- The three types of XSS and where they hide
- Proven techniques that auditors look for during assessments
- How continuous monitoring closes the gaps code reviews miss
What is cross-site scripting (XSS)?
Cross-site scripting, or XSS, allows attackers to inject malicious JavaScriptf into pages viewed by your users. The injected code runs in the browser with the same permissions as your legitimate application code.
The browser can’t distinguish between the code you intended and the code someone else inserted. As a result, the malicious script can read cookies, capture keystrokes, modify page content, or redirect users, all while appearing to come from your trusted site.
From a compliance perspective, XSS matters because it directly violates the principle of controlling what executes on your pages. Although well-understood, XSS remains prevalent because teams focus on preventing it at the code level while missing the scripts that load after deployment.
How PCI DSS and Industry view XSS
Industry experience continues to show that cross-site scripting is a leading cause of web application compromise. The root issues are consistent: untrusted input is not validated or sanitized, and dynamic output is rendered without proper encoding.
For organizations handling payment data, PCI DSS Requirement 6.4.3 mandates that all scripts on payment pages must be inventoried, authorized, and integrity-checked. While designed to prevent card skimming, this requirement directly addresses XSS by mandating organizations to control what JavaScript executes in the browser. Requirement 11.6.1 goes further, requiring detection of unauthorized changes to payment pages, which includes injected scripts.
From an auditor’s perspective, saying “we use React” or “our code is secure” isn’t evidence of XSS prevention. Assessors want to see documentation: your script inventory, how you authorize each script, your monitoring alerts when scripts change, and your process for reviewing third-party code.
We’ve sat through hundreds of PCI assessments, and the most common gap isn’t vulnerable code. It’s the lack of visibility into what’s actually running in the browser after your application goes live.
The three types of XSS attacks
Reflected XSS occurs when a malicious script is included in the HTTP request and immediately reflected back in the response. The attacker crafts a link containing malicious code and persuades a user to click it. We’ve seen this exploited most often in search parameters, error messages, and redirect URLs.
Stored XSS happens when malicious code is saved within your application’s database. Every user who views that content automatically runs the script. In one retail client’s application, we found stored XSS in their product review system. An attacker had posted a review containing hidden JavaScript six months earlier. Every customer who viewed that product page unknowingly executed the script, which captured their session tokens.
DOM-based XSS exists entirely in client-side JavaScript code. The malicious script never touches your server, so server-side security tools can’t detect it. A financial services client we worked with had DOM-based XSS in their single-page application’s routing logic. Because this all happened client-side, their penetration tests missed it completely.
The four XSS blind spots your defenses are missing
1. Third-party scripts that bypass your controls
Your application code may be secure, but analytics tags, chat widgets, and marketing pixels all execute with the same browser permissions. A single compromised or misconfigured third-party script can expose sensitive customer data or inject malicious code into trusted pages.
From an auditor’s perspective under PCI DSS 6.4.3, every script that executes on your payment pages requires authorization and integrity monitoring. That includes all third-party and third-party-loaded scripts.
2. Framework bypasses that developers use daily
React, Angular, and Vue encode output by default, which prevents most XSS. However, developers routinely bypass these protections using functions like dangerouslySetInnerHTML or innerHTML to solve formatting problems.
In React e-commerce codebases, we frequently see numerous uses of dangerouslySetInnerHTML. Many teams don’t realize this bypasses React’s XSS protections. Typical risk areas include rendering CMS-managed product descriptions or marketing content without proper sanitization. We mitigate by removing nonessential sinks, sanitizing allowed HTML, validating inputs server-side, and enforcing a tight CSP.
3. DOM-based XSS in single-page applications
Single-page applications handle routing in JavaScript. Security tools that scan HTTP responses can’t see these client-side vulnerabilities because the dangerous code never reaches your server.
From an auditor’s perspective, this is a critical gap. Your penetration test reports might show no XSS vulnerabilities, but those tests probably didn’t examine client-side routing logic. The only way to catch DOM-based XSS is through runtime monitoring that observes JavaScript behavior in actual user sessions.
4. Unmonitored CSP violations that hide attacks
Many teams implement Content Security Policy but never configure violation reporting. When CSP blocks a script, it creates a report showing what was blocked and why. Without monitoring, you never know whether you blocked a legitimate feature or an actual attack attempt.
In checkout flows that use CSP, enabling violation reporting often uncovers dozens of reports each day. Most map to legitimate scripts that need to be allow-listed, but a small number can reveal clear XSS attempts, such as inline scripts trying to send form data to external domains.
These attacks may have been occurring for weeks. CSP blocks them, yet teams may not realize attacks are happening without monitoring. From a compliance perspective, PCI DSS 11.6.1 requires detection of unauthorized changes. If attacks are blocked but not detected or investigated, it is difficult to demonstrate that your controls are working.
How to prevent XSS on payment pages
1. Encode output based on context
Encoding converts special characters into safe representations before displaying them, ensuring the browser treats user input as data rather than code. Most modern frameworks handle HTML encoding by default. The vulnerabilities appear when developers bypass these protections. In React, dangerouslySetInnerHTML explicitly disables encoding. Use it only when absolutely necessary, and only with input that has been sanitized by a well-maintained library like DOMPurify.
2. Implement Content Security Policy correctly
Content Security Policy tells browsers which scripts are allowed to execute, blocking everything else. Start with a restrictive baseline that allows scripts only from your domain and specific CDNs. Deploy in report-only mode first to see what would be blocked without breaking functionality.
Common CSP mistakes we see: using ‘unsafe-inline’ defeats most XSS protection, not monitoring violation reports means missing both attacks and legitimate blocks, and overly permissive wildcards provide minimal protection.
From an auditor’s perspective, having CSP configured isn’t sufficient evidence. You must demonstrate that you review violations, respond to policy breaches, and update the policy as your application changes.
3. Monitor what actually executes in production
Code reviews and security testing catch many issues, but they represent a moment in time. Monitoring shows you what’s actually happening in production, after deployment, when real users interact with your application. You need to know what scripts execute in your users’ browsers, not just what you deployed.
See how Feroot stops XSS before it executes
XSS prevention under OWASP and PCI DSS standards requires two things: control over what scripts execute, and evidence that your controls work continuously.
Feroot’s PageGuard platform provides the visibility and documentation that compliance requires:
Continuous script inventory and authorization automatically discovers every script executing on your pages, including third-party tags that load dynamically. When a script appears that wasn’t approved, you receive an immediate alert. This directly addresses PCI DSS 6.4.3, which requires organizations to maintain an inventory of authorized scripts on payment pages.
Real-time XSS detection and behavioral monitoring observes actual runtime behavior in production, catching DOM-based XSS and framework bypasses that static analysis misses.
CSP violation monitoring and analysis provides context for each violation, helping you distinguish between legitimate functionality that needs adjustment and actual attack attempts. This creates the audit trail that demonstrates your controls aren’t just configured; they’re actively monitored and maintained.
We’ve helped hundreds of organizations implement client-side security without disrupting their development velocity. When you can see what executes in real browsers, XSS prevention becomes a manageable, everyday practice rather than an emergency response after an incident.
See PageGuard in action. Schedule a demo.
Conclusion
Cross-site scripting remains one of the most exploited web vulnerabilities, but it’s also one of the most preventable when teams understand where modern applications are actually at risk.
The gap between your framework’s built-in protections and real-world security comes down to visibility. Your React components may be secure, but can you list the 15 third-party scripts loading on the same page? Your output encoding may be perfect, but do you know when a developer bypasses it?
The teams that maintain XSS-free environments aren’t necessarily the ones with the most security expertise. They’re the ones with the best visibility into what actually runs in production. When you can see what’s executing, you can control it. When you can control it, compliance becomes straightforward and security becomes predictable.
