-
Notifications
You must be signed in to change notification settings - Fork 198
[FEAT] Audit and secure innerHTML usage to reduce XSS risks #1022
Description
Is your feature request related to a problem? Please describe.
maxGraph currently has multiple places where HTML is written with Element.innerHTML.
In many cases, the input may come from user-controlled data, and there is no sanitization in place. This can expose applications to XSS risks.
A recent Copilot review also highlighted this concern:
#1000 (review)
In some cases, the risk is documented when enabling a feature, for example with AbstractGraph.setHtmlLabels(), but this is not consistent across the codebase. As a result, users may enable features without clearly understanding the security implications.
Also, replacing innerHTML with safer DOM APIs such as innerText or textContent is not always possible, depending on the expected behavior.
Describe the solution you'd like
The goal is to make maxGraph safer by default and reduce XSS risks as much as possible.
Expected outcomes:
- remove XSS risks by default whenever possible
- reduce risks even when HTML-related options are enabled
- clearly document the remaining unsafe cases when they cannot be avoided
A possible implementation plan:
- list all methods and code paths that set
innerHTML - review each case to determine whether it can introduce security issues
- check whether the implementation can be changed to use safer DOM APIs
- when this is not possible, document the unsafe behavior clearly
- evaluate whether sanitization can be introduced, either with custom code or with a dedicated library
- where relevant, make unsafe HTML rendering opt-in behind explicit configuration switches
Describe alternatives you've considered
1. Use safer DOM APIs when possible
Prefer APIs such as textContent or innerText when the feature does not require raw HTML rendering.
Limitation:
This is not always possible because some features intentionally rely on HTML content.
2. Keep current behavior and improve documentation only
This would be the smallest change, but it would still leave users exposed by default in some cases.
3. Introduce HTML sanitization
If maxGraph needs to support user-provided HTML content, sanitization could reduce the risk.
Possible libraries:
| Library | Bundle Size | Performance | Best For |
|---|---|---|---|
| DOMPurify | ~16KB | Fast | XSS prevention, DOM-based sanitization, most use cases |
| sanitize-html | ~50KB | Good | Fine-grained tag/attribute control, complex filtering rules |
| xss | ~30KB | Very Fast | Performance-critical apps, whitelist-based filtering |
| HTML Sanitizer API | Built-in | Native | Modern browsers only, limited customization |
DOMPurify looks like a strong candidate because it is widely used, battle-tested, and focused on XSS prevention.
Example:
import DOMPurify from 'dompurify';
const dirty = '<img src=x onerror="alert(1)">';
const clean = DOMPurify.sanitize(dirty);If we introduce a sanitization dependency, we should also evaluate the impact on bundle size.
Additional context
This issue is intended as a general hardening task for HTML rendering in maxGraph.
It may later be split into smaller implementation issues if needed, for example:
- audit and inventory of innerHTML usage
- safe replacements with DOM APIs
- documentation updates
- optional sanitization support
- opt-in switches for unsafe HTML behavior