XSS
securityFull Name: Cross-Site Scripting
Definition
Cross-Site Scripting (XSS) is a web security vulnerability that enables attackers to inject malicious client-side scripts into web pages served by trusted websites, which then execute in the browsers of other users who view those pages. Named somewhat confusingly (the "cross-site" refers to the attacker's ability to make a trusted site execute untrusted code, not necessarily to cross-domain requests), XSS consistently ranks among the most prevalent and dangerous web vulnerabilities in the OWASP Top 10. The vulnerability arises when web applications include untrusted data in their HTML output without proper encoding or sanitization, allowing attacker-controlled content to be interpreted as executable code by the victim's browser. In the EUDI Wallet ecosystem, XSS vulnerabilities in any web-facing component (credential issuer portals, verifier web interfaces, wallet provider management dashboards, trust registry query interfaces, or administrative tools) could enable attackers to steal authentication tokens and session cookies, intercept or modify credential presentation data, redirect users to fraudulent credential issuance or presentation flows, exfiltrate personal identity data displayed in the interface, or perform unauthorized administrative actions. Given the sensitivity of identity data processed by EUDI Wallet infrastructure, XSS prevention is a critical security requirement enforced through eIDAS 2.0 certification testing.
XSS Attack Vectors in EUDI Wallet Web Components
EUDI Wallet web components face XSS risks at several points where untrusted data is incorporated into HTML output. Credential issuer portals that display user-submitted information (names, addresses, or other attributes from credential applications) are vulnerable if the display logic does not properly encode special characters. A malicious user could submit a name containing a script tag (such as including JavaScript within the name field), and if the issuer's administrative dashboard displays this name without encoding, the script would execute in the administrator's browser, potentially accessing administrative functions or stealing the admin's session token.
Verifier web applications that process credential presentations face reflected XSS risks. The OpenID4VP response contains credential data that the verifier application must display or process. If the verifier application reflects credential attributes (such as the holder's name or credential type) in the response page without encoding, an attacker who controls a specially crafted credential could inject scripts through the attribute values. While this attack vector is more constrained (the attacker must control a credential), it demonstrates why all data -- including data from seemingly trusted sources like signed credentials -- must be treated as untrusted when incorporated into HTML.
DOM-based XSS is particularly relevant for single-page application (SPA) architectures commonly used in modern EUDI Wallet web interfaces. If the JavaScript application reads data from URL fragments, query parameters, or API responses and inserts it into the DOM using unsafe methods (such as innerHTML, document.write, or jQuery's html()), an attacker can craft URLs or API responses that inject executable content. EUDI Wallet web applications built with frameworks like React, Angular, or Vue benefit from built-in XSS protections (automatic output encoding in templates), but developers can accidentally bypass these protections through unsafe practices like dangerouslySetInnerHTML (React) or bypassSecurityTrust (Angular).
XSS Prevention for EUDI Wallet Systems
The primary defense against XSS is context-aware output encoding. Every piece of untrusted data inserted into HTML output must be encoded according to the context in which it appears: HTML entity encoding for content within HTML elements, attribute encoding for values within HTML attributes, JavaScript encoding for values within JavaScript code blocks, URL encoding for values within URL parameters, and CSS encoding for values within CSS styles. Modern web frameworks provide automatic encoding in their template engines, and EUDI Wallet developers should use these built-in mechanisms rather than manual encoding, which is error-prone.
Content Security Policy (CSP) provides a powerful second line of defense. A strict CSP header instructs the browser to only execute scripts from explicitly trusted sources, effectively neutralizing injected scripts even if output encoding is accidentally omitted. For EUDI Wallet web applications, the recommended CSP configuration includes disabling inline scripts (requiring all scripts to be loaded from separate files with nonce-based authorization), restricting script sources to the application's own origin and explicitly trusted CDNs, disabling eval() and similar dynamic code execution functions, and restricting form submission targets to prevent credential data exfiltration. A properly configured CSP can prevent the majority of XSS attacks even when application-level encoding is imperfect.
Additional defense layers include HTTP-only and secure flags on session cookies (preventing JavaScript access to authentication tokens), Subresource Integrity (SRI) attributes on external script tags (preventing modification of loaded scripts through CDN compromise), X-Content-Type-Options: nosniff header (preventing MIME type confusion attacks), and input validation on the server side (rejecting input containing unexpected characters for fields with well-defined formats like credential identifiers or dates). Together, these measures create a defense-in-depth strategy where no single XSS prevention mechanism needs to be perfect because multiple layers provide overlapping protection.
XSS in eIDAS 2.0 Certification and Compliance
The eIDAS 2.0 certification process for EUDI Wallet infrastructure includes explicit security testing for XSS vulnerabilities as part of the broader web application security assessment. Certification evaluators use both automated scanning tools (which can detect common XSS patterns) and manual penetration testing (which can identify context-specific vulnerabilities that automated tools miss) to verify that all web-facing components are protected against XSS. Discovery of XSS vulnerabilities during certification results in a finding that must be remediated and re-tested before the certification can be granted.
Beyond initial certification, EUDI Wallet operators must maintain XSS prevention as part of their ongoing security program. This includes security code reviews for all changes to web components (specifically checking for unsafe output handling), automated security testing in the CI/CD pipeline (running SAST and DAST tools that check for XSS patterns in every build), dependency monitoring (checking for XSS vulnerabilities in third-party JavaScript libraries and frameworks), and regular penetration testing (at least quarterly for internet-facing components) that includes XSS-specific test cases.
The consequences of an XSS vulnerability in EUDI Wallet infrastructure extend beyond the immediate technical impact. A successful XSS attack that leads to exposure of personal identity data triggers GDPR breach notification obligations (72-hour notification to the Data Protection Authority, potential notification to affected individuals). If the vulnerability enabled credential theft or manipulation, the trust implications for the entire EUDI Wallet ecosystem could be significant, potentially undermining public confidence in the digital identity system. This is why XSS prevention is treated as a critical security requirement rather than a routine web development concern in the EUDI Wallet context.