ウェブサイトのセキュリティを確認する方法：パッシブチェックでわかること、わからないこと

「自分のウェブサイトは安全か？」という問いに、はい・いいえで答えることはできません。それでも、有効な最初の一歩はあります。インターネット上の誰もがすでに見ることのできる部分のセキュリティを確認することです。サイトを訪れるすべてのブラウザは、HTTPS の設定、証明書、レスポンスヘッダー、Cookie を受け取ります。これらの設定が誤っていれば、理由もなく攻撃をしやすくしていることになります。しかも、その修正はたいてい作り直しではなく、設定の変更で済みます。

このガイドでは、何を確認するのか、どう確認するのか、そして同じくらい重要なこととして、こうした確認では何がわからないのかを順に説明します。

パッシブチェックとセキュリティテストの違い

パッシブチェックは、ブラウザが行うのと同じ種類のリクエストを送り、その応答を読み取ります。攻撃用のペイロードを送ることも、フォームを送信することも、ログインを試みることもありません。そのため、稼働中のサイトに対していつでも安全に実行でき、設定ミスを見つけるのが得意です。

ペネトレーションテスト（侵入テスト）は別物です。資格を持つ専門家が、あなたの許可を得たうえで、ログイン、入力値の処理、アクセス制御、ビジネスロジックをテストしながら、実際に侵入を試みます。パッシブチェックでは見えない脆弱性を見つけられますが、本番サイトに対して思いつきで行うようなものではありません。

まずはパッシブな層から始めましょう。短時間で済みますし、目に見える基本ができていないサイトには、たいてい他の問題もあります。

確認する項目と、あるべき状態

1. すべてのページを HTTPS にし、恒久的なリダイレクトを設定する

すべてのページが https:// で読み込まれ、http:// だけのアドレスを入力したときには、HTTPS 版への 301 または 308 リダイレクトが返されるべきです。302 でも動作はしますが、ブラウザに記憶されません。また、暗号化されていない HTTP でページを配信し続けているサイトでは、同じネットワーク上にいる誰もがその内容を読んだり書き換えたりできてしまいます。curl -I http://yourdomain.com/ でテストし、ステータス行と Location ヘッダーを確認してください。

2. 自動で更新される有効な証明書

証明書は、信頼されたもので、ドメインと一致し、有効期限が迫っていない必要があります。証明書の期限切れは、ほとんどの場合、サーバーや DNS の変更後に更新ジョブがいつの間にか止まっていたことが原因です。ブラウザの鍵アイコンをクリックして発行元と有効期限を確認し、更新が自動化されていることを確かめましょう。

3. 適切な値が設定されたセキュリティヘッダー

Strict-Transport-Security、Content-Security-Policy、X-Content-Type-Options、Referrer-Policy などのヘッダーは、ブラウザに組み込まれた保護機能を有効にします。ヘッダーが存在するかどうかと同じくらい、その値が重要です。テスト時のまま残された300秒の HSTS max-age はほとんど何も守りませんし、script-src に 'unsafe-inline' や * を含む CSP は、注入されたスクリプトに対してほとんど効果がありません。安全な値については、セキュリティヘッダーと Content-Security-Policy のガイドで解説しています。

4. Cookie のフラグ

セッション Cookie とログイン Cookie には、Secure（HTTPS のみ）と HttpOnly（JavaScript から見えない）を設定し、SameSite の値も明示的に指定すべきです。ブラウザで開発者ツールを開き、「アプリケーション」（Chrome、Edge）または「ストレージ」（Firefox）→「Cookie」を確認します。各フラグについては、Cookie のセキュリティを確認する方法のガイドで一つずつ説明しています。

5. 誰でも信頼してしまわない CORS 設定

Cross-Origin Resource Sharing（オリジン間リソース共有）のヘッダーは、他のどのサイトがあなたのサイトのレスポンスを読み取ってよいかをブラウザに伝えます。危険なのは、サーバーが受け取った Origin を何でもそのまま Access-Control-Allow-Origin にコピーし、さらに Access-Control-Allow-Credentials: true も送信するパターンです。これでは、どのウェブサイトでも、訪問者の Cookie を使って行われたリクエストのレスポンスを読み取れてしまいます。許可するオリジンは個別に指定しましょう。

