2.onclick / onchange インラインハンドラを addEventListener に移行する
サーバー側のバリデーション・サニタイズと、ブラウザ側のCSPの両方が必要
- グループA：サイドバー（id 付き → そのまま addEventListener）
- グループB：サイドバー（id なし → id を付与してから addEventListener）
- グループC：ページタブバー（id なし → id 付与）
- グループD：ナビバー（Blade 条件分岐内）
施工計画のエディット画面（edit_section_blade.php）が、ほぼ実装が完了したので、再びコードの検証を行う・・・やはり、まだ課題が多く残っていたので、順にコードの手直しをする
1.生HTML出力（{!! !!}）を使用している
{!! !!} はエスケープなしの生出力のため、$headerHtml / $footerHtml がDB経由で、悪意あるスクリプトを含む場合、XSS攻撃が成立する。
サーバーサイドでのサニタイズ（無害化）状況を確認し、不十分であれば修正する・・・XSS（クロスサイトスクリプティング）、SQLインジェクション・・以下はサニタイズの手法
| 手法 | 内容 |
|---|---|
| エスケープ | 特殊文字を無害な表現に変換（< → <） |
| 除去 | 危険な文字・タグを削除 |
| バリデーション | 想定外の値を拒否（数字のみ受け付けるなど） |
| プレースホルダ | SQLをコードと分離して処理 |
これらの手法は、Laravelでは多くは自動で処理してくれるが、施工計画のSVGダイアグラムエディタのような自前JS処理部分は別途確認が必要
1-1.データの流れを追跡する
- コントローラを特定する（ルート名 project_plans.sections.editから逆引きする）
- $headerHtml / $footerHtml の生成箇所を特定する
- DBカラムの確認
1-2.現状の判定（サニタイズ処理必要性の検証）
- ✅ 安全なケース（修正不要）
- ❌ 要修正なケース（対応する、入力時サニタイズ、HtmlPurifier の導入確認、サービスクラスまたはヘルパーの作成、コントローラの保存処理にサニタイズを追加、既存DBデータの一括サニタイズ（Artisan コマンド））
1-3.実施結果
Claude Codeでの実施結果ではOK、変更なし、コメントを追記