- セキュリティUtilityを共通化することは「プロジェクト全体の安全基準を一本化すること」です
- ステップ1:まず「何を共通化するか」を整理する
- ステップ2:共通化の基本方針を決める
- ステップ3:暗号化系Utilityの共通化テンプレート
- ステップ4:入力値・出力値サニタイズ系Utilityの共通化
- ステップ5:Secret管理系Utilityの共通化
- ステップ6:HTTPS通信やCSRFなどフレームワーク連携系の共通化
- ステップ7:セキュリティUtility共通化で絶対にやってはいけないこと
- ステップ8:実務的ベストプラクティス
- まとめ:セキュリティUtilityの共通化は「プロジェクト全体の安全基準をコードで表現すること」
セキュリティUtilityを共通化することは「プロジェクト全体の安全基準を一本化すること」です
業務・実務でC#を使ってシステム開発をしている読者のみなさんにとって、 暗号化、入力値サニタイズ、XSS対策、SQL Injection対策、Path Traversal対策、Secret管理など、 セキュリティに関わる処理はプロジェクトのあちこちに登場します。
もしそれぞれの画面やAPIが「バラバラのやり方」でセキュリティ処理を書いていたらどうなるでしょうか。
- ある画面ではHTMLエスケープしているが、別の画面ではしていない
- あるAPIではSQLパラメータを使っているが、別のAPIでは文字列連結している
- あるバッチではSecretを環境変数から取っているが、別のバッチではコードに直書きしている
こうした「セキュリティのばらつき」は、 脆弱性の温床になります。
そこで重要になるのが、 セキュリティUtilityを共通化して、プロジェクト全体で同じルール・同じコードを使う という発想です。
ここでは、プログラミング初心者の方にも分かるように、 セキュリティUtilityを共通化する考え方をステップバイステップで整理し、 例題・コード・テンプレートを交えて詳しく説明していきます。

