【実務・中級編】AngularのSanitizerサービスとセキュリティコンテキスト – アプリケーションセキュリティ & 安全な開発防御ガイド

Angularの「自動サニタイズ」を過信するな：XSSの入り口を塞ぐ実務的アプローチ

現場でコードレビューをしていると、必ずと言っていいほど耳にする言葉がある。「Angularを使っているからXSS（クロスサイトスクリプティング）は大丈夫ですよね？」。

結論から言おう。それは半分正解で、半分は致命的な勘違いだ。

Angularの強力な武器である「自動サニタイズ」は、確かにフレームワーク側で提供するテンプレートバインディングにおいては非常に優秀な防壁だ。しかし、攻撃者はその「防壁の隙間」を嗅ぎ分けるプロフェッショナルである。今回は、Angularの防御機構の裏側を覗き、なぜ開発者が「意図的に」脆弱性を生み出してしまうのか、そのメカニズムと完全な防御策を共有する。

—

1. 自動サニタイズの限界と「信頼された値」の罠

Angularの DomSanitizer は、テンプレートに値を挿入する際、その値が「安全なコンテキスト（HTML, Style, URLなど）」に含まれているかを確認し、危険な文字列（等）の実行をブロック。

object-src 'none': Flash等の古いプラグインによる攻撃を防止。

---

セキュリティチーフからのアドバイス

「動くものを作る」のはエンジニアの最低条件だが、「壊されないものを作る」のがプロの仕事だ。

Angularのサニタイズ機能は強力なツールだが、決して万能ではない。特に、バックエンドからのデータ入力や、動的なDOM操作が絡む部分には必ず「疑いの目」を持ってほしい。セキュリティは機能開発の最後に行うものではなく、設計段階からコードの端々に埋め込むものだ。

もしチーム内で「このbypassメソッド、使っても大丈夫？」という議論が起きたら、まずは「それが本当に必要か？代替手段はないか？」を徹底的に問うてみてほしい。その泥臭い議論こそが、インシデントゼロへの近道になるはずだ。