[RFC] Architectural Audit: Potential memory leaks, XSS vectors, and SSR stability in 5.3.x

[idk8914289912]

Prerequisites

• I have searched for duplicate or closed issues
• I have validated any HTML to avoid common problems
• I have read the contributing guidelines

Describe the issue

While performing a deep dive into the 5.3.x source code for a custom integration, I’ve identified a few architectural patterns and edge cases that might lead to stability and security issues in specific environments (especially SPAs and SSR).

I’ve summarized the findings below:

1. Potential XSS via sanitizer.js
   The sanitizeHtml function currently returns the result through innerHTML. While there is an allowList in place, using innerHTML as the primary injection vector is risky. If a developer misconfigures the SAFE_URL_PATTERN or the attribute filter, it opens a door for XSS attacks.

Recommendation: Consider more robust DOM manipulation or a stricter output sanitization layer to reduce the risk of bypasses.

2. Event Registry Memory Leaks (event-handler.js)
   The eventRegistry keeps references to handlers tied to unique element IDs. In Single Page Applications (SPAs) where elements are frequently created and destroyed without an explicit call to dispose() or EventHandler.off(), these references persist. Over time, this leads to a significant memory footprint increase.

Recommendation: Perhaps implementing a more automated cleanup or utilizing WeakMap for registry storage could mitigate these leaks in dynamic environments.

3. Selector Engine Robustness (selector-engine.js)
   Currently, find and findOne methods wrap querySelector directly without try-catch blocks. If an invalid CSS selector is passed through data-bs-target or href (e.g., unescaped special characters or :invalid(), the browser throws a DOMException, which halts the entire JS execution thread.

Recommendation: Wrapping queries in a try-catch to return null or an empty array would prevent the entire application from crashing due to a malformed attribute.

4. DOM Encapsulation Conflicts in modal.js
   The _showElement method uses document.body.append(this._element). While this ensures the modal is on top, it forcefully moves the element in the DOM tree. This is a known "pain point" for React/Vue/Angular users, as it breaks the virtual DOM's encapsulation and can lead to runtime crashes during re-renders.

Recommendation: Acknowledging this is a legacy behavior, but exploring "Portal-like" logic or providing an option to toggle body-appending would greatly improve DX for modern framework users.

5. Config Merging and Validation Risks (config.js)
   Shallow Merging: _mergeConfigObj uses the spread operator (...). This causes nested configuration objects to be overwritten rather than merged, which can lead to unexpected data loss.

RegExp Validation: Creating new RegExp(expectedTypes) on the fly without pre-validation is risky. A malformed expectedTypes string will throw a syntax error, preventing the component from initializing.

I’m happy to discuss these further or provide more specific examples if needed. Let me know if you’re open to PRs addressing any of these points!

Reduced test cases

These are architectural findings based on a static analysis of the source code. A specific visual test case is not applicable for logic-based memory leaks and RegExp syntax risks, but the code locations are provided in the description.

What operating system(s) are you seeing the problem on?

Windows, macOS, Linux

What browser(s) are you seeing the problem on?

Chrome, Firefox, Microsoft Edge, Opera, Safari

What version of Bootstrap are you using?

v5.3.x (latest source as of Feb 16, 2026)