fix(security): bump dompurify to patch DOM XSS advisory

[hitesh-shetty-cstk]

What the vulnerability was

Snyk SCA flagged dompurify@3.4.13/3.4.14 as vulnerable to a Cross-site Scripting (XSS) advisory. dompurify is a direct runtime dependency here.

Note: an earlier open PR (#634, dependabot) bumps dompurify to 3.4.13, which does not reach the fixed version — this PR supersedes that with a sufficient bump.

What the fix does

Bumps dompurify from ^3.4.13 to ^3.4.16 in package.json, and updates the corresponding node_modules/dompurify entry (version/resolved/integrity) plus the root package's declared range in package-lock.json to match.

How it was verified

• Confirmed dompurify is a direct dependency in package.json.
• Confirmed 3.4.16 satisfies the package's existing semver usage.
• No overrides/resolutions block added — direct version bump only.
• No build/test run, per the minimal-fix policy for this pass.

---

🤖 Generated with Claude Code

---

Generated by 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
✅	Code Security	0	0	0	0	0 issues

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

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	0	0	25	✅ Passed
🟡 Medium Severity	0	0	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

✅ BUILD PASSED - All security checks passed

[Copilot]

Copilot review overview

🟢 Approval recommended

The dependency declaration and lockfile metadata are consistent, with no unresolved issues found.

Review effort: Balanced
Findings: None

What changed in this PR

Updates the direct DOMPurify runtime dependency to a version containing the XSS security fix.

Changes:

• Bumps DOMPurify from ^3.4.13 to ^3.4.16.
• Synchronizes resolved package and integrity metadata.

File	Description
package.json	Updates the dependency range.
package-lock.json	Locks DOMPurify 3.4.16 and updates metadata.

---

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

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	68.26%	2564 / 3756
🔵	Statements	67.12%	2605 / 3881
🔵	Functions	65.66%	461 / 702
🔵	Branches	62.58%	1547 / 2472

File Coverage

No changed files found.

Generated in workflow #929 for commit eb53cc9 by the Vitest Coverage Report Action

[hitesh-shetty-cstk]

Automated review

What this changes: Raises the dompurify range in package.json from ^3.4.13 to ^3.4.16 and updates the one matching entry in package-lock.json (version, resolved URL, integrity). No source file changes. The single call site, sanitizeData in src/visualBuilder/utils/collabUtils.ts, is untouched.

I checked the lockfile edit against the npm registry rather than taking it on trust:

• dompurify@3.4.16 exists and is the current latest.
• The integrity hash in the lockfile matches the registry's published hash for 3.4.16 exactly, as does the resolved tarball URL. This is the check that matters most on a hand-edited lockfile.
• There is one dompurify entry in the lockfile, now at 3.4.16, and packages[""].dependencies agrees with package.json. A partial bump leaving a second entry on the old version is the usual failure mode here and it is not present.
• lockfileVersion is 3, so no legacy dependencies block needs a parallel edit.

One note on what the manifest bump actually buys, because it is easy to read it as doing more or less than it does. ^3.4.13 already permitted 3.4.16, so a fresh install was resolving to a patched version regardless. What this adds is a floor, so a consumer cannot land on 3.4.13 or 3.4.14 from a stale lockfile, a pinned resolution, or an offline cache. That is the right lever for this repo: tsup.config.js sets no noExternal, and tsup leaves dependencies external by default, so dompurify stays an import in dist and each consumer resolves it from the declared range.

Business impact: None identified. The change does reach customers through the published package's dependency range, so it is fair to treat as customer-facing, but a patch-level dompurify bump carries no expected behavior change. The only call site passes USE_PROFILES: { html: true } and strips remaining tags before using the result.

Security: Remediation rather than a new finding. Snyk and the org security workflow both report clean on this head, and I found nothing they miss. The supply-chain question specific to an edited lockfile, whether the integrity hash matches the real published artifact, I verified directly against the registry.

Flow

No flow change. A dependency bump with no altered control flow or message path.

Findings: 0 blocker, 1 should fix, 1 nit. The should-fix is inline on package.json. The nit is here, because it concerns a different pull request and has no honest line to anchor to.

Nit: #634 is still open. It is lockfile-only and moves dompurify from 3.4.12 to 3.4.13, below the floor this sets. It edits the same lockfile lines, so it cannot merge quietly after this one, and Dependabot normally closes its own pull request once the dependency moves past its target. Worth closing by hand if it does not.

Reviewer candidates: @kirtesh-cstk authored 8 of the last 30 commits on package.json. @csAyushDubey authored 6.

Not covered: I did not run the build, the unit tests, or an install. The test check was still in progress when I read it; the other checks on this head had passed. I could not independently confirm the advisory's affected range or its first patched version, because both advisory databases I tried were unreachable from this run. That part rests on Snyk's clean result for this head rather than on my own reading of the advisory record.

Automated review by Claude Code. A human review is still required.

---

Generated by Claude Code