本記事は、僕がWebアプリ開発を通じて学び・実践してきた脆弱性と確認項目のメモを、整理して公開するものです。
以下のような方におすすめです：
- セキュリティ対策を自己チェックしたい Web 開発者の方
- コードレビュー時にセキュリティ観点の漏れを防ぎたいエンジニアの方
現時点では網羅性は十分ではありませんが、今後のアップデートを通じて少しずつ内容を充実させていく予定です。
各脆弱性については、確認項目・内容・なぜ重要かの3点を軸に、チェックリスト形式で整理しています。
実装後のセルフチェックやレビュー前の確認などに、ぜひご活用ください。
📌 各脆弱性とチェックポイント
共通する確認観点（入力バリデーション、サニタイズ、セッション管理など）は「セーフティネット（共通防御）」で一元管理し、個別脆弱性の節ではリスクと関連付けて簡潔に記載します。
🖋️ セーフティネット（共通防御）
| 確認項目 |
内容 |
なぜ重要か |
| 入力の妥当性 |
文字数・型・範囲をサーバー・クライアント両方で制限しているか。 |
型や範囲が不正だと、XSS、SQLi、DoSなどの入り口になる。 |
| 正規表現やフォーマット検証 |
メール・URL・数値・識別子などの入力に適切な形式制限をかけているか。 |
不正な形式がシステムに流入することで、後続の処理に影響を与える。 |
| サニタイズ・エスケープ処理 |
出力時（HTML/JavaScript/SQL/コマンド等）に文脈に応じた処理がされているか。 |
文脈に合わない処理では、XSSやインジェクションが防げない。 |
| サーバー側でも検証 |
クライアント側検証のバイパスを前提に、同等のチェックをサーバーでも行っているか。 |
JSを無効化されたり、ツールで送られるとフロント検証は無効になる。 |
| 多層防御の設計 |
入力検証、出力エスケープ、DB権限、CSPなど複数の防御が併用されているか。 |
1つの防御が破られても、他の層で食い止めることができる。 |
| CSRF対策 |
トークンによる正当性確認があるか（詳細はCSRF項参照）。 |
正規のユーザーの操作と不正なリクエストを区別する基礎になる。 |
| コメントによる情報漏えい |
コメントや hidden 属性など、画面上では見えない部分にパスワードやアカウント情報、ライブラリ名などを記述しないこと |
攻撃者に解析されると機密情報が漏洩するリスクがある。 |
| デバッグ機能の作り込み禁止 |
テスト用のチートなど特殊な事情を除き、不要なデバッグ機能を開発・本番反映しないこと |
URLパラメータや裏機能が攻撃者に悪用される可能性がある |
🖋️ クリックジャッキング
| 確認項目 |
内容 |
なぜ重要か |
| X-Frame-Options / CSP |
iframe 埋め込みを防ぐ設定があるか。 |
攻撃者が正規ページを透明に表示し、ユーザーに誤クリックを誘導する攻撃を防ぐ。 |
| UIの二重確認 |
重要操作の前に確認画面・2FAがあるか。 |
クリックを強制されても操作の前に止められる可能性がある。 |
| サードパーティiframe制限 |
外部から埋め込み可能なiframeが制限されているか。 |
攻撃者が自サイトに取り込んで悪用するのを防げる。 |
🖋️ クロスサイトスクリプティング（XSS）
| 確認項目 |
内容 |
なぜ重要か |
| 出力エスケープ |
ユーザー入力をHTMLやJSで出力する際に適切に処理しているか。 |
エスケープ不足はスクリプト実行につながる。 |
| CSPの導入 |
インラインスクリプト・外部スクリプトの制限があるか。 |
被害を局所化し、スクリプト実行の成功率を下げられる。 |
| URLパラメータの処理 |
表示に使われるパラメータは、出力前に処理されているか。 |
リフレクト型XSSの原因になりやすい。 |
🖋️ SQLインジェクション
| 確認項目 |
内容 |
なぜ重要か |
| パラメータ化クエリ |
プレースホルダやプリペアドステートメントを使用しているか。 |
入力とSQL構文を分離することで、構文挿入を防止できる。 |
| DBユーザーの権限制限 |
アプリケーションが使うDBユーザーに不要な権限がないか。 |
インジェクション成功時の被害範囲を限定できる。 |
| エラーメッセージの制御 |
SQLエラーが詳細に出力されていないか。 |
テーブル名や構造のヒントを攻撃者に与えてしまう。 |
🖋️ OSコマンド・インジェクション
| 確認項目 |
内容 |
なぜ重要か |
| コマンドの固定 |
入力によってコマンド構造が変わらない設計になっているか。 |
入力でコマンド構成を変えると任意コマンドの実行に繋がる。 |
| 外部ライブラリの使用 |
シェルコマンド実行ではなくAPI・ライブラリを使っているか。 |
コマンド構築時のリスクを根本的に排除できる。 |
| 実行権限の制限 |
コマンド実行ユーザーに最小限の権限しか与えられていないか。 |
実行された場合の被害範囲を限定できる。 |
🖋️ evalインジェクション
| 確認項目 |
内容 |
なぜ重要か |
| evalの使用回避 |
eval() や Function() などを使用しない設計にしているか。 |
入力を評価することで、任意のコードが実行されるリスクがある。 |
| 入力ソースの限定 |
実行対象の値が内部に固定された安全な値か。 |
外部から入力された値を評価すると、意図しない実行が起こる。 |
| 安全な代替手段 |
JSON.parse や switch文などで代替できないかを検討しているか。 |
より明示的で安全な構文を使うことでリスクを抑えられる。 |
🖋️ ディレクトリ・トラバーサル
| 確認項目 |
内容 |
なぜ重要か |
| パスの正規化 |
../ やエンコード形式のパスが除去・検証されているか。 |
システムファイルや意図しないファイルへのアクセスを防ぐ。 |
| ホワイトリストの適用 |
読み込み可能なファイルを事前に限定しているか。 |
任意のパスを指定できる状態は危険。 |
| ファイル種類の制限 |
許可された拡張子以外は読み込めないようにしているか。 |
設定ファイルやコードファイルの漏洩防止。 |
🖋️ ファイルアップロードの脆弱性
| 確認項目 |
内容 |
なぜ重要か |
| 拡張子・MIME制限 |
拡張子およびMIMEタイプをホワイトリストで制限しているか。 |
スクリプトのアップロードを防止する。 |
| 保存先の制限 |
アップロードファイルがWeb公開ディレクトリ内に保存されていないか。 |
ファイルが直接アクセスされると実行されるリスクがある。 |
| 実行権限の無効化 |
アップロードファイルに実行権限が付与されていないか。 |
アップロード→実行の流れを防ぐ。 |
| ファイル名のサニタイズ |
入力されたファイル名から ../ などを排除しているか。 |
パスの乗っ取りや上書きを防止できる。 |
🖋️ ファイルインクルード攻撃
| 確認項目 |
内容 |
なぜ重要か |
| インクルード対象の検証 |
ユーザー入力によって読み込まれるファイルがホワイトリストに限定されているか。 |
任意のファイルを読み込まれると、コード実行につながる。 |
| 外部URL禁止 |
http:// など外部のファイルを読み込めない設定か。 |
リモートファイルインクルード（RFI）によるコード実行リスクがある。 |
| アップロードされたファイルの検証 |
ユーザーがアップロードしたファイルがインクルードされていないか。 |
任意ファイル実行のトリガーになる。 |
🖋️ クロスサイト・リクエストフォージュリ（CSRF）
| 確認項目 |
内容 |
なぜ重要か |
| CSRFトークンの導入 |
状態変更を伴うリクエストにトークンが含まれているか。 |
攻撃者がユーザーの操作を偽装するのを防げる。 |
| トークンの検証 |
トークンがセッションと紐付いて正しく検証されているか。 |
トークンがあっても検証しないと意味がない。 |
| SameSite属性 |
クッキーに SameSite 属性が設定されているか。 |
外部サイトからのリクエストにクッキーが送信されなくなる。 |
🖋️ セッションハイジャック
| 確認項目 |
内容 |
なぜ重要か |
| セッションIDのSecure/HttpOnly属性 |
セッションIDがCookieに格納され、安全に送信・読み取り制限されているか。 |
ネットワーク傍受やXSSによる漏洩を防げる。 |
| セッションの有効期限 |
無期限ではなく、一定時間で自動ログアウトされる設計か。 |
乗っ取られたセッションの長期利用を防ぐ。 |
| セッション固定対策 |
ログイン時にセッションIDが再生成されているか。 |
固定されたセッションIDの悪用を防げる。 |
| 2FAの導入 |
重要操作時に多要素認証が実装されているか。 |
セッションが乗っ取られても、完全な操作を防止できる。 |
🖋️ オープンリダイレクト
| 確認項目 |
内容 |
なぜ重要か |
| リダイレクトURLの検証 |
next パラメータなどが正規のドメインに限定されているか。 |
攻撃者が悪意ある外部サイトへリダイレクトできなくなる。 |
| 相対パス限定 |
リダイレクト先は /dashboard のような相対パスに限定されているか。 |
絶対URLを指定できると外部誘導の危険がある。 |
| リダイレクト確認表示 |
リダイレクト前にユーザーへの通知画面があるか。 |
不正な誘導に気づくチャンスをユーザーに与える。 |
✅ まとめ
Webアプリのセキュリティ対策は、「わかっているつもり」でも、実装やコードレビューの現場でどれだけ意識できているかがとても重要だと感じています。
組織内でセキュリティに関するコーディングルールが整備されていても、運用の中で漏れが生じることは珍しくありません。だからこそ、「一度作って終わり」ではなく、実際の改善サイクルを回していくことが大切です。
例えばCTOやチームリーダー、あるいは外部のセキュリティベンダーなど、一部の人にセキュリティ観点を任せきりにしてしまうと、対策が浸透しにくくなるように思います。
気づいた人が改善を提案し、チーム全体で「なぜそれが重要なのか？」を共有・考えることが、実効性ある対策につながるように思います。
本記事では、代表的な脆弱性ごとに確認項目とその理由（なぜ重要か） を整理しました。
改善提案の場面では、「なぜそれが必要か？」を言語化できること自体が信頼につながると思います。
ぜひご自身でも「なぜ重要か」を一緒に考えてみてください。
Discussion