fix(security): remove dangerous tags and attributes from DOMPurify allow-list (WCH-SI10-001)

[smohite-nice]

Removes dangerous tags and attributes that were explicitly re-permitted in the hand-rolled DOMPurify allow-list, restoring the security boundary the sanitizer was intended to provide.

Scope — user-typed input and PrivacyNotice text only.
sanitizeHTML() in this repo is called on two surfaces:

1. User-typed messages — message-middleware.ts:123 (SEND_MESSAGE path), when disableTextInputSanitization is false
2. PrivacyNotice body — PrivacyNotice.tsx:58, sanitizing the tenant-configured notice text

Bot and agent messages are out of scope for this PR.
Incoming bot/agent messages flow through RECEIVE_MESSAGE → addMessage() → @cognigy/chat-components, which never calls sanitizeHTML() in this repo. Bot message HTML sanitization lives in @cognigy/chat-components. Tags like style and iframe used by customers to style or embed content in bot messages are not affected by this change and must be addressed separately in that repo.

FedRAMP SI-10 / AC-4 remediation (WCH-SI10-001 — partial):
The previous allowedHtmlTags and allowedHtmlAttributes arrays re-permitted every tag and attribute that DOMPurify excludes by default, weakening sanitization for user-typed input. This PR restores the correct security boundary for the two surfaces listed above.

The dangerous path only opens when disableHtmlInput: false is configured (non-default). With the default disableHtmlInput: true, stripHtmlToInertText() runs after sanitizeHTML() and strips all HTML anyway — but the permissive allow-list is still a defence-in-depth gap.

Tags removed from allowedHtmlTags:
applet, base, body, embed, form, frame, frameset, head, html, iframe, link, meta, noframes, object, style

Note on html / head: these were inconsistently left in the previous commit alongside the removal of body. All three are structural document elements with no legitimate use in sanitised chat fragments; removed for consistency.

Known minor behaviour change: iframe and noframes are members of DOMPurify's DEFAULT_FORBID_CONTENTS. Once removed from ALLOWED_TAGS, they are stripped along with their entire subtree rather than just unwrapped. In practice this only affects developer-facing bots where a user literally types an <iframe> tag — the text content following the tag is also removed. Not a regression in normal use.

Attributes removed from allowedHtmlAttributes:
action, formaction, sandbox, srcdoc, style, target

All other tags (img, audio, video, table, a, b, p, etc.) and safe attributes (href, src, alt, rel, etc.) are preserved — no functional regression for PrivacyNotice content or user text input under non-default configurations.

Jira: CSA-97602

Success criteria

• None of the removed tags appear in the DOM after user-typed input is submitted containing those tags
• None of the removed attributes appear on any element after user-input sanitization
• Bot message rendering is unaffected — customers using style or iframe in bot messages see no change
• All existing Cypress tests pass — no regression in safe tag rendering

How to test

1. Run npm run build && npm test — all Cypress tests including the new sanitize.cy.ts suite pass
2. With disableHtmlInput: false, submit an iframe with a srcdoc script — verify no iframe element appears in chat history
3. Submit a base tag with an attacker href — verify no base element appears and page URLs are unchanged
4. Submit a form with an attacker action — verify no form element appears
5. Receive a bot message with inline styles or an iframe — verify it renders correctly and is unaffected

Security

• Possible injection vector
• Authentication/Access controls touched
• Sensitive Data could be exposed
• XSS
• Logging/Monitoring touched
• Exchanges data with external systems
• No security implications

Accessibility (WCAG 2.2 AA)

• No accessibility implications (non-UI change)

Additional considerations

• This PR might have performance implications

Documentation Considerations

No documentation update required — allowedHtmlTags and allowedHtmlAttributes are internal implementation details. Bot message rendering (and its allow-list) lives in @cognigy/chat-components and is not changed by this PR.

🤖 Generated with Claude Code

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[Copilot]

Pull request overview

This PR hardens the Webchat HTML sanitization layer by tightening the DOMPurify allow-list, aiming to restore DOMPurify’s intended security boundary by no longer re-permitting tags/attributes that are excluded by secure defaults.

Changes:

• Removes high-risk tags (e.g., iframe, base, form, object, embed, style, meta, link) from the DOMPurify allow-list used by sanitizeHTML().
• Removes high-risk attributes (e.g., formaction, srcdoc, style, target, etc.) from the DOMPurify allow-list.
• Adds a Cypress E2E suite to guard against regressions and verify dangerous tags/attributes don’t survive sanitization.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/webchat/helper/sanitize.ts	Updates DOMPurify allow-lists to stop re-permitting tags/attributes excluded by secure defaults.
cypress/e2e/sanitize.cy.ts	Adds E2E regression tests for stripping dangerous tags/attributes and preserving safe content.

