no-worker-message-innerhtml

No Worker Message Innerhtml

⚠️ Security Issue

📋 Description

Web Workers can process untrusted data from various sources. Directly rendering Worker message data via innerHTML can lead to XSS if the worker processes malicious content.

🔍 What This Rule Detects

❌ Incorrect

// onmessage handler with innerHTML
worker.onmessage = (e) => {
  element.innerHTML = e.data;
};

// addEventListener pattern
myWorker.addEventListener('message', (event) => {
  container.innerHTML = event.data;
});

// outerHTML
worker.onmessage = (e) => {
  element.outerHTML = e.data;
};

// insertAdjacentHTML
worker.onmessage = (e) => {
  element.insertAdjacentHTML('beforeend', e.data);
};

✅ Correct

// Use textContent for plain text
worker.onmessage = (e) => {
  element.textContent = e.data;
};

// Sanitize before rendering HTML
worker.onmessage = (e) => {
  const sanitized = DOMPurify.sanitize(e.data);
  element.innerHTML = sanitized;
};

// Parse and validate structured data
worker.onmessage = (e) => {
  const data = JSON.parse(e.data);
  if (isValid(data)) {
    renderData(data);
  }
};

🛠️ Options

{
  "rules": {
    "browser-security/no-worker-message-innerhtml": [
      "error",
      {
        "allowInTests": true
      }
    ]
  }
}

💡 Why This Matters

Workers process data in the background, often from external sources like APIs or uploaded files. If this data contains malicious HTML/JavaScript and is rendered without sanitization, it enables XSS attacks.

Worker Data Sources to Consider:

1. API responses: Validate server data
2. File processing: Sanitize file contents
3. Third-party integrations: Never trust external data

Rule ownership

This rule fires only when the receiver is positively identified as a new Worker(...) or new SharedWorker(...) in the same file. X.onmessage = … on a receiver this file cannot resolve is not evidence of Worker — it is unknown, and unknown belongs to no-innerhtml / no-eval, which report it without claiming a provenance they cannot prove.

The two tests are complements, so exactly one rule reports any given value. Before this gate both fired at the identical range in recommended.

A receiver that arrives as a parameter or from another module therefore falls to the generic rule. That is deliberate: the alternative is guessing.

Known False Negatives

The following patterns are not detected due to static analysis limitations:

Event Data Stored in Variable

Why: Data stored in variables not traced.

// ❌ NOT DETECTED - Data stored first
worker.onmessage = (e) => {
  const html = e.data;
  element.innerHTML = html;
};

Mitigation: Always sanitize before any assignment.

Handler in External Function

Why: External handlers not analyzed.

// ❌ NOT DETECTED - External handler
worker.onmessage = processWorkerMessage;

Mitigation: Apply rule to handler implementations.

Custom Sanitizer

Why: Non-standard sanitizers may not be recognized.

// ❌ NOT DETECTED - Custom sanitizer
element.innerHTML = mySanitize(e.data);

Mitigation: Configure trusted sanitizer names.

📚 Related Resources

• MDN: Web Workers
• DOMPurify
• OWASP XSS Prevention

Error Message Format

The rule provides LLM-optimized error messages (Compact 2-line format) with actionable security guidance:

⚠️ CWE-79 OWASP:A05 CVSS:6.1 | Cross-site Scripting (XSS) detected | MEDIUM [SOC2,PCI-DSS,GDPR,ISO27001]
   Fix: Review and apply the recommended fix | https://owasp.org/Top10/A05_2021/

Message Components