Skip to content

[FEAT] Audit and secure innerHTML usage to reduce XSS risks #1022

@redfish4ktc

Description

@redfish4ktc

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesttriageIssue/PR under review for categorization

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions