--- title: "Webサイトのセキュリティ構築｜設計段階から作り込む安全なサイトの基本" url: "https://www.issoh.co.jp/tech/details/5147/" published: 2025-02-03 updated: 2026-10-02 categories: ["セキュリティ"] publisher: "株式会社一創" --- # Webサイトのセキュリティ構築｜設計段階から作り込む安全なサイトの基本 Webサイトのセキュリティは、公開直前に脆弱性診断を1回かけて終わりにするものではなく、要件定義から実装・運用まで一貫して「作り込む」対象です。攻撃の大半は、SQLインジェクションやクロスサイト・スクリプティング（XSS）といった既知の脆弱性を突いたものであり、原因を実装で断てば大部分は成立しなくなります。本記事は、IPA「安全なウェブサイトの作り方」が示す**根本的解決**と**保険的対策**の2軸を土台に、Webサイトのセキュリティ構築を設計段階から進める考え方を、各対策の深掘り記事への入り口としてまとめます。 ## まとめ：Webサイトのセキュリティ構築の要点 - セキュリティは後付けではなく、要件定義・実装・運用の全工程で作り込む。 - 対策は「根本的解決（原因を作らない実装）」と「保険的対策（被害を抑える運用）」の2軸で切り分ける。 - SQLインジェクション・XSS・CSRFなどの代表的脆弱性は、原因を断つ実装（プレースホルダ・エスケープ）が根本的解決になる。 - WAFや詳細エラー抑止は被害を抑える保険的対策であり、根本的解決の代わりにはならない。 - IPA「安全なウェブサイトの作り方」改訂第7版とセキュリティ実装チェックリストを、要件定義とコードレビューに組み込む。 以下、なぜ設計段階から必要なのか、2軸での対策設計、代表的脆弱性の勘所、IPA資料の実務活用の順に見ていきます。 ## Webサイトのセキュリティ構築が設計段階から必要な理由 脆弱性は多くの場合、入力値の扱いやデータの組み立て方といった実装の判断から生まれます。原因が実装にあるため、リリース後にWAFやフィルタを「上から被せる」だけでは、原因そのものは残り続けます。保険的対策は攻撃の一部を止められても、想定外のパターンや設定漏れをすり抜けられれば被害に直結します。 そのため、実務では公開直前の脆弱性診断だけに依存する運用は失敗しやすいパターンです。診断で指摘が出てからコードの根幹を直すと手戻りが大きく、修正が間に合わずにリリース優先で保険的対策に逃げる判断を招きます。セキュリティ要件を機能要件と同時に定義し、原因を作らない実装を最初から選ぶほうが、結果的に総コストは下がります。 ## 根本的解決と保険的対策の違い（IPAの2軸で対策を設計する） IPA「安全なウェブサイトの作り方」は、脆弱性ごとの対策を**根本的解決**と**保険的対策**に分けて提示しています。根本的解決は脆弱性の原因そのものを作り込まない実装、保険的対策は万一攻撃が成立した際の被害を低減する措置です。この2軸で「何を実装で潰し、何を運用で守るか」を切り分けるのが、セキュリティ構築の設計の骨格になります。 | 脆弱性 | 根本的解決（原因を作らない実装） | 保険的対策（被害を抑える運用） | | ----------- | ---------------- | ---------------- | | SQLインジェクション | プレースホルダでSQL構築 | 詳細エラーの非表示 | | XSS | 出力時のHTMLエスケープ | 入力値制限・Cookie属性付与 | | CSRF | リクエスト正当性の照合 | 重要操作後のメール通知 | | クリックジャッキング | フレーム制限ヘッダの付与 | 重要操作前の再認証 | 優先すべきは根本的解決です。保険的対策は根本的解決を補完する位置づけであり、単独で脆弱性を消すものではありません。設計時にこの区別を明確にしておくと、後述するWAFのような保険的対策への過信を避けられます。 ## Webサイト構築で押さえる代表的な脆弱性と対策の勘所 ここでは各脆弱性の要点と、根本的解決の勘所だけを示します。攻撃例やコードを含む詳細は、それぞれの専用記事に委ねます。 ### SQLインジェクション：プレースホルダで原因を断つ 入力値をSQL文に文字列連結すると、データベースを不正に操作されます。根本的解決はプレースホルダ（プリペアドステートメント）でSQLを組み立て、値を構文と分離することです。仕組み・攻撃例・コード付きの対策は[SQLインジェクションとは？仕組み・攻撃例・対策をコード付きで解説](/column/details/3030/)で扱っています。 ### クロスサイト・スクリプティング（XSS）とCSRF XSSは出力時のHTMLエスケープが根本的解決で、CSRFは正規の画面遷移を経たリクエストかを照合することが要になります。両者は混同されやすいため、対策の違いを整理した[CSRFとXSSへの対策方法と防止策のベストプラクティス](/tech/details/4109/)、CSRF単体の仕組みを掘り下げた[CSRFとは？仕組み・XSSとの違い・実装で効くWeb対策を解説](/tech/details/3031/)を参照してください。 ### クリックジャッキング：フレーム制限ヘッダで防ぐ 透明化した自サイトを攻撃者のページに重ね、利用者に意図しない操作をさせる攻撃です。根本的解決は、外部サイトからのフレーム表示を制限するレスポンスヘッダを付与することです。旧来の`X-Frame-Options`に加え、現在は`Content-Security-Policy`の`frame-ancestors`指定が推奨されます。両ヘッダは同じ意図で対にして指定します。フレーム表示を一切許さない場合は次のとおりです。 ``` Content-Security-Policy: frame-ancestors 'none' X-Frame-Options: DENY ``` 自サイト内での埋め込みだけを許すなら、`frame-ancestors 'self'`と`X-Frame-Options: SAMEORIGIN`を対で指定します（`'none'`が`DENY`、`'self'`が`SAMEORIGIN`に対応）。重要操作の直前に再認証やパスワード入力を挟むことが保険的対策になります。 ### セッション管理・認可制御の不備 推測されにくいセッションIDの発行、ログイン後のID再発行、通信のTLS化が土台です。あわせて、URLやパラメータの改変で他人のデータにアクセスできないよう、画面表示だけでなくサーバー側で認可を必ず検証します。「画面に出していないから安全」という前提は、直リクエストで崩れます。サーバーへの侵入から個人情報の外部送信まで進んだ実例は、[ショップサーブの情報漏えい最大885万件の技術解説](https://www.issoh.co.jp/tech/details/16098/)で整理しています。 ## IPA「安全なウェブサイトの作り方」を実務で使う Webサイトのセキュリティ構築で最初に押さえる一次資料が、IPA（独立行政法人 情報処理推進機構）の「安全なウェブサイトの作り方」改訂第7版です。届出の多い脆弱性と影響の大きい脆弱性を取り上げ、それぞれを根本的解決と保険的対策に分けて解説しています。 本編とは別に「セキュリティ実装 チェックリスト」がPDF・Excel形式で無償公開されています。これを読み物として消費するのではなく、要件定義書の付録に組み込み、コードレビューやリリース前チェックの確認項目として運用するのが効果的です。各項目を「対応済／非該当」で埋めていけば、抜け漏れの記録がそのまま説明責任の証跡になります。改訂第7版は2015年公開のため、TLSの設定やヘッダの推奨値など変化の速い項目は、実装時に公式ドキュメントで最新の推奨を確認してください。 ## 設計・実装・運用でセキュリティを作り込む進め方 2軸と一次資料を踏まえ、工程ごとに何を担保するかを整理します。 ### 要件定義：セキュリティ要件を機能要件と同時に決める 扱う個人情報や認証の有無から、必要な対策のレベルを最初に確定します。IPAチェックリストの該当項目を要件として明文化し、「後で入れる」項目を残さないことが手戻りを防ぎます。 ### 実装：フレームワークの標準機能で根本的解決を取りにいく 主要なWebフレームワークは、SQLのプレースホルダやテンプレートの自動エスケープ、CSRFトークンなどを標準で備えています。独自実装で対策を書き起こすより、フレームワークの安全な機能を正しく使うほうが、根本的解決を確実かつ低コストに達成できます。標準の安全機能を無効化する設定は、根本的解決をわざわざ手放すことになります。 ### 運用：保険的対策と定期的な脆弱性診断を組み合わせる 運用フェーズでは、保険的対策としてのWAF導入と、継続的な脆弱性診断が柱になります。WAFは既知の攻撃パターンを遮断するのみで、脆弱性の根本原因は実装側に残ります。導入判断は[WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説](/tech/details/13275/)を、診断の種類や費用相場・外注の判断は[脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](/column/details/13101/)を参考に、自社の体制に合わせて選定してください。 ## よくある質問 ### IPA「安全なウェブサイトの作り方」はどこで入手できますか？ IPA公式サイトの情報セキュリティのページから、本編PDFとセキュリティ実装チェックリスト（PDF・Excel）を無償でダウンロードできます。現在の最新は改訂第7版です。 ### Webサイトのセキュリティ構築は何から始めるべきですか？ 要件定義の段階で、扱うデータと認証要件から必要な対策レベルを決めることから始めます。IPAチェックリストを要件に転記し、根本的解決にあたる実装項目を先に確定するのが効率的です。 ### WAFを導入すれば脆弱性対策は十分ですか？ 不十分です。WAFは被害を抑える保険的対策であり、脆弱性の原因は実装側に残ります。プレースホルダやエスケープなどの根本的解決を実装で行ったうえで、WAFを補完として使う位置づけが適切です。 ### フレームワークを使えば安全ですか？ 標準機能を正しく使えば根本的解決の多くを低コストで達成できますが、自動エスケープを無効化する、生SQLを直接組み立てるといった使い方をすると脆弱性は生じます。安全なのはフレームワークではなく、その安全機能を活かす実装です。 ### 脆弱性診断はいつ実施すべきですか？ 公開直前の1回だけでなく、大きな機能追加やリリースの節目ごとに定期的に実施します。設計段階から根本的解決を作り込んでおくと、診断での重大な手戻りを減らせます。 ## 関連記事 - [SQLインジェクションとは？仕組み・攻撃例・対策をコード付きで解説](/column/details/3030/) - [CSRFとXSSへの対策方法と防止策のベストプラクティス](/tech/details/4109/) - [CSRFとは？仕組み・XSSとの違い・実装で効くWeb対策を解説](/tech/details/3031/) - [WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説](/tech/details/13275/) - [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](/column/details/13101/) --- 出典: [Webサイトのセキュリティ構築｜設計段階から作り込む安全なサイトの基本]()（株式会社一創）