ホームページの発注側も知っておきたい ── IPA「安全なウェブサイトの作り方」をチェックリストとして使う

「うちのホームページ、セキュリティは大丈夫?」と聞かれて、根拠を持って「大丈夫」と答えられる会社は多くありません。

制作会社に任せているから大丈夫、会社案内だけのサイトだから狙われない、と思われがちですが、問い合わせフォームが1つあれば入力値を処理するプログラムが動いていますし、WordPressのようなCMSを使っていれば管理画面もプラグインも攻撃対象です。しかも攻撃の多くは会社を狙い撃ちにするのではなく、弱いサイトを機械的に探し出して行われます。

では、何を基準に「大丈夫」を確認すればよいのか。その基準として長く使われてきた公的資料が、IPA(独立行政法人情報処理推進機構)の安全なウェブサイトの作り方です。

この記事では、この資料が何を教えてくれるのかを、Webサイトを発注する側・運営する側にも分かる言葉で整理します。

1．まず結論

• 「安全なウェブサイトの作り方」は、IPAに実際に届出のあった脆弱性をもとに、ウェブサイトの弱点11種類と対策をまとめた資料。開発者だけでなく、発注・検収の基準としても使える
• 対策は「根本的解決」(原因を取り除く)と「保険的対策」(被害を軽減する)に分かれる。基本は根本的解決で、保険的対策はその上乗せ
• 付属の「セキュリティ実装チェックリスト」は、制作会社への発注時・検収時の確認項目としてそのまま使える
• 別冊「ウェブ健康診断仕様」は、運用中のサイトを定期点検するときの診断項目の基準になる
• 会社サイトの実務では、フォームなど入力を受け付ける部分と、CMS(WordPressなど)の運用が2大リスク。「作って終わり」にしない運用体制まで含めて発注時に決めておく

この記事の知識マップ

IPA「安全なウェブサイトの作り方」は、IPAに届出のあった脆弱性をもとに、SQLインジェクションやクロスサイト・スクリプティング(XSS)、CSRFなど11種類のウェブサイトの脆弱性と対策をまとめた資料である。対策は原因そのものを取り除く根本的解決を基本とし、それでも残るリスクを下げる保険的対策を上乗せするという順序で示され、SQLインジェクションにはプレースホルダ、XSSには出力時エスケープが根本的解決として挙げられる。付属のセキュリティ実装チェックリストは対策の実装状況を確認する基準に、別冊ウェブ健康診断仕様は稼働中サイトの脆弱性診断の目安に使える。更新の止まったCMSは、既知の脆弱性を突かれて改ざんされる典型的なリスクとして挙げられている。

flowchart LR
    accTitle: 「安全なウェブサイトの作り方」の知識マップ
    accDescr: IPA「安全なウェブサイトの作り方」が11種類のウェブサイトの脆弱性を取り上げ、根本的解決と保険的対策という考え方、付属のセキュリティ実装チェックリストやウェブ健康診断仕様との関係を示す図
    secure_website_guide["安全なウェブサイトの作り方"]
    ipa["IPA(独立行政法人情報処理推進機構)"]
    sql_injection["SQLインジェクション"]
    os_command_injection["OSコマンド・インジェクション"]
    directory_traversal["パス名パラメータの未チェック(ディレクトリ・トラバーサル)"]
    session_management_flaw["セッション管理の不備"]
    cross_site_scripting["クロスサイト・スクリプティング(XSS)"]
    csrf["クロスサイトリクエストフォージェリ(CSRF)"]
    http_header_injection["HTTPヘッダ・インジェクション"]
    mail_header_injection["メールヘッダ・インジェクション"]
    clickjacking["クリックジャッキング"]
    buffer_overflow["バッファオーバーフロー"]
    access_control_flaw["アクセス制御や認可制御の欠落"]
    security_implementation_checklist["セキュリティ実装チェックリスト"]
    web_health_checkup_spec["ウェブ健康診断仕様"]
    fundamental_solution["根本的解決"]
    insurance_measure["保険的対策"]
    prepared_statement["プレースホルダ(プリペアドステートメント)"]
    output_escaping["出力時エスケープ"]
    vulnerability_assessment["脆弱性診断"]
    cms["CMS(Content Management System)"]
    website_defacement["ウェブサイトの改ざん"]
    waf["WAF(Web Application Firewall)"]
    ipa -->|"実装を担う"| secure_website_guide
    secure_website_guide -->|"利用する"| sql_injection
    secure_website_guide -->|"利用する"| os_command_injection
    secure_website_guide -->|"利用する"| directory_traversal
    secure_website_guide -->|"利用する"| session_management_flaw
    secure_website_guide -->|"利用する"| cross_site_scripting
    secure_website_guide -->|"利用する"| csrf
    secure_website_guide -->|"利用する"| http_header_injection
    secure_website_guide -->|"利用する"| mail_header_injection
    secure_website_guide -->|"利用する"| clickjacking
    secure_website_guide -->|"利用する"| buffer_overflow
    secure_website_guide -->|"利用する"| access_control_flaw
    secure_website_guide -->|"利用する"| security_implementation_checklist
    secure_website_guide -->|"利用する"| web_health_checkup_spec
    fundamental_solution -->|"より先に行うべき"| insurance_measure
    prepared_statement -->|"防止する"| sql_injection
    output_escaping -->|"防止する"| cross_site_scripting
    fundamental_solution -->|"で確認できる"| security_implementation_checklist
    insurance_measure -->|"で確認できる"| security_implementation_checklist
    vulnerability_assessment -->|"利用する"| web_health_checkup_spec
    cms -.->|"原因になり得る"| website_defacement
    cms -.->|"で確認できる"| vulnerability_assessment
    waf -->|"用いるのは非推奨"| fundamental_solution

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全23件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2．「安全なウェブサイトの作り方」とは

