Enhancement: Chart uses dangerouslySetInnerHTML for styles — sanitize config #4

Closed
opened 2026-06-17 14:03:36 +00:00 by abumahid · 0 comments
Owner

Description

The ChartStyle component currently uses dangerouslySetInnerHTML to inject dynamically generated CSS based on ChartConfig.

While the current implementation may only consume trusted configuration data, this pattern introduces risk if chart configuration values are ever sourced from:

  • User input
  • CMS content
  • API responses
  • Database records
  • Third-party integrations

Any untrusted value interpolated into injected CSS could enable CSS injection and, depending on future implementation changes, potentially contribute to XSS vulnerabilities.

Impact

  • Potential CSS injection if configuration values contain malicious payloads.
  • Increased XSS risk when using dangerouslySetInnerHTML.
  • Security assumptions rely on all chart configuration remaining trusted forever.
  • Future code changes may unintentionally introduce exploitable attack paths.

Location

src/components/ui/chart.tsx

Component

ChartStyle

Approximate Lines

~69–86


Suggested Fix

Preferred Option

Avoid dangerouslySetInnerHTML entirely and construct styles using safer APIs or React-supported mechanisms.

Examples:

  • CSS variables
  • Inline style objects
  • DOM APIs (document.createTextNode)
  • Static class mappings
  • Theme token mappings

Alternative Option

If dangerouslySetInnerHTML must remain:

  • Sanitize all config keys.
  • Sanitize all config values.
  • Whitelist allowed characters.
  • Reject invalid CSS tokens.
  • Restrict values to known-safe formats (hex colors, CSS variables, predefined classes, etc.).

Security Requirements

  • Chart configuration must not be user-controlled.
  • Chart configuration must not be directly derived from remote content without validation.
  • Any dynamic values must pass validation before interpolation.

Example Validation

Key Validation

const SAFE_KEY_REGEX = /^[a-zA-Z0-9_-]+$/;

Color Validation

const SAFE_COLOR_REGEX =
  /^#([A-Fa-f0-9]{3}|[A-Fa-f0-9]{6})$/;

Reject any values that fail validation before generating CSS.


How to Audit Similar Patterns

Search for additional uses of dangerouslySetInnerHTML:

rg "dangerouslySetInnerHTML" src

Review each occurrence and verify:

  • Data source is trusted.
  • Input is validated.
  • A safer rendering approach is not available.

Acceptance Criteria

  • Review the ChartStyle implementation.
  • Validate whether chart configuration can originate from untrusted sources.
  • Remove dangerouslySetInnerHTML if a safe alternative is practical.
  • If retained, sanitize all dynamic values before interpolation.
  • Document trust assumptions for chart configuration.
  • Audit other dangerouslySetInnerHTML usages in the codebase.
  • No new ESLint, TypeScript, or security scanner warnings are introduced.

Local Verification

Run the following commands before creating the PR.

Build

npm run build

Lint Check

npm run lint

Security Audit

rg "dangerouslySetInnerHTML" src

Verify all results have appropriate safeguards.


## Description The `ChartStyle` component currently uses `dangerouslySetInnerHTML` to inject dynamically generated CSS based on `ChartConfig`. While the current implementation may only consume trusted configuration data, this pattern introduces risk if chart configuration values are ever sourced from: * User input * CMS content * API responses * Database records * Third-party integrations Any untrusted value interpolated into injected CSS could enable CSS injection and, depending on future implementation changes, potentially contribute to XSS vulnerabilities. ## Impact * Potential CSS injection if configuration values contain malicious payloads. * Increased XSS risk when using `dangerouslySetInnerHTML`. * Security assumptions rely on all chart configuration remaining trusted forever. * Future code changes may unintentionally introduce exploitable attack paths. ## Location `src/components/ui/chart.tsx` ### Component `ChartStyle` ### Approximate Lines ~69–86 --- ## Suggested Fix ### Preferred Option Avoid `dangerouslySetInnerHTML` entirely and construct styles using safer APIs or React-supported mechanisms. Examples: * CSS variables * Inline style objects * DOM APIs (`document.createTextNode`) * Static class mappings * Theme token mappings ### Alternative Option If `dangerouslySetInnerHTML` must remain: * Sanitize all config keys. * Sanitize all config values. * Whitelist allowed characters. * Reject invalid CSS tokens. * Restrict values to known-safe formats (hex colors, CSS variables, predefined classes, etc.). ### Security Requirements * Chart configuration must not be user-controlled. * Chart configuration must not be directly derived from remote content without validation. * Any dynamic values must pass validation before interpolation. --- ## Example Validation ### Key Validation ```ts const SAFE_KEY_REGEX = /^[a-zA-Z0-9_-]+$/; ``` ### Color Validation ```ts const SAFE_COLOR_REGEX = /^#([A-Fa-f0-9]{3}|[A-Fa-f0-9]{6})$/; ``` Reject any values that fail validation before generating CSS. --- ## How to Audit Similar Patterns Search for additional uses of `dangerouslySetInnerHTML`: ```bash rg "dangerouslySetInnerHTML" src ``` Review each occurrence and verify: * Data source is trusted. * Input is validated. * A safer rendering approach is not available. --- ## Acceptance Criteria * [ ] Review the `ChartStyle` implementation. * [ ] Validate whether chart configuration can originate from untrusted sources. * [ ] Remove `dangerouslySetInnerHTML` if a safe alternative is practical. * [ ] If retained, sanitize all dynamic values before interpolation. * [ ] Document trust assumptions for chart configuration. * [ ] Audit other `dangerouslySetInnerHTML` usages in the codebase. * [ ] No new ESLint, TypeScript, or security scanner warnings are introduced. --- ## Local Verification Run the following commands before creating the PR. ### Build ```bash npm run build ``` ### Lint Check ```bash npm run lint ``` ### Security Audit ```bash rg "dangerouslySetInnerHTML" src ``` Verify all results have appropriate safeguards. ---
abumahid added the Kind/Enhancement label 2026-06-17 14:03:36 +00:00
abumahid added this to the techzaa-frontend project 2026-06-17 14:03:36 +00:00
abumahid moved this to Done in techzaa-frontend on 2026-06-17 16:22:37 +00:00
rimi closed this issue 2026-06-17 16:25:15 +00:00
Sign in to join this conversation.