Express XSS Sanitizer restrictive configuration bypass

The primary impact is weakening or bypass of intended XSS defenses in applications that rely on Express XSS Sanitizer with restrictive custom configurations. If an application expects empty allowedTags and/or allowedAttributes to enforce a highly restrictive sanitization policy, affected versions may instead permit content according to overridden defaults, increasing the likelihood that attacker-supplied markup survives sanitization. This can lead to stored or reflected XSS depending on how the sanitized data is later rendered, with potential consequences including session theft, arbitrary script execution in victims’ browsers, content injection, and integrity compromise of the web application’s client-side context.

If immediate upgrade is not possible, avoid relying on empty allowedTags or allowedAttributes values in affected versions to enforce restrictive policies, because those settings may be ignored. Review middleware configuration and validate the actual sanitization output against expected policy. As a compensating control, apply output encoding appropriate to the rendering context, use defense-in-depth browser controls such as CSP where feasible, and consider direct sanitize-html configuration or equivalent server-side sanitization logic that can be verified to enforce the intended restrictions until the library is upgraded.

Upgrade Express XSS Sanitizer to version 2.0.2 or later. The fix updates validation logic so that explicitly provided allowedTags or allowedAttributes values, including empty configurations, are passed directly to sanitize-html and are no longer silently overridden. Where possible, verify application behavior after upgrade with regression tests covering custom sanitization policies, especially configurations intended to disallow all tags or attributes.