「安全なウェブサイトの作り方」は、IPAが届出を受けた脆弱性関連情報のうち、届出件数が多かった脆弱性や、攻撃された場合の影響が大きい脆弱性を取り上げ、ウェブサイトの開発者や運営者向けに対策をまとめた資料です。現在公開されている最新版は改訂第7版で、全115ページ。配布されているPDFは2021年3月31日に第4刷として更新されたものです。PDFのほか、脆弱性ごとのHTMLページも公開されています。

構成は3章立てです。

さらに、本編とは別に次の資料が公開されています。

• セキュリティ実装チェックリスト(Excel形式): 本編の対策を実装したかを確認する一覧表
• 別冊「安全なSQLの呼び出し方」: データベースまわりの脆弱性対策を深掘りした資料
• 別冊「ウェブ健康診断仕様」: 稼働中のサイトを診断するための13の診断項目をまとめた仕様

いずれもIPAのページから無償でダウンロードできます。

2.1．資料の鮮度をどう考えるか

この資料を基準として使う前に、押さえておきたい前提があります。改訂第7版が公開されたのは2015年3月で、その後は増刷のたびに修正が入り、現在配布されているPDFは2021年3月31日更新の第7版第4刷です。本記事の執筆時点(2026年7月)で第8版は公開されていません。

それでも基準として使えるのは、この資料が扱っているのがウェブアプリケーションの作り方そのものに由来する弱点だからです。入力値をSQL文やHTMLに埋め込む、セッションで本人を識別する、フォームの入力からメールを送る、という仕組みは今も変わっていません。11種類の脆弱性と「根本的解決/保険的対策」という考え方は、今も実装の確認基準として通用します。

逆に言えば、近年の脅威の動向はこの資料ではカバーできません。ランサム攻撃、取引先や委託先を経由した侵入、生成AIの利用に伴うリスクといった話題は、もともとこの資料の守備範囲ではありません。そこは毎年更新される資料で補うことになります。

3つを別々に読む必要はありません。「実装の基準はこの資料、脅威の最新動向は10大脅威、会社の体制はガイドライン」と役割を分けて、必要になったところだけ見に行けば十分です。10大脅威の2026年版の中身は情報セキュリティ10大脅威2026の解説記事で、ガイドライン第4.0版はガイドライン第4.0版の解説記事で扱っています。

3．11の脆弱性を「何が起きるか」で読む

第1章が取り上げる11種類の脆弱性は、開発者向けの用語で並んでいますが、「放置すると自社のサイトで何が起きるか」に置き換えると、発注側にも他人事ではないことが分かります。

右端の列は、会社サイトでこの脆弱性が問題になりやすい場所の例です。自社のサイトに同じ機能があるかどうかで、どの行が自分事かを見分けられます。

たとえば「メールヘッダ・インジェクション」は、会社案内サイトの問い合わせフォームがそのまま該当します。対策の甘いフォームは迷惑メールの発信元として悪用され、会社のドメインの信用(メールが相手に届くかどうか)まで傷つけます。フォームからのメールが届かなくなる問題は問い合わせフォームのメールが届かない原因で扱ったとおり、ビジネス機会の損失に直結します。

4．「根本的解決」と「保険的対策」── 対策の考え方

この資料の優れた点は、対策を2種類に分けて示していることです。

