webセキュリティ対策の全体像｜主な脆弱性・認証・診断と改修の進め方

webセキュリティとは、自社が公開するWebサイト・Webアプリを、脆弱性を突く攻撃による情報の漏えい・改ざん・サービスの停止から守る対策だ。

社員のWeb閲覧を守る仕組み（セキュアWebゲートウェイ）を指すこともあるが、ここでは扱わない。

webセキュリティで守る対象と主な脆弱性

守る対象は、登録された個人情報、ページの内容、サービスの稼働だ。脆弱性を突かれると、それぞれ漏えい、改ざん、停止につながる（IPA『安全なウェブサイトの作り方』）。主な脆弱性は、入力の扱いと認証・認可の不備によるものだ。

IPAの脆弱性届出制度の2026年第1四半期の報告では、2004年7月の受付開始から2026年3月末までにWebサイトの脆弱性に関する届出が13,535件あり、全体の約7割を占める。

OWASPは『OWASP Top 10:2025』で、リスクの1位にアクセス制御の不備、2位に設定の不備、5位にインジェクションを挙げている。

入力の扱いによる脆弱性：SQLインジェクションとクロスサイトスクリプティング

SQLインジェクションは、入力値をそのままSQL文に組み込むと、攻撃者がデータベースの内容を読み出したり書き換えたりできる脆弱性だ。IPAは、根本的な対策としてSQL文の組み立てにプレースホルダを使うことを挙げている。

クロスサイトスクリプティング（XSS）は、入力値がHTMLにそのまま埋め込まれると、第三者のブラウザで意図しないスクリプトが動く脆弱性だ。IPAによれば、出力のすべての要素にエスケープ処理を施すことが根本的な対策になる。同じ型の脆弱性に、入力値からサーバーのOSコマンドを実行されるOSコマンド・インジェクションや、公開していないファイルを読まれるディレクトリ・トラバーサルがある。

認証・認可とセッションの不備による脆弱性

認証はログインの仕組み、認可はログインした利用者に何を許すかの仕組みだ。OWASPが1位に挙げるアクセス制御の不備は、利用者が許された権限を超えて操作や閲覧ができる状態で、認可の確認の抜けが典型だ。

URLやパラメータのIDを変えるだけで他人のデータを取得できるAPIがある。OWASPの『API Security Top 10 2023』はこの問題をBOLA（オブジェクト単位の認可不備）と呼び、APIの脆弱性の1位に挙げている。

CSRF（クロスサイトリクエストフォージェリ）は、ログイン中の利用者が罠のページを開くと、本人の意図しない処理を実行させられる脆弱性だ。IPAは送金や商品の購入、パスワードなどの設定変更を被害の例に挙げ、重要な処理の直前のページに推測が難しい秘密の値を埋め込んで照合するか、パスワードを再入力させることを根本的な対策としている。

Webアプリケーションのセキュリティ設計と認証・認可

認証・認可と入力の検証は、設計の段階で組み込む。OWASPは「安全でない設計」を6位に挙げ、実装の修正では補えない欠陥として扱っている。

サーバー側で行う権限確認と入力の検証

画面のボタンを隠したりJavaScriptで入力を制限したりしても、サーバーへ直接要求を送れば迂回できる。権限の確認と入力の検証はサーバー側で行う。APIを含むすべてのエンドポイントで、処理の前に操作と対象データの認可を確かめる。

IPAの区分では入力値の検証は保険的対策で、プレースホルダやエスケープの代わりにはならない。

ログイン・多要素認証・セッション管理の設計

NISTは『デジタルアイデンティティのガイドライン（SP 800-63B-4）』で、パスワードをソルト付きで、保存に適したハッシュ方式で保存するよう求めている。1つのアカウントで連続したログイン失敗を100回以下に制限することと、新しいパスワードを漏えい済み・頻出のパスワードの一覧と照合することも求めている。多要素認証は、一定の水準（AAL2）以上で必須だ。

IPAはセッションIDをURLに含めず推測が難しい値を使い、ログイン成功後に新しいセッションを始めることを挙げている。加えて、無操作のセッションは失効させ、ログアウト時はサーバー側で破棄する。

IDを書き換えると他人のデータが返るBOLAを、どこで防ぎ、直した後にどう確かめるかはBOLAの解説記事で扱っている。

Webサイトのセキュリティ対策と公開設定・更新の管理

公開設定と更新の対策は、更新管理、管理画面の公開範囲の制限、通信の暗号化、ログ監視と復旧の備えだ。

CMSで動くサイトでは、CMS本体、プラグイン、サーバーのソフトウェアに残った既知の脆弱性が攻撃の入口になる。JPCERT/CCは2026年4月15日号のWeekly Reportで、WordPress用プラグインのアドオンの脆弱性が悪用されているとの情報を紹介した。

サーバー・CMS・ライブラリの更新管理

公開しているサーバー・CMS・プラグインのバージョンを把握し、既知の脆弱性に追随する担当と頻度を決める。

