無料ウェブサイトセキュリティチェッカー

このツールのチェック内容

• HTTPS とリダイレクト

  リダイレクト後にページが最終的に https:// になるか、途中のリダイレクト、そして http://yourdomain/ が HTTPS への恒久的なリダイレクト（301 または 308）を返すかを確認します。

• SSL/TLS 証明書

  証明書が信頼されていてドメインと一致しているか、使われている TLS のバージョン、発行者、有効期限までの日数。

• HSTS の値

  Strict-Transport-Security ヘッダーは、存在を確認するだけでなく内容を解析します：max-age が 180 日以上か、不正なディレクティブがないか、includeSubDomains があるか、そして preload フラグがある場合に preload リストが求める設定を満たしているかを確認します。

• Content-Security-Policy のディレクティブ

  各ディレクティブを読み取ります：スクリプトが制限されているか、'unsafe-inline'（nonce やハッシュを使っている場合は指摘しません）、'unsafe-eval'、script-src 内の *、https:、data: などの広範なソース、object-src、base-uri、そしてポリシーが Report-Only のみになっていないかを確認します。

• クリックジャッキング対策

  X-Frame-Options（無効な値や廃止された ALLOW-FROM を含む）、または * やスキームのみではない CSP の frame-ancestors ルール。

• その他の保護用ヘッダー

  X-Content-Type-Options は nosniff と完全に一致する必要があります。Referrer-Policy は unsafe-url や認識できない値がないか、Permissions-Policy は制限されていない機能がないかを確認します。クロスオリジン分離のヘッダーは情報として表示します。

• バージョン情報の露出とソースマップ

  バージョン番号を明かす Server、X-Powered-By、X-AspNet-Version、X-AspNetMvc-Version、X-Generator ヘッダーと、自サイトのスクリプト最大 3 件の公開されたソースマップ。

• Cookie のフラグ

  ページのレスポンスで設定される Cookie を、名前のみで確認します：HTTPS での Secure、名前からセッションやトークンと思われる Cookie の HttpOnly、Secure のない SameSite=None、SameSite の欠落、親ドメインを対象にした Cookie。

• CORS

  無害な架空の Origin（https://rudra-audit.invalid）を付けたリクエストを 1 回追加で送り、サーバーが任意のオリジンをそのまま返すか、さらに認証情報も許可しているか（これが危険な組み合わせです）を確認します。

• 混在コンテンツ

  HTTPS のページ上にある http:// のスクリプト、スタイルシート、フレーム（アクティブな混在コンテンツ）と、http:// の画像やメディア（パッシブな混在コンテンツ）。

• security.txt

  /.well-known/security.txt が存在し、Contact 行と将来の日付の Expires があるかを確認します。これにより、セキュリティ研究者が連絡方法を知ることができます。

• 技術と外部から見える領域

  ヘッダーや HTML から識別できるフレームワークやサービス、さらにログインフォーム、ページ内で言及されている API やドキュメントの URL、robots.txt などの公開ファイル。把握のために表示するもので、減点はありません。

• クライアント側のパターン（手動での確認）

  onclick などのインラインのイベントハンドラーや、Subresource Integrity なしで読み込まれるサードパーティのスクリプト。これらは確認を促す優先度の低いヒントであり、確認済みの脆弱性ではありません。

チェックの仕組み

このツールでチェックしないこと

• ペネトレーションテストではありません

  脆弱性の悪用、攻撃用のペイロード、総当たり攻撃、隠れたパスの推測は行いません。どのブラウザでも受け取る設定を読み取るだけです。

• ログインが必要なページ

  サインインや認証情報の送信は一切行わないため、認証が必要なページ、管理画面、アカウント設定はテストしません。

• コードと依存関係

  サーバー側のコードレビューや、CMS、プラグイン、ライブラリ、サーバーソフトウェアの脆弱性スキャンは行いません。

• マルウェアや乗っ取られたサイト

  マルウェア、改ざん、スパムの埋め込み、アカウントの流出は調べません。

• サイトが使うすべての Cookie

  確認できるのは、ページ自体のレスポンスで設定される Cookie だけです — 後から JavaScript、他のページ、第三者によって追加されるものは含まれません。Cookie の値を読み取ることはありません。

• フォームの動作

  フォームの存在は記録しますが送信はしないため、サーバー側の検証、CSRF 対策、レート制限はテストできません。

よく見つかる問題

• HSTS がない、または短すぎる

  すべてを HTTPS にリダイレクトしているサイトでも非常によく見られます。また、テスト時のまま残った数分の max-age では、ほとんど保護になりません。

• CSP がない、または許可範囲が広すぎる

  最もよく欠けているヘッダーです。設定されていても、script-src 内の 'unsafe-inline'、'unsafe-eval'、* によって、保護の大部分が無効になっていることがよくあります。

• クリックジャッキング対策がない

  X-Frame-Options も frame-ancestors ルールもない状態。

• 期限切れ間近の証明書

  たいていは、サーバーや DNS の変更後に自動更新が止まってしまったことが原因です。

• サーバーのバージョンが見えている

  「Server: Apache/2.4.41」や「X-Powered-By: PHP/7.4」のようなヘッダーは、攻撃者に狙いどころを教えてしまいます。

• リダイレクトされない HTTP

  http://yourdomain/ がまだページを配信しているか、一時的なリダイレクト（302）しかしていないため、ドメインだけを入力した訪問者が暗号化されていない状態で閲覧できてしまいます。

• Secure や HttpOnly のないセッション Cookie

  スクリプトから読み取れる、または暗号化されていない HTTP で送信される可能性のある、ログインやセッションの Cookie。

直し方

1. 1

   サイトを配信している場所でヘッダーを設定する

   ヘッダーは、ウェブサーバー（Nginx の add_header、Apache の Header set）、CDN、またはホスティングの設定やヘッダーファイルで設定します。実際にブラウザに届く値を確認するため、チェックを再実行してください。

2. 2

   HTTPS がすべてで機能したら HSTS を有効にする

   Strict-Transport-Security: max-age=31536000 を使ってください（当チェックで許容する最小値は 180 日です）。includeSubDomains は、すべてのサブドメインが HTTPS に対応している場合にだけ追加し、preload は最後にしてください。

3. 3

   CSP は段階的に強化する

   まず Content-Security-Policy-Report-Only から始め、その後で強制モードに切り替えます。'unsafe-inline' は nonce やハッシュに置き換え、'unsafe-eval' を削除し、* や https: の代わりに正確なスクリプトのオリジンを列挙し、object-src 'none' と base-uri 'self' を追加してください。

4. 4

   シンプルなヘッダーを追加する

   X-Content-Type-Options: nosniff、Referrer-Policy: strict-origin-when-cross-origin、X-Frame-Options: DENY（または SAMEORIGIN）は、何かを壊すことはほとんどありません。

5. 5

   証明書の更新とリダイレクトを自動化する

   マネージド証明書か、自動更新付きの Let's Encrypt を使い、すべての http:// へのリクエストを 301 または 308 で同じ https:// の URL にリダイレクトしてください。

6. 6

   バージョン番号を隠す

   バージョン情報の出力をオフにし（例：Nginx では server_tokens off、PHP では expose_php = Off）、意図しない限り本番環境でソースマップを公開しないでください。

7. 7

   Cookie にフラグを付ける

   HTTPS のサイトではすべての Cookie に Secure を付け、セッションやログインの Cookie には HttpOnly を追加し、SameSite=Lax（または Strict）を明示的に設定してください。SameSite=None には必ず Secure が必要です。