• 根本的解決: 脆弱性の原因そのものを取り除く実装。たとえばSQLインジェクションなら、SQL文の組み立てを文字列連結ではなくプレースホルダで行う
• 保険的対策: 脆弱性が残ってしまった場合に、攻撃の成功率や被害を下げる対策。たとえばエラーメッセージをそのままブラウザに表示しない

この分類は、発注側がセキュリティの説明を受けるときの物差しになります。「WAF(攻撃を検知・遮断する仕組み)を入れるので安心です」という説明は保険的対策の話であって、アプリケーション自体の根本的解決の代わりにはなりません。逆に、根本的解決を実装したうえでWAFを重ねるのは理にかなった構成です。どちらの層の話をしているのかを区別して聞くだけで、提案の妥当性がかなり見えるようになります。

5．発注・検収でどう使うか

「安全なウェブサイトの作り方」は開発者向けの資料ですが、発注側にとっての実用性は、要求と確認の基準に使えることです。

• 見積もり・要件の段階: 仕様書やRFPに「IPA『安全なウェブサイトの作り方』が挙げる脆弱性への対策を実装すること」と一文入れる。基準を名指しすることで、「セキュリティに配慮する」という曖昧な表現より要求が明確になる
• 検収の段階: セキュリティ実装チェックリストの該当項目について、確認結果の提出を求める
• 契約の段階: 公開後にCMS・プラグイン・サーバーの更新を誰が行うのか、脆弱性が見つかった場合の対応は保守契約の範囲か個別見積もりかを、文書で線引きする

3点目は特に重要です。Webサイトのセキュリティは作った時点で完成ではなく、公開後に見つかる新しい脆弱性への追従で維持されます。この「誰が面倒を見続けるのか」は、受託開発・運用保守の契約の記事で整理した保守範囲の話と同じ構図です。

5.1．仕様書・RFPに書く文例

「セキュリティに配慮すること」では、何をもって満たしたと言えるのかが決まりません。資料名と提出物を指定すると、要求が検証できる形になります。たとえば次のように書きます。

セキュリティ要件

1. 本件のウェブアプリケーションは、IPA「安全なウェブサイトの作り方 改訂第7版」第1章が挙げる各脆弱性について、同資料の「根本的解決」に分類される対策を実装すること。
2. 納品時に、同資料付属の「セキュリティ実装チェックリスト」の全項目について自己チェックの結果を提出すること。「対応不要」と判断した項目は、その理由(該当する機能を持たない等)を併記すること。
3. 動的な処理を伴う画面(問い合わせフォーム、検索、ログイン、ファイルダウンロード等)について、入力値の扱いと出力時のエスケープ処理の方針を設計書に記載すること。
4. 公開後にCMS本体・テーマ・プラグイン・実行環境の更新を行う主体と頻度、緊急の脆弱性が公表された場合の対応時間と費用の扱いを、保守契約に明記すること。

4項目すべてを最初から入れる必要はありません。会社案内中心のサイトなら1と2だけでも、「セキュリティは任せます」で発注するのとは検収時の会話がまるで違ってきます。

5.2．チェックリストの中身

チェックリストはExcelファイル1枚で、「安全なウェブサイトの作り方 改訂第7版」の第1章に対応した47の実施項目が、11種類の脆弱性ごとに並んでいます。各行は、脆弱性の種類、対策の性質(根本的解決/保険的対策)、チェック欄(対応済/未対策/対応不要)、実施項目の文、本編の解説番号という構成です。

実際の項目は、たとえば次のような文で書かれています。

(実施項目の文はIPA「安全なウェブサイトの作り方 改訂第7版」付属のセキュリティ実装チェックリストからの引用)

発注側にとって使いやすいのは、チェック欄に「対応不要」があることです。ログイン機能のないサイトでセッション管理の項目が空欄なのは正常ですが、それが「該当しないから対応不要」なのか「見落とし」なのかは、記入されていなければ区別できません。理由つきで「対応不要」と書いてもらうだけで、検収の会話が具体的になります。

6．運用中のサイトは「健康診断」する

すでに公開しているサイトについては、別冊の「ウェブ健康診断仕様」が役立ちます。これは、稼働中のウェブサイトに対して安全性を点検するための診断項目(13項目)をまとめた仕様で、脆弱性診断サービスを利用するときの内容の目安にもなります。

中小企業の会社サイトで、実務上とくにリスクが集中しやすいのは次の2か所です。