1. CMS本体、プラグイン、テーマ、OS、ミドルウェアの一覧と現在のバージョンを記録する
2. 脆弱性情報の入手先（JVN、CMS公式のセキュリティ通知、IPAの注意喚起）と、確認の担当・頻度を決める
3. ステージング環境で確かめてから本番に適用する。更新できなければ回避策と期限を記録する

使わないサービスとアカウントは止める。IPAは公開を想定していないファイルを公開用のディレクトリに置かないことと、エラーメッセージをそのまま表示しないことも挙げている。

管理画面の公開範囲・通信の暗号化・WAFの役割

CMSの管理画面を誰でも開けると、ログインの総当たりや既知の脆弱性を突く攻撃を受けやすい。管理画面への接続元をIPアドレスやVPNで制限する。

通信の暗号化は、利用者とサーバーの間の盗聴と改ざんを防ぐ。HTTPSの導入に加え、証明書の期限管理と、HTTPSでの接続をブラウザに指示するHSTSの設定も対象だ。

WAF（Webアプリケーションファイアウォール）は、SQLインジェクションやXSSのパターンに合う要求を遮断する。IPAはWAFを、改修が難しいときに攻撃の影響を低減する運用面の対策としている。

大量の通信でサイトを止めるDDoS攻撃について、NISCは2025年2月の注意喚起で、同じIPアドレスからしきい値を超える要求の遮断、専用の対策装置やサービス、CDNの利用を挙げ、防ぎきれない場合に別のサーバーでお知らせを出す準備も求めた。

不正ログインや改ざんに気づくログ監視と復旧の備え

OWASPはログの記録と警告の不備を9位に挙げ、調査に足りる期間ログを残すことと、対応と復旧の計画を定めることを勧めている。ログイン失敗が記録されずログがサーバー内だけでは、攻撃に気づけず後から調べられない。

• ログ：ログインの成否、権限エラー、管理画面の操作を記録し、保存期間と確認の担当を決める
• バックアップ：データと設定を本番環境から切り離した場所に保管する
• 発生時の連絡：通報先・連絡先の一覧を含む対応の手順を作る。NISCもDDoS攻撃への備えとして挙げている

webセキュリティの診断と改修の進め方

webセキュリティの診断と改修は、脆弱性診断で問題を洗い出し、影響の大きい順に直す流れで進める。

脆弱性診断の範囲と時期の決め方

• 公開前の診断：利用者が操作できるすべての画面とAPIで、認証、アクセス制御、入力値の処理を手動で確かめる
• 機能追加時の診断：変更した画面・APIと、その変更が影響する範囲を対象にする
• 定期診断：時期を決め（たとえば年1回）、範囲を前回と揃えて比べる

自動スキャンは広い範囲を短時間で調べられるが、認可の不備のように操作の文脈の理解が要る問題は見つけにくい。手動診断と自動スキャンを組み合わせ、それぞれの得意な範囲を分ける。

診断結果から改修の順番を決める手順

CVSSは脆弱性の深刻度を0.0〜10.0で表す共通の指標だ。基本値だけでは自社での影響は分からないので、4段で順番を決める。

優先度と暫定対処は、影響を受ける情報（個人情報、認証情報、業務データ）と業務への影響でも変わる。

Webセキュリティを個別に詳しく

• 「PHP2Shell」は本当に悪用できる？PoCと修正前後のPHPを検証：PHP2Shellの公開PoCを手元の環境で動かし、修正前後のPHPを比較。3つの経路で確認した結果、悪用の成立条件、公式勧告に基づく対策を整理する。
• PHPの重大な脆弱性「php2shell」で緊急メンテナンス相次ぐ！停止予定と今すぐ確認すること：PHPの重大な脆弱性「php2shell」への対応で、BASE、ツイキャス、はいチーズ！などが緊急メンテナンスを告知。5社の当初の停止予定・影響範囲と、確認できた再開報告、利用者・運用担当者の確認事項を整理する。
• Lean言語で権限逸脱が起きないことを数学的に証明、「Nyxis」が保証する安全性とは：Lean言語で認可の安全性を証明するNyxis。DB操作を認可層に通す構造と、1回の操作から要求の繰り返しへ証明を広げる仕組みを解説する。
• BOLAとは？他人のデータにアクセスできる認可不備と対策：BOLAが起きる仕組みを請求書の例で解説。利用者・データ・操作ごとの権限確認、IDORとの違い、修正後の確認方法を整理する。
• 脆弱性診断は無料ツールで足りる？OSSで調べる範囲と手動診断の違い：脆弱性診断の無料ツール（ZAP・Nikto・OpenVAS・Trivy）で見つかるのは既知の脆弱性と設定の不備まで。権限や業務の流れの弱点が自動では見つからない理由、使う前の許可と停止条件、外部診断に出す条件と渡す結果を整理した。
• PHPのサポート終了への対策｜バージョン確認・暫定対応・移行の判断：PHPのサポート終了への対策を、8.1以前やOSのパッケージに修正が届くかの確かめ方、Web・CLI・コンテナごとの稼働バージョンと依存の洗い出し、WAFや接続元の制限の限界、移行・改修・停止の決め方の順にまとめた。