Experience Lwc Security Validate

<!-- 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 — blocked APIs and allowed alternatives.
• Rule catalog (lws-001…lws-023b): Product Security Framework — 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 and Product Security Framework 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 (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, lightning__AppPage, etc.) when the component doesn't need it.
• Public properties exposed that contain sensitive data.
• Missing capabilities restrictions for the target surface.

Inspect Apex bindings for:

• @wire to Apex methods without @AuraEnabled(cacheable=true) where caching is safe.
• Direct imperative calls that bypass permission checks.

Findings from Steps 4-5 use rule IDs lws-tpl-001…lws-tpl-NNN (HTML) and lws-meta-001…lws-meta-NNN (meta) — sequence numbers per finding within the report — so they don't collide with the SARIF catalog.

Step 6 — Produce the report

Pick the output format based on the mode confirmed in Prerequisites.

Review mode (default)

Use examples/review-report.md as the template — one bullet per finding under ## Security (LWS + Product), one totals line under ## Summary.

Severity ordering: Critical → High → Medium → Low (map SARIF error → High, warning → Medium unless the rule says otherwise). Cite the reference section that produced each finding (e.g., "Product Security § lws-001 document.createProcessingInstruction").