harden: add output encoding in typography.js (CWE-79)

[anupamme]

The typography panel accepts user input for base font size settings through the baseFontSizeInput state variable without strict input validation. This input is stored in the WordPress database via the saveSettings function and later rendered in the admin interface. While the value is primarily used in CSS contexts, the presence of dangerouslySetInnerHTML usage in the same file for notices indicates potential XSS vectors if user-controlled data reaches these render paths without proper sanitization. This is defence-in-depth at App/Controller/Manager/src/js/panels/typography.js:166 rather than a vulnerability I can show is exploitable here — it makes the failure mode explicit and bounded. Close it freely if the pattern is intentional.

Reference: CWE-79

What changed

• App/Controller/Manager/src/js/panels/typography.js

Verification

No automated check could be run against this repository, so this change is unverified beyond review. Please treat it as a suggestion.

---

Automated security fix by OrbisAI Security

[inc2734]

Thank you for the suggestion. I am closing this PR because it breaks supported base font size values. The default is the string 16px (Settings.php), and the Typography input also stores strings such as 20px. The new number-only check turns these values into undefined, so reopening the panel leaves the Base Font Size field empty and the preview no longer reflects the saved value.

The proposed XSS path is not demonstrated: the base font size is used through getRootFontSize and React style properties, while the dangerouslySetInnerHTML notice uses a translation and fixed <code> tags. The base font size does not reach that HTML sink. This change also leaves the saved value and frontend CSS output unchanged, so it does not address those paths. If there is a reproducible injection path, please share the input, sink, and reproduction steps so we can address it at the appropriate boundary.

[anupamme]

Thanks for tracing the existing flow. I agree that the current patch is incorrect because 16px/20px are legitimate values, and the number-only validation breaks the settings UI.

I withdraw that change. I’ll separately verify whether an attacker-controlled base-font-size value can actually reach an HTML sink. If I can establish a reproducible source → sink path, I’ll open a focused PR with the exact payload and reproduction steps. Otherwise, I’ll consider the original finding a false positive.