/experience-lwc-security-validate

name: experience-lwc-security-validate
description: "Use this skill as THE specialized Lightning Web Security (LWS) validator for a Lightning Web Component bundle (`.js`, `.ts`, `.html`, `.css`, `.js-meta.xml`) — the canonical LWS/Product-Security review for LWCs, NOT a generic code-security pass. It produces either a severity-ranked finding list with code-level remediations or a SARIF 2.1.0 JSON score report keyed by the `lws-001`…`lws-023b` rule catalog. TRIGGER when the user asks to review, audit, or check an LWC component for LWS compliance issues and recommend fixes, score a component's LWS/security compliance, find dangerous DOM APIs or blocked sinks (`eval`, `Function`, `document.write`, `innerHTML`, `document.createElement('script')`, global-scope assignment to `window`/`globalThis`, unsafe URL schemes), or emit a SARIF security report. DO NOT TRIGGER for generic non-LWC security review, for building a new LWC (use experience-lwc-generate), accessibility (WCAG 2.2), RTL/i18n, or Apex/Aura/server-side review."
metadata:
  version: "1.0"
  domains: ["Experience"]
  relatedSkills:
    - design-systems-slds-validate
    - dx-code-analyzer-run
    - experience-lwc-generate
  cliTools:
    - tool: ["jq"]
      semver: ">=1.6"
    - tool: ["python3"]
      semver: ">=3.8"

<!-- adk-managed-skill -->

Reviewing LWS Security

Run a structured Lightning Web Security (LWS) and Product Security compliance pass over a Lightning Web Component. Two output modes:

• **Review mode** (default) — severity-ranked findings + applied code fixes.
• **Score mode** — SARIF 2.1.0 JSON report keyed by the LWS rule catalog (`lws-001`…`lws-023b`) for downstream gating, eval scoring, or CI ingest.

Both modes use the same detection rules from the references; only the output format differs.

When to Use

• The user asks for a "security review", "LWS check", "pre-ship security audit", or "compliance pass" on a specific LWC → review mode.
• The user asks to "score" a component's security or wants machine-readable findings to feed a gate or eval → score mode.
• Preparing a component for release and needing a unified security report.
• After implementing a fix, to verify no regression in security posture.

Do NOT use this skill for:

• Building new components (use `experience-lwc-generate`).
• Accessibility (apply WCAG 2.2 separately) or RTL review — out of scope.
• Gating a fix behind a feature flag (apply feature-flag gating after fixes land).
• Non-LWC security review (Apex, Aura, server-side) — out of scope.

Prerequisites

• Component path (LWC bundle under `modules/…`).
• Access to the component's JS/TS, HTML templates, CSS, and `.js-meta.xml`.
• Output mode: `review` (default — find, fix, report) or `score` (find, emit SARIF JSON, do NOT modify code). Confirm with the user before starting if it isn't obvious from the request.

Knowledge Bases

Each reference is the source of truth. Do not summarize from memory — open the reference, apply the guidelines, and cite the specific section you used in the report.

• Lightning Web Security (LWS) catalog: [LWS Security Expert](references/lws-security-expert.md) — blocked APIs and allowed alternatives.
• Rule catalog (`lws-001`…`lws-023b`): [Product Security Framework](references/security-analysis.md) — for every rule the catalog gives the detection patterns and the canonical SARIF `ruleId` / `level` / `message` template. **Score mode emits one SARIF result per match using these exact values.**

Workflow

Step 1 — Scope the review

Collect the component path and identify the files to review. Include every file in the component bundle: `.html`, `.js`/`.ts`, `.css`, `.js-meta.xml`, and any child components owned by the same team that are invoked from the target.

Note any existing feature-flag gates — findings that require code changes must respect them.

Step 2 — Read the knowledge bases

Read [LWS Security Expert](references/lws-security-expert.md) and [Product Security Framework](references/security-analysis.md) top-to-bottom before judging. The LWS reference enumerates blocked DOM APIs and their allowed alternatives; the Product Security framework gives the severity taxonomy, the 23-rule SARIF catalog, and remediation patterns.

Step 3 — Walk the rule catalog

Run every rule in [Product Security Framework](references/security-analysis.md) (`lws-001` through `lws-023b`) against the component bundle. For each rule:

1. Apply the **"How to Find the Issue"** patterns verbatim. Do NOT shortcut — each rule lists obfuscation patterns (bracket notation, unicode escapes, `Reflect.*`, string concatenation) you must consider. 2. For every match record: `ruleId`, `level` (`error` / `warning` from the catalog), `file`, `startLine`, `startColumn` (column 1 if unknown), `message` (use the catalog's `message` template, substituting any `{placeholder}` from the actual code). 3. If a rule has the prerequisite "Only analyze files that import from 'lwc'" (lws-008), gate it via `scripts/check-lwc-import.sh <file>` — the script prints `lwc-import=yes` when a `from 'lwc'` import is present and `lwc-import=no` otherwise. Skip the rule for that file when the answer is `no`.

This catalog is the canonical detection list; the JS/TS, HTML, and `.js-meta.xml` bullets that follow are *additional* checks beyond the SARIF rules.

Step 4 — HTML template inspection (additional)

Walk each template for:

• `lwc:inner-html` usage — verify the source is trusted.
• Unescaped expressions feeding attributes LWS treats as sensitive (`href`, `src`, `srcdoc`, inline event handlers).
• Direct `style="…"` with bound expressions — candidates for CSS class swaps.
• Embedded `<iframe>` or `<object>` without sandboxing (Step 3 catches the `srcdoc` and protocol cases via lws-023a/lws-023b; this step catches missing `sandbox` attributes).

Step 5 — Meta and configuration inspection (additional)

Inspect `.js-meta.xml` for:

• Over-broad API access (`lightning__FlowScreen`, `l