Webサイトのセキュリティ共通認識：15分野の対策と導入時期
認証・認可・入力検証・インジェクション対策から運用・復旧・AI固有の対策まで、Webサイトで確認したい15分野と導入時期を整理した共通認識のためのレポートです。
Webサイトのセキュリティ共通認識：15分野の対策と導入時期
このレポートの使い方
問い合わせフォームや顧客管理、外部API連携などを導入するときは、便利さと一緒に「誰が使えるか」「何を守るか」「問題が起きたらどう戻すか」を決めます。本稿は、発注担当者・開発担当者・運用担当者が確認範囲を揃えるための共通対策一覧です。
導入時期は、対策を準備・導入する目安です。導入後も、機能追加や運用の変更に応じて見直します。ログイン、DB、ファイルアップロード、AI機能など、サイトに存在しない機能は「対象外」とし、理由を記録します。
要件を体系的に確認するならOWASP ASVS
OWASP ASVS（Application Security Verification Standard）は、Webアプリケーションの技術的なセキュリティ対策を検証し、安全な開発の要件を整理するためのオープン標準です。設計・開発・テストで確認すべき内容を具体化するときの参照先になります。
以下の15分野は、開発から運用まで話し合いやすいように本稿で整理したものです。ASVSの正式な章立てや全要件を再現したものではなく、この一覧を確認しただけでASVS準拠や安全性を保証するものではありません。
OWASP公式：Application Security Verification Standard
共通セキュリティ対策一覧
1. 認証：誰が利用しているかを確かめる
導入時期：設計・実装。安全なログインとパスワード保管、MFA（多要素認証）、セッションの有効期限・ログアウト・Cookie保護を整えます。ログインだけでなく、パスワード再設定やアカウント復旧の経路も確認します。
2. 認可：利用者ごとにできることを制限する
導入時期：設計・実装。管理者・一般ユーザーなどの権限を決め、サーバー側で操作ごとに確認します。URLやリクエスト内のIDを書き換えると他人の情報へアクセスできる問題（IDOR）を防ぎます。画面のボタンを隠すだけでは権限制御になりません。
3. 入力検証：受け付ける値を決める
導入時期：実装。Zodなど、利用技術に合った方法で型・形式・長さ・許容値・サイズをサーバー側で検証します。ブラウザ側の検証は入力補助として使い、APIへの直接送信にも対応します。形式が正しいことと、アクセス権限があることは別に確認します。
4. インジェクション：入力を命令として実行させない
導入時期：実装。SQLは値を文字列連結せず、パラメータ化したクエリを使います。OSコマンドの実行は必要な場合に限定し、外部入力をそのまま渡さず、実行内容と引数を制限します。入力検証だけに依存せず、実行先に合った対策を行います。
5. XSS・CSRF：表示と操作要求を保護する
導入時期：実装。XSSには表示先の文脈に合った出力エスケープを行い、CSP（コンテンツセキュリティポリシー）を補助的に使います。Cookie認証などを使う状態変更の処理では、CSRFトークンやSameSite設定など、構成に合ったCSRF対策を組み合わせます。
6. API保護：呼び出し元と利用量を管理する
導入時期：実装。認証・認可に加えてRate Limitで過剰な呼び出しを抑え、CORSで許可するオリジンを絞ります。CORSは認証の代わりにはなりません。Webhookは提供元の仕様に従って署名を検証し、再送・重複処理への対応も決めます。
7. DB保護：データへの接続と権限を絞る
導入時期：設計・運用。アプリケーション用アカウントは必要最小限の権限にし、接続元を制限します。バックアップの取得・保管・アクセス権限も決め、DB本体と同じく保護します。
8. 秘密情報：コードや公開範囲へ出さない
導入時期：全工程。パスワードやAPIキーは秘密情報管理機能などで保管し、.envを使う場合もGit管理対象やWeb公開範囲へ含めません。.envに書くだけで安全になるわけではありません。認証情報の漏洩検出、鍵のローテーション、漏洩時の失効手順を整えます。
9. ファイル：アップロードと保存先を制御する
導入時期：必要時。許可する形式・実際の内容・容量を検査し、必要に応じてマルウェア検査を行います。保存先を公開・実行領域から分離し、ファイル名を安全に扱い、ダウンロード時にも権限を確認します。
10. 依存ライブラリ：導入後も更新を管理する
導入時期：全工程。使用するバージョンを固定・記録し、脆弱性検査と更新管理を行います。バージョン固定だけでは脆弱性は解消しないため、修正情報を確認する担当者と更新の手順を決めます。
11. サーバー：公開する範囲を最小にする
導入時期：デプロイ。HTTPS、証明書の更新、OS・ミドルウェアの更新を整え、公開ポートと管理画面へのアクセスを絞ります。本番のデバッグ表示を無効にし、エラーから内部情報が漏れないようにします。
12. GitHub：ソースと自動実行の権限を守る
導入時期：開発・デプロイ。ブランチ保護やレビューのルールを設定し、GitHub Actionsの権限を最小限にします。Secretsの参照範囲を絞り、信頼できない変更から秘密情報や本番環境へアクセスできないようにします。
13. ログ・監視：異常に気付き、対応できるようにする
導入時期：実装・運用。重要な操作履歴、認証失敗、異常なアクセスを記録し、検知・通知の条件と対応担当者を決めます。パスワード、トークン、不要な個人情報をログへ残さず、閲覧権限と保存期間も管理します。
14. 障害・復旧：戻せることを確かめる
導入時期：リリース前。バックアップからの復元テストとデプロイの巻き戻し手順を確認します。DB変更を伴う場合はコードを戻すだけで復旧できるかも確認し、復旧後にどの時点までデータが戻るかを担当者間で共有します。公開後も定期的に見直します。
15. AI固有の対策：AIの判断と実行権限を分ける
導入時期：AI機能使用時。外部文書や入力に紛れた指示でAIの動作が変わるプロンプトインジェクションを想定します。ツールの実行権限、アクセスできるデータ、送信先を制限し、権限確認をAIの出力だけに任せません。重要な操作には人の確認を設けます。
共通認識を実際の確認につなげる
各分野について「対象機能・対応状況・担当者・確認方法・次回確認日」を残します。対応状況は「未確認・対応中・確認済み・対象外」などで揃え、確認済みには根拠、対象外には理由を添えます。
例えば顧客管理画面なら、「一般ユーザーが別の顧客IDへ変更しても情報を閲覧できないことを確認する」と具体化します。「認可対策あり」という記録だけより、何を確かめたかを共有できます。
必要な対策と優先順位は、扱う情報や機能、外部サービスとの接続によって変わります。まず未確認の箇所を見えるようにし、設計時・公開前・運用中の確認を担当者と分担します。
記事の内容を相談したい方へ
ページ下部の「診断を相談する」から、お問い合わせ種別で「改善レポート内容の相談について」を選び、対象の機能と確認したい分野をお知らせください。初回のお問い合わせにパスワード、APIキー、顧客データを記載する必要はありません。