experience-lwc-security-validate

LWS セキュリティのレビュー

Lightning Web Component に対して、Lightning Web Security（LWS）および製品セキュリティのコンプライアンスレビューを体系的に実施します。出力モードは 2 つあります。

• レビュー モード（デフォルト）— 重大度順の指摘事項と、適用したコード修正。
• スコア モード — 下流のゲート、評価スコアリング、または CI への取り込みに使用する、LWS ルールカタログ（lws-001…lws-023b）に対応付けられた SARIF 2.1.0 JSON レポート。

どちらのモードも、参照資料にある同じ検出ルールを使用します。異なるのは出力形式のみです。

使用する場面

• ユーザーが特定の LWC について「セキュリティレビュー」、「LWS チェック」、「リリース前のセキュリティ監査」、「コンプライアンスレビュー」を依頼した場合 → レビューモード。
• ユーザーがコンポーネントのセキュリティを「スコアリング」するよう依頼した場合、またはゲートや評価に渡す機械可読な指摘事項を必要としている場合 → スコアモード。
• コンポーネントをリリースに向けて準備し、統一されたセキュリティレポートが必要な場合。
• 修正を実装した後、セキュリティ体制にリグレッションがないことを確認する場合。

このスキルは次の場合には使用しないでください。

• 新しいコンポーネントの構築（experience-lwc-generate を使用してください）。
• アクセシビリティ（WCAG 2.2 を別途適用してください）または RTL のレビュー — 対象外です。
• フィーチャーフラグで修正をゲートする場合（修正の適用後にフィーチャーフラグによるゲートを適用してください）。
• LWC 以外のセキュリティレビュー（Apex、Aura、サーバーサイド） — 対象外です。

前提条件

• コンポーネントのパス（modules/… 配下の LWC バンドル）。
• コンポーネントの JS/TS、HTML テンプレート、CSS、.js-meta.xml へのアクセス。
• 出力モード：review（デフォルト — 検出、修正、報告）または score（検出、SARIF JSON を出力、コードは変更しない）。依頼内容から明らかでない場合は、開始前にユーザーに確認してください。

ナレッジベース

各参照資料を信頼できる情報源としてください。記憶に頼って要約せず、参照資料を開いてガイドラインを適用し、レポート内で使用した具体的なセクションを引用してください。

• Lightning Web Security（LWS）カタログ：LWS セキュリティエキスパート — ブロックされる API と許可される代替手段。
• ルールカタログ（lws-001…lws-023b）：製品セキュリティフレームワーク — 各ルールについて、カタログには検出パターンと、正規の SARIF ruleId / level / message テンプレートが記載されています。スコアモードでは、これらの値をそのまま使用して、一致ごとに 1 つの SARIF 結果を出力します。

ワークフロー

ステップ 1 — レビューの範囲を定める

コンポーネントのパスを確認し、レビュー対象のファイルを特定します。コンポーネントバンドル内のすべてのファイル（.html、.js/.ts、.css、.js-meta.xml）と、対象から呼び出される同じチームが所有するすべての子コンポーネントを含めます。

既存のフィーチャーフラグによるゲートがあれば記録してください。コード変更が必要な指摘事項には、そのゲートを反映する必要があります。

ステップ 2 — ナレッジベースを読む

判定を行う前に、LWS セキュリティエキスパートと製品セキュリティフレームワークを最初から最後まで読んでください。LWS の参照資料には、ブロックされる DOM API と許可される代替手段が列挙されています。製品セキュリティフレームワークには、重大度の分類、23 個のルールからなる SARIF カタログ、修正パターンが記載されています。

ステップ 3 — ルールカタログを確認する

Product Security Framework のすべてのルール（lws-001 から lws-023b）をコンポーネントバンドルに適用します。各ルールについて、次の手順を実行します。

1. **「問題の検出方法」**に記載されたパターンをそのまま適用します。手順を省略してはいけません。各ルールには考慮すべき難読化パターン（ブラケット記法、Unicode エスケープ、Reflect.*、文字列連結）が記載されています。
2. 一致するものがあれば、すべて次の情報を記録します。ruleId、level（カタログの error／warning）、file、startLine、startColumn（不明な場合は 1）、message（カタログの message テンプレートを使用し、実際のコードにある値で {placeholder} を置き換えます）。
3. 前提条件に「'lwc' からインポートするファイルのみを分析する」とあるルール（lws-008）については、scripts/check-lwc-import.sh <file> を使って判定します。このスクリプトは、from 'lwc' インポートがある場合は lwc-import=yes、ない場合は lwc-import=no を出力します。判定結果が no のファイルでは、そのルールをスキップします。

このカタログが検出対象の正式な一覧です。後続の JS/TS、HTML、.js-meta.xml の項目は、SARIF ルールに加えて実施する追加チェックです。

ステップ 4 — HTML テンプレートを調査する（追加）

各テンプレートについて、次の点を確認します。

• lwc:inner-html の使用箇所 — ソースが信頼できるものか確認します。
• LWS が機密情報として扱う属性（href、src、srcdoc、インラインイベントハンドラー）に値を渡す、エスケープされていない式。
• バインドされた式を含む直接指定の style="…" — CSS クラスへの置き換え候補です。
• サンドボックス設定のない埋め込み <iframe> または <object>（ステップ 3 では lws-023a／lws-023b によって srcdoc とプロトコルのケースを検出します。このステップでは sandbox 属性の欠落を検出します）。

ステップ 5 — メタデータと設定を調査する（追加）