• 入力を受け付ける部分: 問い合わせフォーム、検索窓、会員ログインなど。第1章の脆弱性の多くはここに関係する
• CMSの運用: WordPressなどの本体・テーマ・プラグインの更新が止まっているサイトは、既知の弱点を突かれて改ざんされる典型パターン。更新が誰の仕事か決まっていないまま放置されているケースが非常に多い

CMSの更新負担を運用体制ごと見直したい場合は、WordPressからの移行を扱った記事も参考になります。また、そもそも動的な処理を減らした静的サイト構成にすることで、攻撃対象面そのものを小さくするという設計判断もあります。当社がサイト制作でデジタル庁デザインシステムを土台にした静的構成を採用しているのも、この考え方の延長です。

なお、Webサイトの安全な運用は、IPAの「中小企業の情報セキュリティ対策ガイドライン」第4.0版の自社診断でも確認項目として挙げられています。会社全体のセキュリティ対策の中での位置づけは、ガイドライン第4.0版の解説記事をご覧ください。

7．用語ミニ辞典

制作会社との打ち合わせで出てくる言葉のうち、この記事で使ったものをまとめます。意味を1行で言えるようになっていれば、説明を受けるときに「それは根本的解決の話か、保険的対策の話か」を自分で判断できます。

まとめ

IPA「安全なウェブサイトの作り方」のポイントを整理します。

• 実際にIPAへ届出のあった脆弱性に基づく、ウェブサイトの弱点11種類と対策の定番資料(改訂第7版・全115ページ)
• 対策は根本的解決と保険的対策の2層。WAFなどの保険的対策は根本的解決の代わりにならない
• 発注側は、要件に資料名を明記し、チェックリストで検収し、公開後の更新体制を契約で決める、という使い方ができる
• 運用中のサイトは「ウェブ健康診断仕様」を目安に定期点検する
• 会社サイトの現実的なリスクは、フォームなどの入力処理とCMSの放置に集中しやすい

セキュリティは「専門家に言われるままに費用をかける」か「何もしない」かの二択になりがちですが、公的な基準を知っているだけで、要求も確認も自分の言葉でできるようになります。

ホームページの制作・リニューアルをご検討の方へ

合同会社小村ソフトでは、ホームページの制作・リニューアルの際、この記事で紹介した考え方に沿って、フォームまわりの実装、CMSに依存しすぎない静的構成、公開後の更新体制までを含めてご提案しています。「今のサイトがどうなっているか分からない」という段階の現状確認からご相談いただけます。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

「安全なウェブサイトの作り方」はどんな資料ですか？

IPA(独立行政法人情報処理推進機構)が公開している、ウェブサイト開発者・運営者向けのセキュリティ資料です。IPAに届出のあった脆弱性関連情報のうち、届出件数が多かったものや影響度の大きいものを取り上げ、脅威と対策を解説しています。最新の改訂第7版は2021年3月公開で、全115ページ。本編のほか、セキュリティ実装チェックリスト、別冊「安全なSQLの呼び出し方」「ウェブ健康診断仕様」が無償で公開されています。

会社案内程度のホームページでも、セキュリティ対策は必要ですか？

必要です。問い合わせフォームがあれば入力値を処理するプログラムが動いていますし、WordPressなどのCMSを使っていれば管理画面やプラグインが攻撃対象になります。攻撃者は会社の規模を選んで攻撃するとは限らず、脆弱なサイトを機械的に探して、改ざんやウイルス配布の踏み台、迷惑メールの送信元として悪用します。被害者であると同時に、取引先や訪問者への加害側になってしまうのがWebサイトの怖さです。

根本的解決と保険的対策の違いは何ですか？

「安全なウェブサイトの作り方」では、対策を2種類に分けて示しています。根本的解決は、脆弱性の原因そのものを取り除く実装方法(例:SQL文の組み立てにプレースホルダを使う)です。保険的対策は、脆弱性が残ってしまった場合に攻撃の成功率や被害を下げる対策(例:エラーメッセージをそのまま表示しない)です。保険的対策だけでは原因が残るため、根本的解決を基本とし、保険的対策を上乗せするのが正しい順番です。

制作会社に発注するとき、セキュリティについて何を確認すればよいですか？

少なくとも、①「安全なウェブサイトの作り方」が挙げる脆弱性への対策を実装しているか、②付属のセキュリティ実装チェックリストなどで確認結果を示せるか、③公開後にCMSやプラグインの更新を誰が行うのか(運用・保守の契約範囲)、の3点を見積もり段階で確認することをおすすめします。セキュリティ要件は後から追加すると手戻りが大きいため、契約前に文書で確認しておくことが重要です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。