Harden config colour/size values against style-attribute injection

[amadeobriones]

🤖 Disclosure — written with an AI agent (Claude Code) under my direction. I run this card on a live HA instance daily. Addresses #64.

Config is shareable/importable, so its colour and size fields are effectively attacker-controlled. Lit doesn't escape ; or } inside a style-attribute expression, so a shared/imported config can break a value out of its declaration — e.g. background: "red;position:fixed;inset:0;z-index:99999" paints a full-viewport overlay over the HA UI, and a colour containing url(…) becomes an IP-leaking remote fetch.

What this does

• Adds src/css-safe.ts: an allowlist cssColor/cssColorOr (hex, named + CSS-wide keywords, rgb/hsl/hwb/lab/lch/oklab/oklch/color(...), and var(--x[, fallback])) plus a cssNumber coercion for numeric fields. Allowlist over denylist on purpose — a denylist invites the one vector you forgot.
• Wires it at every style="…" sink in the card, the editor preview, and the shared render helpers: stage background, text color/size, item badge size/angle, opening accent (the fill/stroke in style=), and ripple color/size.
• Leaves SVG fill=/stroke=/transform= presentation attributes alone — there's no CSS declaration there to break out of, so they're not this bug class.

Honest scoping

• The colour allowlist is the part I've run hard; the size/angle numeric coercion is a simple finite-number guard (new, not previously battle-tested, but small and covered by tests).
• Top-level width/height/grid already go through your setConfig numeric check, so those are left as-is.
• Items: Show name toggle + adjustable label size — closes #61, #59 #62 adds a labelSize field of the same shape; it's not on main so it's out of scope here — it just needs the same cssNumber wrap wherever it lands.

Backward-compatible: every legitimate value renders unchanged — I tested the allowlist against the colours real configs use (HA theme vars with/without fallback, hex, named, rgb/rgba in comma and modern space syntax, hsl/hsla, oklch/lab/lch/hwb/color). Only invalid/malicious values fall back to the existing defaults. tsc clean; full suite green (adds sanitiser unit + adversarial/fuzz cases).

Marked as a draft — happy to adjust scope, naming, or split it if you'd prefer smaller.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: bfa089ffc5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve valid nested CSS variable colors

When a user configures a color with a nested theme fallback such as var(--ha-card-background, var(--card-background-color, #fff)), this allowlist rejects it because the fallback part of var() cannot contain parentheses. Nested var() fallbacks are valid CSS and common in Home Assistant theme values, so existing configured backgrounds, text colors, active colors, or ripple colors silently revert to the hard-coded default after this change.

Useful? React with 👍 / 👎.

[amadeobriones]

Good catch from the Codex pass — the follow-up commit addresses it, and it turned out to point at something broader.

The nested var() fallback it flagged (var(--a, var(--b, #fff))) was indeed being rejected. Digging in, the same limitation also rejected rgb(var(--rgb-primary-color)) / rgba(var(--rgb-*), …) — the standard way HA has expressed theme colours since 2022.12 (stored as bare r, g, b triplets). So the first pass would have silently reverted a lot of real theme values to their defaults.

Rather than special-case those, I swapped the fixed colour-regexes for a structural check: allowed characters only (no ; { } " ' : @ \ !), balanced parens, and every function call on an allowlist of inert ones (colour / gradient / var / env / maths). Arbitrary nesting like rgb(var(--x)) and var(--a, var(--b, #fff)) now passes, while url() / image-set() / expression() / attr() / element() / paint() can never appear, nested or not.

I checked it against theme-colour forms from across HA versions — named, hex, rgb()/hsl() literals, traditional var(--…), the older --paper-* / --mdc-theme-* variables, the 2022.12+ rgb(var(--rgb-*)) idiom, fallback chains, and modern color-mix() / light-dark() — plus an adversarial + fuzz battery. Still O(n), no ReDoS.

One trade-off worth flagging: it's slightly more permissive than a strict grammar — an invalid value like #xyz is accepted and simply ignored by CSS rather than pre-rejected. Safe (no breakout), and it's what lets the full HA colour syntax through.

[amadeobriones]

Following up on my own PR with a gap I found while re-auditing this.

The colour/size sanitiser is solid, but width/height still reach the stage's aspect-ratio raw — aspect-ratio: ${c.width} / ${c.height} at editor.ts and floorplan-card.ts. The card's setConfig guards those as numbers, but the editor's setConfig doesn't, so a config imported/opened in the editor can break out. Reproduced in the dev harness: setting width to "1 / 600; position: fixed; inset: 0; z-index: 99999; background: rgb(255,0,0)" makes the editor .stage compute position: fixed — the injected CSS takes effect (a full-viewport overlay; swap for url() via the height field and it's a remote fetch).

Fix is ready and verified: coerce both sinks through cssNumber(c.width, DEFAULT_WIDTH) / cssNumber(c.height, DEFAULT_HEIGHT), plus cssNumber should treat a blank string as unset (Number("") is 0). With it applied, the same payload renders aspect-ratio: 1000 / 600 and position stays relative; adds regression tests; full suite green (309). Happy to push it to this branch — flagging here first so it's visible.

[nicosandller]

Approved — and we agree with the scope as drawn: style-attribute sinks only, SVG presentation attributes deliberately excluded (no declaration to break out of there), numeric fields coerced rather than pattern-matched, allowlist over denylist. That's the right boundary for this bug class, and the test suite — legit HA colours across every theme era, the hand-written attack corpus, and the 500-case fuzz invariant — is the most thorough in the repo.

I've rebased the branch on main (pushed to your fork — hope that's welcome; it was the same mechanical churn as the other rebases this week):

• One conflict, the badge size line vs #58's animation resolver — resolved as a union, so the sanitized size and the animation class both stay.
• #62's labelSize now routes through cssNumber exactly as your PR body anticipated: itemLabelSize keeps its 8–40 range clamp but delegates coercion to your shared guard, so every numeric style sink uses one primitive.
• Audited the merged tree for style sinks that arrived after your branch (#57/#58/#60/#62) — all covered; no unsanitized interpolation remains.

Verified end-to-end: tsc clean, 341/341 tests, build clean, and a live harness pass — the demo attack (red;position:fixed;inset:0;z-index:99999 as background) falls back to the theme default, a url(…)-smuggling text colour is neutralized, hostile size/labelSize strings coerce to defaults, while var(--primary-color, #03a9f4) and the rgba(var(--rgb-primary-color), 0.5) triplet idiom render byte-identical and the merged features (icon animation, labels, rotation) still work.

Two style sinks in my still-open branches (#63's roll curtain scaleY, #69's editor preview) will adopt these helpers when they rebase after this lands. Ready to merge.