Fix XSS vulnerabilities in Wix integration examples

[Copilot]

The Wix example custom elements used innerHTML with unsanitized attribute values interpolated via template literals, allowing arbitrary HTML/JS injection. The inline onclick in capture-eye-sytle-element.js also constructed a URL directly from a raw attribute value.

Changes

examples/wix/capture-eye-element.js

• Replaced innerHTML template literal with createElement + setAttribute for both capture-eye and media-viewer

examples/wix/capture-eye-sytle-element.js

• Replaced innerHTML block with explicit DOM construction; all text set via textContent
• Replaced inline onclick="window.open('.../${_nid}'...)" with addEventListener('click', ...) using encodeURIComponent(_nid)
• Content reset via removeChild loop instead of innerHTML = ''

Before:

elem.innerHTML = `<capture-eye nid="${_nid}">
  <img src="${thumbnail}" ...>
  <p class="nid" onclick="window.open('https://asset.captureapp.xyz/${_nid}', '_blank')">${nid}</p>
  ...
</capture-eye>`;

After:

const captureEye = document.createElement('capture-eye');
captureEye.setAttribute('nid', _nid);

const img = document.createElement('img');
img.setAttribute('src', thumbnail);

const nidP = createParagraph('nid', nid); // uses textContent internally
nidP.addEventListener('click', () => {
  window.open(`https://asset.captureapp.xyz/${encodeURIComponent(_nid)}`, '_blank');
});

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Security][High] XSS vulnerabilities in Wix integration examples via unsanitized innerHTML</issue_title>
<issue_description>## Summary

The Wix integration example files contain XSS vulnerabilities through direct use of innerHTML with unsanitized attribute values. While these are example files (not production source), they serve as copy-paste templates for Wix integrators, propagating XSS vulnerabilities to downstream implementations.

Affected Files

examples/wix/capture-eye-element.js (line 5)

this.innerHTML = `<capture-eye nid="${nid}"><media-viewer src="${thumbnail}"/></capture-eye>`;

nid and thumbnail come directly from DOM attributes and are interpolated into HTML via template literals without sanitization.

examples/wix/capture-eye-sytle-element.js (lines 23, 32)

elem.innerHTML = `<capture-eye nid="${_nid}"><div class="container"><img src="${thumbnail}"...>${captureUpdatedDate}...${creator}...${headline}...`;

Multiple user-controlled values (_nid, thumbnail, captureUpdatedDate, creator, headline) are interpolated directly into HTML. Line 32 also has an inline onclick handler constructing a URL from _nid.

Impact

An attacker who controls these attribute values (e.g., via URL parameters passed to Wix custom elements) can inject arbitrary HTML and JavaScript. This affects any Wix site using these examples as templates.

Suggested Fix

Replace innerHTML usage with safe DOM construction:

• Use createElement + textContent for safe attribute assignment
• Use setAttribute instead of string interpolation for element attributes
• At minimum, add prominent security warnings in the example code and sanitize all interpolated values
• Consider providing a sanitization utility function in the examples

References

• OWASP XSS Prevention Cheat Sheet
• Related: [Security] Unvalidated API-sourced URLs in href attributes enable potential javascript: protocol XSS #77 (Unvalidated API-sourced URLs), [Security] XSS vulnerability in WordPress Elementor widget due to unescaped output #64 (XSS in WordPress Elementor widget)

Generated by Heart Beat with Omni</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [Security][High] XSS vulnerabilities in Wix integration examples via unsanitized innerHTML #96

---

⌨️ Start Copilot coding agent tasks without leaving your editor — available in VS Code, Visual Studio, JetBrains IDEs and Eclipse.