.js-meta.xml を調べ、次の点を確認します。

• コンポーネントに不要な、過度に広範な API アクセス（lightning__FlowScreen、lightning__AppPage など）。
• 機密データを含む、公開されているプロパティ。
• 対象サーフェスに対する capabilities 制限の欠落。

Apex バインディングを調べ、次の点を確認します。

• キャッシュが安全な場合に、@AuraEnabled(cacheable=true) のない Apex メソッドへの @wire。
• 権限チェックを回避する直接的な命令型呼び出し。

ステップ 4～5 で検出した項目には、SARIF カタログとの重複を避けるため、lws-tpl-001…lws-tpl-NNN（HTML）および lws-meta-001…lws-meta-NNN（メタデータ）のルール ID を使用します。番号はレポート内の各検出項目に対して順番に割り当てます。

ステップ 6 — レポートを作成する

前提条件で確認したモードに基づいて、出力形式を選択します。

レビューモード（既定）

examples/review-report.md をテンプレートとして使用します。## Security (LWS + Product) の下に検出項目ごとに 1 つの箇条書きを記載し、## Summary の下に合計行を 1 行記載します。

重大度は、Critical → High → Medium → Low の順にします（SARIF の error は High に、warning はルールに特別な指定がない限り Medium に対応させます）。各検出項目について、その検出元となった参照セクション（例：「Product Security § lws-001 document.createProcessingInstruction」）を示します。

スコアモード

SARIF 2.1.0 の JSON ドキュメントのみを出力します。それ以外は出力しません。前後に文章を付けてはいけません。JSON をファイルに書き込まず、インラインで返します。results 配列が空であれば、問題は見つかっていません。

examples/score-report.sarif.json を構造の参考にします。同じトップレベル構造（$schema、version、runs[0].tool.driver.rules[]、runs[0].results[]）を使用し、実際に該当したルールと一致箇所を設定します。

ルール：

• ruleId は、カタログの項目（lws-001…lws-023b、またはステップ 4～5 の lws-tpl-*／lws-meta-* 名前空間）と完全に一致させます。
• level は、カタログで level: error とされているルールでは error、level: warning とされているルールでは warning にします。それ以外の値は使用しません。
• message.text には、カタログの message テンプレートを使用し、プレースホルダーを実際の値に置き換えます（例：コードで見つかった実際のイベント名で {eventName} を置き換えます）。
• 一致箇所ごとに 1 つの result を出力します。1 つのルールが 1 つのファイルで 3 回該当した場合は、3 つの result を出力します。
• tool.driver.rules には、該当したルールのみを含めます。results 配列が空の場合も、tool.driver.rules は必須です（[] を使用します）。

ステップ 7 — 修正を適用する（レビュー モードのみ）

スコア モードではスキップしてください。スコア モードは読み取り専用です。

受け入れた各指摘について、次の手順を実行します。

1. コンポーネントファイル（HTML、JS/TS、CSS、meta.xml）を編集して修正を適用します。
2. 既存の正しい動作と既存の機能フラグによるゲートを維持します。同じ懸念事項についてゲートがすでに設定されている場合は、そのままにします。段階的なロールアウトのための新しい機能フラグによるゲートは、このスキルの対象外です。別途適用してください。
3. 古いコードを黙って削除しないでください。ゲートが必要な場合は、元の処理経路を維持します。
4. テストに合格させるためにセキュリティ体制を弱めないでください。テストが安全でないパターンに依存している場合は、テストを修正してください。

ステップ 8 — 検証する

• レビュー モード：更新したファイルに対してステップ 3 のカタログ走査を再実行します。修正した指摘がすべて検出されなくなっていることを確認します。Jest テストと、コンポーネントレベルのセキュリティテストを実行します。Apex のアクセスパターンを修正した場合は、サーバーサイドのレビュアーと権限を確認します。
• スコア モード：返す前に、生成した SARIF を一時ファイルに書き込み、scripts/validate-sarif.sh <path> を実行します。このスクリプトにより、JSON が解析可能であること、version が 2.1.0 であること、各 ruleId がカタログのパターン（lws-NNN[a-z]? / lws-tpl-NNN / lws-meta-NNN）に一致し、tool.driver.rules に宣言されていること、各 level が error または warning であること、各結果に physicalLocation.artifactLocation.uri と region.startLine があることを確認します。失敗があれば、返す前に修正してください。

相互参照

• 関連スキル：
  • experience-lwc-generate — 最初からセキュリティに準拠した新しい LWC バンドルを作成する場合に使用します。
  • design-systems-slds-validate — SLDS／デザインシステムの準拠チェックです（アクセシビリティは WCAG 2.2 と重複するため、別途実行してください）。
  • dx-code-analyzer-run — リポジトリ全体の静的解析です。LWS カタログの対象範囲を超える検査には、このスキルと併用してください。

検証

• カタログの各ルール（lws-001～lws-023b）を、手動で選んだ一部ではなく、バンドル全体に対して評価しました。
• すべての指摘を適用済み（レビュー モード）または SARIF 結果に提示済み（スコア モード）にするか、理由を明記した保留の注記を付けました。
• 各指摘には特定のカタログルール ID を記載しています。「疑わしい」などの自由形式の記述はありません。
• 修正によって、新たな XSS のシンク、安全でない URL のフロー、または禁止された DOM API が導入されていません。
• スコア モードの出力は有効な SARIF 2.1.0 JSON で、周囲に説明文を付けず、インラインで返されます。