Suppressed comments (2)

cypress/e2e/sanitize.cy.ts:72

• Same issue as the <base> test: scoping the assertion to [data-cognigy-webchat-root] can miss <meta> if the browser relocates it (e.g., into head). To ensure the tag is fully stripped from the DOM, assert globally (or at least against head).

		it("strips <meta> — was in allow-list, enables HTTP redirect and CSP bypass", () => {
			typeAndSend('<meta http-equiv="refresh" content="0;url=https://attacker.example.com">');
			cy.get("[data-cognigy-webchat-root]").find("meta").should("not.exist");
		});

cypress/e2e/sanitize.cy.ts:77

• Same issue as the <base> / <meta> tests: <link> can also end up outside the widget subtree (e.g., moved into head), so asserting only within the webchat root can produce a false negative. Assert globally (or at least against head).

		it("strips <link> — was in allow-list, loads external stylesheets", () => {
			typeAndSend('<link rel="stylesheet" href="https://attacker.example.com/evil.css">');
			cy.get("[data-cognigy-webchat-root]").find("link").should("not.exist");
		});

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Dmitrii Ostasevich (kwinto)]

Three issues with this and 309, by increasing severity:

1. These PRs should be merged into one.
2. The reported issue stated in the jira ticket is not closed: this hardens the outgoing path (user messages), the report describes incoming path (bot messages). The incoming path config is in the https://github.com/Cognigy/chat-components/ repo.
3. If we actually remove this capability from the bot messages in the repo above - we can't and should not prohibit style attribute on the elements. It is used by the customers to customize message stylings. Also I remember some customers had iframe use-case previously.

If this comes as a hard requirement for the FedRAMP, we need to consider a separate, harden build of the Cognigy Webchat.

This is also relevant for the recent PRs which harden and limit the xApps iframe capabilities. We strip them of valid use-cases like geolocation for the sake of audit compliance. This would be another argument towards separate build.

Please raise these concerns with the stakeholders.

[smohite-nice]

1. we create PRs specific to issues, so 2 different PRs
2. have updated PR description: scope is for user-typed messages & not for bot
   could you please re-review? Dmitrii Ostasevich (@kwinto)

[Dmitrii Ostasevich (kwinto)]

Approving. I checked the customer blast radius carefully and it is much smaller than the diff size suggests.

Bot/Flow-authored HTML is not affected by this PR. Bot and agent message content is rendered by @cognigy/chat-components, which ships its own allowedHtmlTags/allowedHtmlAttributes and its own bundled DOMPurify. So customers whose Flows emit <iframe> video embeds, inline style, target="_blank" links, or class/id for CSS customisation are unaffected. PrivacyNotice.tsx is also safe — it feeds the sanitised text to react-markdown without rehype-raw, so raw HTML never rendered there.

That leaves only the user-typed input path, where the impact is a genuine nit.

Known minor regression, calling it out for the record. iframe and noframes are members of DOMPurify's DEFAULT_FORBID_CONTENTS, so once they leave ALLOWED_TAGS the element and its entire subtree are removed rather than unwrapped. Since <iframe> is a raw-text element, everything after a stray tag becomes its content:

in:  "Can I embed an <iframe> in my page?"
was: "Can I embed an  in my page?"
now: "Can I embed an "

Only reachable when a user literally types those tags, which realistically means developer-facing bots. Not worth blocking on. If you want it gone, pass an explicit FORBID_CONTENTS that excludes iframe/noframes — their inner text is inert once the element is stripped. (For the avoidance of doubt: the equivalent <style> behaviour already exists on main and is not introduced by this PR.)

Two documentation nits:

• The new comment at the top of the tag list says "always blocked regardless of caller configuration", but line 238 still does { ...config, ALLOWED_TAGS: customAllowedHtmlTags } — a tenant can re-permit every removed tag. #309 is what makes that statement true, so either land #309 first or soften the wording to "blocked by default". The attribute comment is accurate as written, since there is no custom-attribute setting.
• body is removed in the diff but missing from the PR description, the commit message, and the comment block. Also, html, head and title were left in the list, so the "restore DOMPurify defaults" rationale is applied inconsistently. Worth reconciling the audit trail on an SI-10 PR.

This does not close CSA-97602 on its own — see my earlier comment and my review on #309. The tenant-influenced rendering surface is @cognigy/chat-components, whose allow-list still contains iframe, object, embed, applet, frame, frameset, meta, base, link, style, form, svg, template plus action, formaction, sandbox, srcdoc, style, target, and which applies customAllowedHtmlTags with no deny-list. Please keep the ticket open, or split a follow-up, until the same hardening lands there and the dependency is bumped.

Merges cleanly with #309 (verified with git merge-tree); suggest landing this one first so #309's FORBID_TAGS becomes a pure no-op on the default path.