Webセキュリティでやってはいけない判断集【実務で見たNG例】

本記事では、筆者がセキュリティレビューや実務開発の中で実際に遭遇した 「やってはいけない判断」 を整理します。単なる理論ではなく、現場で「NG」と突きつけられたリアルな事例をもとに、なぜその判断が危険なのか、どう判断すべきだったのかを深く掘り下げます。

本記事を読むことで、「なぜその判断がNGなのか」をロジカルに説明できるセキュリティ視点が身につきます。

1. NG「SameSite=Lax を設定しているから CSRF は防げている」

#

これは近年、**最も多く見かける「誤解」**のひとつです。

なぜNGか：Laxの「例外」を理解していない

#

2020年以降、Chromeなどの主要ブラウザで SameSite=Lax がデフォルトとなりました。これにより多くのCSRFが防げるようになったのは事実ですが、Laxは万能の盾ではありません。

Laxには「ユーザーが外部リンクをクリックした際（トップレベルナビゲーション）の GET リクエストには Cookie を送信する」という仕様があります。

脆弱性が残るシナリオ

#

• 副作用のあるGETメソッド: /api/delete-user?id=123 のような、GETでデータを変更するエンドポイントがある場合、リンクを踏ませるだけで攻撃が成立します。
• ブラウザの互換性: 一部の古いブラウザや、特定の条件下でのリダイレクト時など、Laxの挙動が期待通りにならないケースがあります。

正しい判断

#

• CSRFトークン（Synchronizer Token Pattern）による検証を主軸に置く。
• SameSite 属性はあくまで「Defense in Depth（多層防御）」の一環として、補助的に利用する。

2. NG「管理画面はIP制限とログイン必須にしているから安全」

#

なぜNGか：攻撃の「起点」は外部にある

#

CSRFやXSS（クロスサイトスクリプティング）は、攻撃者が直接管理画面にアクセスできなくても成立します。

攻撃のシナリオ：

1. 管理者が、ログインした状態で別のタブで悪意のあるサイトを開く。
2. そのサイトに仕込まれたスクリプトが、管理者のブラウザ経由で POST /admin/delete-database を投げる。
3. サーバーは「管理者からの正規のリクエスト」として処理してしまう。

IP制限やログイン認証は「誰がアクセスできるか」を制限するものであり、「リクエストが本人の意図したものか」を保証するものではありません。

正しい判断

#

• 管理画面こそ、最も厳格なセキュリティ対策（CSRFトークン、追加認証など）を適用すべき領域である。
• 重要な操作（ユーザー削除、設定変更、一括処理）には、操作直前の再認証（パスワード再入力やMFA）を挟む。

3. NG「内部向けツールなのでセキュリティ要件は低くて良い」

#

なぜNGか：侵害の拡大（ラテラルムーブメント）の温床

#

現代のセキュリティ設計は 「境界防御の崩壊」 を前提としています。

• フィッシングやマルウェア: 社内の一人のPCが感染すれば、そこから「内部ネットワーク」として全てのシステムにアクセスされます。
• 内部不正: 権限管理が疎かな内部ツールは、情報漏洩の格好の標的になります。

正しい判断

#

• ゼロトラスト（Zero Trust）の原則: ネットワークの場所（内部/外部）で信頼を判断せず、常に認証・認可を厳格に行う。
• 最小権限の原則（PoLP）を徹底し、被害範囲を最小限に抑える設計にする。

4. NG「GETリクエストでステートを変更している（仕様上仕方ない）」

#

なぜNGか：意図しない実行経路が多すぎる

#

GETメソッドは「安全（副作用がないこと）」がHTTP仕様上の前提です。これを破ると、以下のような予期せぬ挙動に悩まされることになります。

• プリフェッチ（先読み）: ブラウザや検索エンジンがURLを先読みしただけでデータが削除される。
• チャットツールのプレビュー: SlackやTeamsにURLを貼った瞬間、ボットがアクセスして処理が実行される。
• キャッシュサーバー: プロキシやCDNがレスポンスをキャッシュし、2人目以降に削除完了画面が表示される（が実際は削除されていない）といった不整合。

正しい判断

#

• 副作用を伴う操作には必ず POST / PUT / PATCH / DELETE を使用する。
• GETメソッドは「データの取得」のみに限定する。

5. NG「セキュリティは開発の最後にペンテスト（診断）で直せばいい」

#

なぜNGか：手戻りコストの爆増と「詰み」の発生

#

開発の最終段階で致命的な脆弱性（例：根本的なアーキテクチャに起因する認可不備など）が見つかると、リリース延期は避けられません。また、場当たり的な修正は新たなバグを生みます。

正しい判断

#

• シフトレフト（Shift Left）: 要件定義や設計の段階からセキュリティレビューを組み込む。
• 開発の初期段階で「認証・認可・CSRF対策」の共通基盤を固める。

セキュリティレビュー時のチェックリスト

#

実務で判断に迷った際、以下の観点を確認してください。

まとめ：セキュリティは「仕様」である

#

Webセキュリティにおける事故の多くは、高度なハッキング技術によるものではなく、開発現場での「これくらいなら大丈夫だろう」という判断の積み重ねから起こります。

• 「一応やっている」
• 「多分大丈夫」
• 「今まで問題なかった」

これらは、セキュリティ判断において最も危険な言葉です。本記事で紹介したNG例に一つでも心当たりがあれば、ぜひ設計と実装を見直してみてください。

セキュリティは「後付けの機能」ではなく、アプリケーションの根幹をなす「仕様」そのものです。

📘 関連記事

#

• CSRF対策の具体的手法：トークンからSameSiteまで
• 開発速度 vs セキュリティ、どちらを優先すべきか？
• React Server Components の脆弱性解説（CVE-2025-55182）

🔗 参考リンク

#

• OWASP Top 10
• 安全なウェブサイトの作り方（IPA）