6. 混在コンテンツがないこと

HTTPS のページがスクリプト、スタイルシート、フレームを http:// で読み込んでいると、アクティブな混在コンテンツが発生します。最近のブラウザはこれをブロックするため、多くの場合ページが壊れます。暗号化されていない HTTP の画像やメディアはパッシブな混在コンテンツで、危険性は低いものの、鍵アイコンが示す安全性はやはり損なわれます。テンプレートとデータベースを検索して、直接書き込まれた http:// のURLを探してください。

7. 攻撃者に与えている情報

Server: Apache/2.4.41 や X-Powered-By: PHP/7.4 のようなヘッダーは、正確なバージョンを公表しています。公開されている JavaScript のソースマップは、フロントエンドの元のコードを公開してしまうことがあります。どちらもそれ自体は脆弱性ではありませんが、攻撃者の手間を省くことになります。あわせて、Contact と Expires の日付を記載した /.well-known/security.txt ファイルの公開も検討してください。問題を見つけた人が、どこに連絡すればよいかわかるようになります。

Rudra のセキュリティチェッカーの仕組み

無料ウェブサイトセキュリティチェッカーは、上記のリストを自動化したものです。ページに通常のリクエストを1回送り、ヘッダー、ページが設定する Cookie（名前とフラグだけで、値は決して読み取りません）、HTML を読み取ります。続いて、少数の決まった読み取り専用リクエストを追加で行います。証明書を確認するための TLS 接続、リダイレクトの挙動を見るための http://yourdomain/ へのリクエスト1回、CORS ヘッダーの応答を見るための架空のテスト用オリジン（https://rudra-audit.invalid）を付けたリクエスト1回、そして security.txt や robots.txt といったよく知られたファイルの短い許可リストへのリクエストです。

それぞれの検出結果には、観測された値、合格となる値の例、そのチェックの確度が表示されます。インラインの onclick ハンドラーや、Subresource Integrity のないサードパーティスクリプトのように、状況によって問題なかったり危険だったりするパターンもあります。こうしたものは確定した問題として示すのではなく、ご自身で確認していただけるよう、低い確度で指摘します。レポートには、検出できた技術や外部に公開されている範囲（ページ内に記載されたログインフォームや API のURLなど）も一覧表示されるので、外から何が見えているのかがわかります。

パッシブチェックではわからないこと

良いスコアを過大に受け取ってしまいがちなのが、この点です。私たちのものも含め、パッシブチェックは次のことを行いません。

• SQL インジェクション、クロスサイトスクリプティング、アクセス制御の不備といった、コード内の脆弱性の発見
• CMS、プラグイン、ライブラリ、サーバーに既知の脆弱なバージョンがないかのスキャン（ヘッダーがたまたまバージョンを明かしている場合を除く）
• 管理画面やアカウントページなど、ログインの先にあるもののテスト
• CSRF 対策やレート制限を含め、フォームを送信したときの挙動のテスト
• マルウェア、改ざん、アカウントの乗っ取りの検出
• ホスティング環境、バックアップ、アクセス制御、管理者パスワードを誰が持っているかの点検

結果に問題がなければ、外から見える設定は良好な状態にあるということです。サイトがあらゆる面で安全だという意味ではありませんし、それを約束できる自動スキャンは存在しません。

スキャン以外にやるべきこと

1. ソフトウェアを最新に保つ：CMS、プラグイン、テーマ、フレームワークの更新は速やかに適用し、使っていないプラグインは削除します。
2. 管理者アカウントを保護する：サイトを変更できるすべてのアカウントで、使い回しのないパスワードと二要素認証を使います。
3. 復元テスト済みのバックアップを保持する：一度も復元したことのないバックアップは、計画ではなく願望にすぎません。
4. 変化を監視する：デプロイのあとや、サードパーティのスクリプトを追加するたびに、パッシブチェックを再実行します。
5. リスクに見合う場合は専門家によるテストを受ける：決済、健康に関するデータ、アカウントを扱っているなら、資格を持つテスターに、対象範囲を書面で定めたうえでペネトレーションテストを依頼してください。

表示速度、SEO、アクセシビリティ、リンク切れなど、サイトの健全性のその他の面については、同じページで総合的なウェブサイト監査を実行してください。