HOME > 技術ドキュメント > Webアプリケーションのセキュリティ基本設計

Webアプリケーションのセキュリティ基本設計

執筆：株式会社エスロジカル（Webシステム受託開発・セキュリティ設計・インフラ構築）

「セキュリティは後から追加する」という考え方は通用しなくなっています。 個人情報保護法・不正アクセス禁止法・経済産業省のセキュリティ対策基準など、 Webシステムには設計段階からセキュリティを組み込む義務があります。
本記事では、Webアプリケーションのセキュリティ設計で押さえるべき観点を体系的に整理します。

1. セキュリティ設計の3原則

• 最小権限の原則（Least Privilege）：ユーザー・プロセス・DB アカウントに必要最小限の権限のみを与える。 アプリ用 DB ユーザーに DROP TABLE 権限は不要です。
• 多層防御（Defense in Depth）：1 つの対策が破られても次の層で防げる構成にする。 WAF だけに頼らず、アプリ側でもバリデーション・エスケープを実装します。
• フェイルセキュア（Fail Secure）：エラー発生時に安全側に倒す。 認証エラーは「ログイン失敗」と返し、詳細なエラー情報（スタックトレース・SQL 文）を外部に見せない。

2. 認証・セッション管理

認証の脆弱性はシステム全体を無効化するため、最も慎重に設計します。

• パスワードの保存：平文・MD5・SHA-1 は絶対に使わない。bcrypt / Argon2 / scrypt でストレッチングする。
• セッションID：推測不能な乱数で生成し、ログイン後に必ず再発行する（セッション固定攻撃の防止）。
• セッションの有効期限：アイドルタイムアウト（例：30 分）とセッション最大有効期間（例：24 時間）の両方を設定する。
• 多要素認証（MFA）：管理者画面・金融系処理には MFA を必須にする。
• アカウントロック：連続ログイン失敗（例：5 回）でロックし、ブルートフォース攻撃を防ぐ。

3. 入力バリデーションと SQL インジェクション対策

• プレースホルダーの徹底：SQL 文にユーザー入力を直接文字列結合しない。すべてのクエリにプリペアドステートメントを使う。
• 入力バリデーション：型・長さ・形式（メールアドレス・日付など）をサーバー側で検証する。クライアント側の JS バリデーションだけでは不十分。
• パス・コマンドインジェクション：ユーザー入力をファイルパスやシェルコマンドに使う場合は特に慎重に。可能な限りホワイトリスト方式で制御する。

4. XSS（クロスサイトスクリプティング）・CSRF 対策

• XSS 対策：HTML 出力時にはエンティティエスケープを徹底する（&, <, >, ", '）。 テンプレートエンジン（Jinja2・Blade・Go の html/template 等）の自動エスケープを有効にし、意図的に無効化しない。
• CSP（Content Security Policy）：レスポンスヘッダーに CSP を設定し、外部スクリプトの読み込みを制限する。
• CSRF 対策：状態変更を行うフォームには CSRF トークンを埋め込む。 SPA では SameSite Cookie 属性（Strict / Lax）の設定も有効。

5. HTTPS/TLS：全通信の暗号化

ログイン・個人情報・決済など機密性の高い通信に限らず、サイト全体を HTTPS で提供することが現在の標準です。

• TLS 1.2 以上を使用し、TLS 1.0 / 1.1 は無効化する
• HTTP から HTTPS への 301 リダイレクトを設定する
• HSTS（Strict-Transport-Security）ヘッダーを設定し、ブラウザに HTTPS 接続を強制する
• SSL 証明書は有効期限切れの前に確実に更新する

企業サイト・EC・個人情報を扱うシステムでは OV 以上の有料証明書を推奨します。
SSL証明書の一覧・購入はこちら /  DV・OV・EV の違い /  SSL証明書 FAQ

6. セキュリティヘッダーの設定

Nginx や Apache のレスポンスヘッダーに以下を設定することで、ブラウザ側での防御を強化できます。

ヘッダー	効果
Strict-Transport-Security	HTTPS 強制（HSTS）
Content-Security-Policy	XSS・不正スクリプト読み込みの制限
X-Content-Type-Options: nosniff	MIME タイプスニッフィング防止
X-Frame-Options: DENY	クリックジャッキング防止
Referrer-Policy	リファラ情報の漏えい制限
Permissions-Policy	カメラ・マイク等のブラウザ機能の利用制限

7. WAF と DDoS 対策

• WAF（Web Application Firewall）：SQL インジェクション・XSS などの攻撃パターンをネットワーク層で遮断。 AWS WAF・Cloudflare WAF などのクラウド型 WAF は導入コストが低く中小規模に適しています（AWS WAF 設定入門）。
• レートリミット：特定 IP からの過剰なリクエストをブロック。Nginx の limit_req や Cloudflare のレート制限で対応可能（Nginx アクセス制御）。
• CDN によるシールド：Cloudflare などの CDN を前段に置くことで、オリジンサーバーの IP を隠蔽し DDoS 耐性を高める。

8. 脆弱性管理と定期診断

• 依存ライブラリの更新：OSS ライブラリの脆弱性（CVE）は頻繁に発生します。Dependabot や npm audit などで定期的に確認し、速やかにアップデートする。
• OS・ミドルウェアのパッチ適用：Ubuntu の unattended-upgrades や手動の apt upgrade で定期的にセキュリティパッチを適用する。
• 脆弱性診断：本番リリース前に OWASP ZAP などのツールによる自動スキャンを実施し、重大な脆弱性がないことを確認する。
• インシデント対応計画：侵害が発生した場合の対応手順（連絡先・ログ保全・サービス停止の判断フロー）を事前に決めておく。

セキュリティ設計チェックリスト

• □ パスワードは bcrypt / Argon2 でハッシュ化している
• □ SQL はプリペアドステートメントで発行している
• □ HTML 出力時にエンティティエスケープを行っている
• □ CSRF トークンをフォームに実装している
• □ サイト全体が HTTPS で提供されている
• □ TLS 1.0 / 1.1 を無効化している
• □ セキュリティヘッダーを設定している
• □ 管理者画面に IP 制限または MFA を設定している
• □ 依存ライブラリの CVE を定期確認している
• □ エラーメッセージに内部情報（SQL・スタックトレース）が露出していない

← 技術ドキュメント一覧へ戻る