example.comレポート

スコアへの影響

• 配信されている検体の除去と侵入経路の遮断

  検査エンジン原文（英語）

  no malware-feed key is configured, so the feed could not be asked

  上昇幅: 算出していません

  理由: 公開情報からはこの項目を観測できませんでした。

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (未検査)

  リスク詳細

  サーバがマルウェアの配信元として記録されている場合、そこに置かれたファイルが実際に配布されています。多くは侵入した攻撃者が設置したもので、当該サーバは他者への攻撃の道具として使われている状態です。被害を受けるのは配布先の第三者であり、責任を問われるのは配信元です。

  対応手順

  1. 該当ファイルの削除から始めないでください。
  2. 先に、いつ・どの経路で設置されたかをアクセスログとファイルの更新時刻から確認します。
  3. 削除だけでは、同じ経路から再び設置されます。
  4. 侵入経路を塞ぎ、設置された他のファイル（Web シェル、cron への登録、改ざんされた設定）が無いことを確認したうえで除去してください。
  5. 作業後、配信元の一覧からの削除を申請します。
  関連用語

  • 総当たり攻撃 - パスワードや認証情報の組み合わせを片っ端から試して、正解を探し当てようとする攻撃。
  • 秘密鍵 - 持ち主だけが知っていることを前提に、暗号化や身元証明に使われる値。外部に漏れると持ち主になりすませてしまう。
  根拠データを表示 (1 件)

  • threat対象 example.com取得 2026/09/01 09:00 JST

    safe_browsing_asked

    false

    malware_feed_asked

    false

    unconfigured

    safe_browsing・malware_feed

    根拠 ID threat:threat.intel:example.com

• 警告の原因の除去と再審査の申請

  検査エンジン原文（英語）

  no threat-intelligence key is configured, so the service could not be asked

  上昇幅: 算出していません

  理由: 公開情報からはこの項目を観測できませんでした。

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (未検査)

  リスク詳細

  Google Safe Browsing に登録されると、Chrome・Safari・Firefox のいずれでも、サイトを開こうとした利用者に赤い警告画面が出ます。利用者は本文に到達しません。検索結果からも外れ、広告も配信できなくなります。原因の多くは、改ざんされて誘導が仕込まれたページか、利用者投稿を通じた不正な内容の掲載です。

  対応手順

  1. Google Search Console でサイトを登録し、「セキュリティの問題」に表示される該当ページを確認します。
  2. 指摘されたページだけを直しても再発します。
  3. 侵入経路（古いプラグイン、盗まれた管理者資格情報、書き込み可能なアップロード先）を塞いだうえで、Search Console から再審査を申請してください。
  4. 審査には数日かかります。
  関連用語

  • フィッシング - 実在する相手を装った連絡で、パスワードなどを利用者自身に入力させて盗み取る詐欺の手口。
  • サブドメイン乗っ取り - 使われなくなった外部サービスへの案内が残ったままのサブドメインを、第三者が代わりに登録して乗っ取ること。
  根拠データを表示 (1 件)

  • threat対象 example.com取得 2026/09/01 09:00 JST

    safe_browsing_asked

    false

    malware_feed_asked

    false

    unconfigured

    safe_browsing・malware_feed

    根拠 ID threat:threat.intel:example.com

スコアへの影響

この手順に出てくる example.com は記述例です。ご自身のドメイン名に読み替えてください（letsencrypt.org のように実在する第三者のホスト名も混ざっているため、機械的な置換はしていません）。

• 公開前のメタデータの除去

  検査エンジン原文（英語）

  the page links to no document on this site

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (対象外)

  リスク詳細

  PDF や Office の文書には、作成者名、最終更新者、使用したソフトウェアとその版数、保存元のファイルパスが埋め込まれます。パスには社内のファイルサーバ名やアカウント名がそのまま入ります。攻撃者にとっては、標的とする個人の氏名と、社内の構成を知る手がかりです。

  対応手順

  1. 本項目は警告です。
  2. 著者名を意図して載せている資料もあります。
  3. 確認すべきは、意図していない情報が入っていないかです。
  4. Word と Excel は「ファイル」→「情報」→「ドキュメント検査」で、個人情報と隠しデータを一括して削除できます。
  5. PDF は Acrobat の「墨消し」→「文書のサニタイズ」、または exiftool -all= file.pdf で除去します。
  6. 公開前の手順に組み込み、既に公開している文書についても順次確認してください。
  関連用語

  • フィッシング - 実在する相手を装った連絡で、パスワードなどを利用者自身に入力させて盗み取る詐欺の手口。
  • バナー - サーバーが接続してきた相手に返す、自分が使っているソフトウェアの名前や版数を含む応答。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• 資格情報の再発行と、履歴からの除去

  検査エンジン原文（英語）

  the site links to no public code repository

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (対象外)

  リスク詳細

  公開リポジトリに設定ファイルを含めてしまうと、その中の資格情報は誰でも取得できます。リポジトリを非公開に切り替えても、履歴を書き換えても、既に取得された内容は無効になりません。公開リポジトリを機械的に走査して資格情報を集める仕組みは常時稼働しており、公開から利用までは数分です。

  対応手順

  1. まず該当の資格情報を再発行し、古いものを無効化してください。
  2. リポジトリからの削除はその後です。
  3. 次に、履歴からも取り除きます（git filter-repo を使い、強制プッシュ後に共同作業者へ再クローンを依頼）。
  4. 再発防止として、.gitignore に設定ファイルを加え、コミット前に走査する仕組み（gitleaks、git-secrets）を導入してください。
  5. 設定値は環境変数か秘密管理の仕組みから渡します。
  関連用語

  • 秘密鍵 - 持ち主だけが知っていることを前提に、暗号化や身元証明に使われる値。外部に漏れると持ち主になりすませてしまう。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• BIMI レコードの書式の修正

  検査エンジン原文（英語）

  no BIMI record published; BIMI is optional

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (対象外)

  リスク詳細

  BIMI は、受信側のメール一覧に自社のロゴを表示させる仕組みです。表示されることで、差出人が本物であることが受信者の目に見える形になります。レコードの書式が誤っていると表示されないため、なりすましとの見分けが付きにくいままになります。

  対応手順

  1. default._bimi の TXT レコードに v=BIMI1; l=https://example.com/logo.svg; の形式で記載します。
  2. l= にはロゴの HTTPS の URL が必要です。
  3. ロゴは SVG Tiny Portable/Secure 形式に限られ、通常の SVG では表示されません。
  4. 主要な受信側では、加えて検証済マーク証明書（VMC）と DMARC の p=quarantine 以上が要求されます。
  5. 確認は dig +short TXT default._bimi.example.com で行います。
  関連用語

  • DMARC - 送信元の確認に失敗したメールを受信側がどう扱うか(そのまま届ける・迷惑メール扱いにする・拒否する)を指示する仕組み。
  • フィッシング - 実在する相手を装った連絡で、パスワードなどを利用者自身に入力させて盗み取る詐欺の手口。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• 外部の送付先ドメインへの認可レコードの追加

  検査エンジン原文（英語）

  no report address outside this domain

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (対象外)

  リスク詳細

  DMARC の集計レポートを自ドメイン外の宛先に送るには、受け取る側のドメインが認可のレコードを公開している必要があります（RFC 7489 第 7.1 節）。無い場合、規格に従う受信側はレポートを送りません。宛先の記載は正しいのにレポートが 1 通も届かない、という形で現れます。

  対応手順

  1. レポート分析サービスを使っている場合は、提供元が指定する認可レコードを公開します。
  2. 書式は example.com._report._dmarc.<提供元のドメメイン> の TXT に v=DMARC1 です。
  3. この設定は提供元側で行うことも多いため、まず提供元に確認してください。
  4. 自社の別ドメイン宛に送っている場合は、その別ドメイン側に同じ形式で追加します。
  5. 確認は dig +short TXT example.com._report._dmarc.<提供元のドメイン> で v=DMARC1 が返ることです。
  関連用語

  • DMARC - 送信元の確認に失敗したメールを受信側がどう扱うか(そのまま届ける・迷惑メール扱いにする・拒否する)を指示する仕組み。
  • 集計レポート - 誰がそのドメインを名乗ってメールを送っているかを、送信を受け取った側がまとめて送り返してくる定期報告。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• unsafe-eval と裸の unsafe-inline の除去

  検査エンジン原文（英語）

  no Content-Security-Policy to assess

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (対象外)

  リスク詳細

  `unsafe-inline` は、ページに書き込まれたスクリプトの実行を許可します。これは CSP が防ごうとしている当のものです。`unsafe-eval` は文字列をコードとして評価する経路を残します。どちらかを含む CSP は、ヘッダとしては存在していても、注入されたスクリプトを止めません。

  対応手順

  1. インラインスクリプトには nonce を付与します。
  2. 応答ごとに乱数を生成し、script-src 'nonce-<値>' として CSP に載せ、同じ値を <script nonce="<値>"> に書きます。
  3. nonce または hash を指定した時点で、それを解釈するブラウザは unsafe-inline を無視するため、古いブラウザ向けに残しても実効性は下がりません。
  4. unsafe-eval は、eval や new Function を使っているライブラリを特定して置き換えます。
  5. 確認は curl -sI https://example.com | grep -i content-security-policy と、ブラウザの開発者ツールのコンソールに違反が出ないことで行います。
  関連用語

  • CSP - ページの中で実行してよいスクリプトや読み込んでよい外部の場所を、あらかじめ限定しておく仕組み。
  • XSS - 本来のページには無いはずのスクリプトを第三者が紛れ込ませ、利用者のブラウザ上で動かしてしまう攻撃。
  • ノンス - 毎回作り直す使い捨ての値で、これと一致するものだけをそのページ限定で信用してよい印として使う。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

スコアへの影響

この手順に出てくる example.com は記述例です。ご自身のドメイン名に読み替えてください（letsencrypt.org のように実在する第三者のホスト名も混ざっているため、機械的な置換はしていません）。

• 発行済み証明書の把握

  検査エンジン原文（英語）

  1 certificates in the public logs, covering 2 names from 1 issuers

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  自社のドメイン名で証明書が発行されると、その事実は証明書透明性ログに公開されます。逆に言えば、意図しない発行もそこに現れます。身に覚えの無い名前や発行元があれば、DNS の乗っ取りか、社内の誰かが把握されていない経路で取得したかのどちらかです。

  対応手順

  1. 本項目は観測値の報告であり、減点しません。
  2. 一覧の名前と発行元に、把握していないものが無いかを確認してください。
  3. 心当たりの無い発行があった場合は、当該証明書の失効を発行元へ依頼し、DNS の管理権限とレジストラのアカウントを点検します。
  4. 継続的な監視には、CAA レコードで発行できる認証局を限定したうえで（dns.caa）、証明書透明性ログの通知サービスを設定する方法があります。
  関連用語

  • CT ログ - 発行された証明書を、誰でも確認できるよう公開の記録に残しておく仕組み。偽って発行された証明書もここに痕跡が残る。
  • 認証局 - サーバーの身元を確認したうえで証明書を発行する会社。
  • CAA レコード - そのドメインの証明書を発行してよい会社を、DNS の記録で指定しておく仕組み。
  • SAN - 1 枚の証明書に複数のドメイン名をまとめて登録できる欄。
  根拠データを表示 (1 件)

  • CT ログ（crt.sh + Cert Spotter）対象 example.com取得 2026/09/01 09:00 JST

    証明書

    1

    example.com, www.example.com

    C=US, O=Let's Encrypt, CN=R11 · 2099-01-01 → 2099-04-01

    根拠 ID crtsh:crtsh.certs:example.com

• 同形異字ドメインの把握

  検査エンジン原文（英語）

  none of the 15 variants checked is registered

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  アクセント付きのラテン文字や、数字の 0 と英字の o のように、画面上でほとんど区別の付かない文字があります。これらを 1 文字置き換えたドメインは、URL を目で確かめても本物と見分けが付きません。打ち間違いと違い、利用者の側に落ち度がありません。

  対応手順

  1. 本項目も観測の報告です。
  2. 一覧のドメインの所有者と、実際に置かれている内容を確認してください。
  3. 自社を騙る内容がある場合は、レジストラの不正利用窓口と、必要に応じて JPCERT/CC などの窓口へ通報します。
  4. 利用者向けには、メールに記載する URL を常に同じ形式にし、リンクの表示文字列と実際の宛先を一致させる運用が、見分けの助けになります。
  関連用語

  • フィッシング - 実在する相手を装った連絡で、パスワードなどを利用者自身に入力させて盗み取る詐欺の手口。
  根拠データを表示 (1 件)

  • dns-rep対象 example.com取得 2026/09/01 09:00 JST

    typos_tried

    42

    homoglyphs_tried

    15

    根拠 ID dns-rep:dns.lookalike:example.com

• 打ち間違い類似ドメインの把握

  検査エンジン原文（英語）

  none of the 42 variants checked is registered

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  1 文字違いのドメインは、急いで入力した利用者が実際に辿り着く先です。そこに似せたサインイン画面を置けば、資格情報がそのまま渡ります。取引先を騙る請求書メールの差出人にも使われます。この項目は当該ドメインの欠陥では無く、周辺の状況の報告です。

  対応手順

  1. 登録されていること自体が攻撃とは限りません。
  2. 同名の別事業者かもしれず、過去に自社で防衛登録したものかもしれません。
  3. まず一覧の各ドメインが誰のものかを確認してください。
  4. そのうえで、実際に自社を騙る内容が置かれている場合は、レジストラの不正利用窓口へ通報します。
  5. 利用者が入力を誤りやすい少数の綴りについては、自社で登録し、正規のドメインへ転送する運用が有効です。
  関連用語

  • フィッシング - 実在する相手を装った連絡で、パスワードなどを利用者自身に入力させて盗み取る詐欺の手口。
  根拠データを表示 (1 件)

  • dns-rep対象 example.com取得 2026/09/01 09:00 JST

    typos_tried

    42

    homoglyphs_tried

    15

    根拠 ID dns-rep:dns.lookalike:example.com

• 証明書の連鎖の完全性

  検査エンジン原文（英語）

  the certificates the server sends link up without a gap

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  サーバは、自身の証明書から信頼されたルート認証局まで辿れるだけの中間証明書を、握手の中で相手に渡す必要があります。渡していない場合、その中間証明書を手元に持っているブラウザでは通り、持っていない環境では失敗します。開発者の手元では再現せず、一部の利用者や、古い端末や、他社の連携システムだけが失敗するという形で現れます。

  対応手順

  1. 認証局が配布する中間証明書を、サーバ証明書に連結したファイルを設定します。
  2. nginx の ssl_certificate には「サーバ証明書 → 中間証明書」の順に連結したものを指定してください。
  3. Let's Encrypt では cert.pem では無く fullchain.pem がそれです。
  4. Apache は SSLCertificateChainFile、または同様に連結した SSLCertificateFile を使います。
  5. 確認は openssl s_client -connect example.com:443 -showcerts </dev/null の出力に、サーバ証明書に続いて中間証明書が並ぶことです。
  関連用語

  • 認証局 - サーバーの身元を確認したうえで証明書を発行する会社。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• apex および www を含む有効なサーバ証明書の存在

  検査エンジン原文（英語）

  1 valid certificates in CT logs

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  本項目の判定は Certificate Transparency ログの公開索引（crt.sh と Cert Spotter の 2 索引を突き合わせ）に基づきます。索引は高負荷時に空の応答を返すことがあり、その場合は「証明書が存在しない」ではなく「索引が回答しなかった」と解釈すべきです（2026-09-08 に、実在する有効な証明書がこの事象で検出されない例を確認しています）。索引に登録があるにもかかわらず有効なものが無い場合のみ要対応とし、索引が空の場合はデータ未取得として報告します。有効な証明書が無い、または名前が一致しない状態では、利用者はブラウザの警告を毎回無視して進むことになります。その運用が定着すると、経路上の攻撃者が用意した偽の証明書や平文通信への引き下げも「いつもの警告」として受け入れられてしまいます。

  対応手順

  1. まず実機で確認します: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -ext subjectAltName。
  2. 有効期限内で SAN に apex と www の双方が含まれていれば、この判定は索引側の取りこぼしによるものですので、時間をおいて再評価してください。
  3. 含まれていない場合は次に進みます。
  4. apex（example.com）と www の両方を SAN に含む証明書を発行し、配置します。
  5. Let's Encrypt であれば certbot --nginx -d example.com -d www.example.com、商用 CA であれば申請時に両方の名前を指定します。
  6. 配置後は nginx -t && systemctl reload nginx を実行します。
  7. 確認は openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -ext subjectAltName で両方の名前と将来の notAfter が表示されることをもって行います。
  8. 本項目は CT ログを参照するため、crt.sh に反映されるまで数分から数十分を要します。
  関連用語

  • 認証局 - サーバーの身元を確認したうえで証明書を発行する会社。
  • SAN - 1 枚の証明書に複数のドメイン名をまとめて登録できる欄。
  • apex ドメイン - www などを付けない、そのドメインそのものの名前。
  • CT ログ - 発行された証明書を、誰でも確認できるよう公開の記録に残しておく仕組み。偽って発行された証明書もここに痕跡が残る。
  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  根拠データを表示 (1 件)

  • CT ログ（crt.sh + Cert Spotter）対象 example.com取得 2026/09/01 09:00 JST

    証明書

    1

    example.com, www.example.com

    C=US, O=Let's Encrypt, CN=R11 · 2099-01-01 → 2099-04-01

    根拠 ID crtsh:crtsh.certs:example.com

• サーバ証明書の有効期限の余裕

  検査エンジン原文（英語）

  newest certificate valid for 26510 more days

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  証明書が失効すると、すべてのブラウザと API クライアントが接続を拒否します。復旧を急ぐ現場では「一時的に証明書検証を無効にする」回避策が導入されがちで、その状態は経路上の攻撃者にとって好都合です。

  対応手順

  1. 手作業での更新をやめ、自動化します。
  2. certbot であれば systemctl list-timers | grep certbot でタイマの稼働を確認し、certbot renew --dry-run が成功することを確かめます。
  3. acme.sh であれば acme.sh --cron --home ~/.acme.sh が crontab に登録されていることを確認します。
  4. 更新後のリロードは --deploy-hook "systemctl reload nginx" のようにフックで実施します。
  5. 本項目は残り 14 日以内で警告しますので、更新後に openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate で残り期間が 14 日を大きく超えていることを確認してください。
  6. 90 日証明書の自動更新であれば、通常 30 日以上の余裕が残ります。
  関連用語

  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  根拠データを表示 (1 件)

  • CT ログ（crt.sh + Cert Spotter）対象 example.com取得 2026/09/01 09:00 JST

    証明書

    1

    example.com, www.example.com

    C=US, O=Let's Encrypt, CN=R11 · 2099-01-01 → 2099-04-01

    根拠 ID crtsh:crtsh.certs:example.com

• 証明書の名前の一致

  検査エンジン原文（英語）

  the certificate covers this host name

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  証明書に記載された名前が接続先のホスト名と一致しない場合、ブラウザは警告画面を出して通信を止めます。利用者はそこで引き返すか、警告を無視する習慣を身につけるかのどちらかです。後者が定着すると、本物の中間者攻撃の警告も同じように無視されます。

  対応手順

  1. 証明書の SAN（subjectAltName）に、実際に案内しているホスト名をすべて記載して再発行します。
  2. apex と www を両方使っているのであれば両方が必要です。
  3. openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 'Subject Alternative Name' で現在の記載を確認できます。
  4. Let's Encrypt であれば certbot certonly -d example.com -d www.example.com のように、必要な名前をすべて -d で並べて取得し直します。
  5. 仮想ホストが複数ある場合、SNI で選ばれる証明書が意図したものかも併せて確認してください。
  関連用語

  • SAN - 1 枚の証明書に複数のドメイン名をまとめて登録できる欄。
  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  • apex ドメイン - www などを付けない、そのドメインそのものの名前。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• 証明書の鍵長

  検査エンジン原文（英語）

  ECDSA key of 256 bits

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  鍵が短いほど、計算によって秘密鍵を求められる可能性が上がります。秘密鍵が割り出された場合、攻撃者はその名前で正規の通信を装えます。RSA 1024 ビットは既に実用的な危険域にあり、公開認証局は 2048 ビット未満を発行しません。

  対応手順

  1. RSA であれば 2048 ビット以上、楕円曲線であれば P-256 以上で鍵を作り直し、証明書を再発行します。
  2. openssl genrsa -out key.pem 2048、または鍵長あたりの処理が軽い openssl ecparam -genkey -name prime256v1 -out key.pem を使います。
  3. Let's Encrypt では certbot certonly --key-type ecdsa -d example.com で楕円曲線の鍵になります。
  4. 鍵を作り直すと証明書も入れ替わるため、証明書の指紋を固定している連携先があれば事前に調整してください。
  関連用語

  • 秘密鍵 - 持ち主だけが知っていることを前提に、暗号化や身元証明に使われる値。外部に漏れると持ち主になりすませてしまう。
  • 鍵のピン留め - 特定の鍵だけを本物として扱うよう、あらかじめ値を固定しておくこと。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• 証明書の失効状態

  検査エンジン原文（英語）

  the stapled status says the certificate is not revoked

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  失効した証明書は、秘密鍵の漏えいか、誤発行か、そのいずれかが疑われたために取り消されたものです。取り消された鍵で通信を続けている場合、その鍵を持つ者は誰でも、こちらになりすませます。ブラウザの失効確認は失敗時に検証を省く実装が多く、利用者側では気づかれません。

  対応手順

  1. 直ちに新しい証明書を発行し、差し替えます。
  2. 同じ鍵で再発行してはいけません。
  3. 鍵の漏えいが失効の理由であれば、新しい鍵を作るところから始めます。
  4. 差し替え後、当該の鍵を使っていた他のサービス（メール、VPN、API）も併せて確認してください。
  5. 確認は公開されている認証局のCRL、または接続時に添付されたOCSP応答で失効していないことです。
  関連用語

  • 失効 - 発行済みの証明書を、期限が来る前に無効だと宣言すること。受け取った側がその宣言を毎回確かめてくれるとは限らない。
  • 秘密鍵 - 持ち主だけが知っていることを前提に、暗号化や身元証明に使われる値。外部に漏れると持ち主になりすませてしまう。
  • 認証局 - サーバーの身元を確認したうえで証明書を発行する会社。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• 公開認証局による証明書の発行

  検査エンジン原文（英語）

  the certificate is issued by a separate authority

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  自己署名証明書は、その証明書自身が「これは正しい」と言っているだけで、第三者による裏付けがありません。ブラウザは警告を出し、利用者はそれを無視して進むことになります。その状態では、攻撃者が別の自己署名証明書に差し替えても、利用者には同じ警告としか見えません。

  対応手順

  1. 公開認証局の証明書に交換します。
  2. Let's Encrypt であれば certbot --nginx -d example.com または certbot --apache -d example.com で取得と設定まで行えます。
  3. 取得には該当ドメインの制御を証明する必要があるため、80 番または DNS のいずれかを使える状態にしてください。
  4. 交換後、openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject で issuer と subject が別であることを確認します。
  5. 社内専用のホストであっても、自前の認証局を立てて端末に配布するのが筋であり、自己署名のまま運用しないでください。
  関連用語

  • 認証局 - サーバーの身元を確認したうえで証明書を発行する会社。
  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• 公開証明書への内部名の不記載

  検査エンジン原文（英語）

  no internal-looking host names in the public certificates

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  証明書は発行された時点で証明書透明性ログに公開され、誰でも検索できます。`staging.example.com` や `jenkins.example.com` を公開証明書に含めると、社内システムの構成そのものが一覧として外部に渡ります。攻撃者にとっては、どこを狙うかを決めるための地図です。

  対応手順

  1. 内部向けホストには、社内の認証局が発行した証明書を使い、公開認証局からは取得しません。
  2. 取得する場合もワイルドカード証明書 1 枚にまとめれば、個々の名前はログに出ません。
  3. 既に公開された名前は取り消せないため、当該ホストが外部から到達できないことをファイアウォールで確認し、名前が知られている前提で運用します。
  4. 現状は https://crt.sh/?q=%25.example.com で確認できます。
  関連用語

  • CT ログ - 発行された証明書を、誰でも確認できるよう公開の記録に残しておく仕組み。偽って発行された証明書もここに痕跡が残る。
  • SAN - 1 枚の証明書に複数のドメイン名をまとめて登録できる欄。
  • ワイルドカード証明書 - *.example.com のように、同じ名前の下にあるサブドメインをまとめて対象にできる証明書。
  • 認証局 - サーバーの身元を確認したうえで証明書を発行する会社。
  根拠データを表示 (1 件)

  • CT ログ（crt.sh + Cert Spotter）対象 example.com取得 2026/09/01 09:00 JST

    証明書

    1

    example.com, www.example.com

    C=US, O=Let's Encrypt, CN=R11 · 2099-01-01 → 2099-04-01

    根拠 ID crtsh:crtsh.certs:example.com

• 強い署名アルゴリズム

  検査エンジン原文（英語）

  signed with SHA256-RSA

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  SHA-1 と MD5 は、異なる内容から同じ署名値を作る手口が実証済みです。攻撃者が同じ署名で通る別の証明書を用意できれば、認証局の裏付けを迂回できます。主要なブラウザは既にこれらの署名を拒否しています。

  対応手順

  1. SHA-256 以上の署名で証明書を再発行します。
  2. 現在の公開認証局は既定で SHA-256 を使うため、通常は再取得するだけで解消します。
  3. openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep 'Signature Algorithm' で確認してください。
  4. 社内の認証局を使っている場合は、認証局側の既定の署名方式も併せて見直します。
  関連用語

  • 認証局 - サーバーの身元を確認したうえで証明書を発行する会社。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• 信頼された認証局までの連鎖

  検査エンジン原文（英語）

  the chain reaches a trusted root

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  証明書の連鎖がブラウザの信頼するルート認証局まで届かない場合、証明書そのものが正規のものであっても検証は失敗します。原因の多くは中間証明書の設定漏れです。手元のブラウザでは通るのに一部の環境だけで警告が出る、という形で現れるため、気づかれないまま放置されがちです。

  対応手順

  1. 認証局が配布する中間証明書を、サーバ証明書と同じファイルに連結して配置します。
  2. nginx は ssl_certificate に「サーバ証明書 → 中間証明書」の順で連結した fullchain を指定します。
  3. Let's Encrypt であれば cert.pem ではなく fullchain.pem です。
  4. Apache は SSLCertificateChainFile、または同様に連結した SSLCertificateFile を使います。
  5. 設定後、openssl s_client -connect example.com:443 -servername example.com </dev/null の出力末尾が Verify return code: 0 (ok) になることを確認してください。
  関連用語

  • 認証局 - サーバーの身元を確認したうえで証明書を発行する会社。
  • 失効 - 発行済みの証明書を、期限が来る前に無効だと宣言すること。受け取った側がその宣言を毎回確かめてくれるとは限らない。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• ゾーン転送の拒否

  検査エンジン原文（英語）

  all 2 name servers refuse a zone transfer

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  ゾーン転送を誰にでも許している場合、そのドメインのレコードが 1 回の問い合わせで丸ごと取得できます。公開していないつもりのホスト名、開発環境、内部システムの名前まで、一覧として渡ります。攻撃者は、どこに何があるかを推測する必要がなくなります。

  対応手順

  1. 副の権威 DNS のアドレスだけに限定します。
  2. BIND は allow-transfer { 203.0.113.53; }; をゾーンまたは options に記載し、可能であれば TSIG 鍵での認証を併用します。
  3. PowerDNS は allow-axfr-ips を設定します。
  4. 外部の DNS サービスを使っている場合は、既定で拒否されているのが通常ですが、二次 DNS を併用しているときは設定を確認してください。
  5. 確認は dig AXFR example.com @ns1.example.com が Transfer failed を返すことです。
  関連用語

  • ゾーン転送 - ある権威サーバーが持つドメインの記録一式を、別の権威サーバーへまるごと複製する仕組み。
  • 権威 DNS サーバー - そのドメインについての正式な答えを持ち、他のサーバーからの問い合わせに答える役目のサーバー。
  根拠データを表示 (1 件)

  • dns-auth対象 example.com取得 2026/09/01 09:00 JST

    child_ns

    ns1.example.net・ns2.example.net

    根拠 ID dns-auth:dns.authority:example.com

• 親子ゾーンの NS の整合

  検査エンジン原文（英語）

  the delegation matches the zone's NS records

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  レジストラに登録した委任先と、ゾーン自身が公開している NS レコードが食い違っている場合、解決の経路によって別のサーバに問い合わせが向かいます。古い側のサーバがまだ応答していれば、更新前の内容が返り続けます。応答が止まっていれば、そのサーバに当たった問い合わせは失敗します。いずれも「時々つながらない」という、原因の掴みにくい形で現れます。

  対応手順

  1. レジストラの管理画面でネームサーバの一覧を確認し、ゾーンの NS レコードと一致させます。
  2. どちらを正とするかを決め、両方を揃えてください。
  3. ゾーンを移設した直後や、DNS 事業者を変更した直後に食い違うことが多くあります。
  4. 確認は、dig +short NS example.com と、上位ゾーンへ直接問い合わせた dig +norecurse NS example.com @<上位の NS> の結果が一致することです。
  関連用語

  • 委任 - あるドメインについての回答を、親の側が特定のサーバー群に任せると宣言すること。
  • 権威 DNS サーバー - そのドメインについての正式な答えを持ち、他のサーバーからの問い合わせに答える役目のサーバー。
  根拠データを表示 (1 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

• 権威 DNS のネットワーク分散

  検査エンジン原文（英語）

  name servers span 2 networks

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  権威 DNS が同じネットワークに固まっている場合、そのネットワークの障害や攻撃で全台が同時に応答を止めます。名前が引けなくなれば、Web もメールも到達しません。台数だけを増やしても、置き場所が同じであれば冗長にはなりません。

  対応手順

  1. 1 台以上を別の事業者、別のネットワークに置きます。
  2. 外部の DNS ホスティングを 2 社併用するのが最も手早く、レジストラの管理画面でネームサーバを両社のものに設定します。
  3. ゾーンの内容は両者で同期させ、片方だけを更新しないよう手順を決めてください。
  4. 設定後、dig +short NS example.com の各ホストを dig +short で引き、返る IP アドレスが別のネットワークにあることを確認します。
  関連用語

  • 権威 DNS サーバー - そのドメインについての正式な答えを持ち、他のサーバーからの問い合わせに答える役目のサーバー。
  • 委任 - あるドメインについての回答を、親の側が特定のサーバー群に任せると宣言すること。
  根拠データを表示 (1 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

• 権威 DNS サーバの冗長化

  検査エンジン原文（英語）

  2 name servers

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  権威サーバが 1 台のみの場合、そのサーバが停止した時点でドメイン全体の名前解決ができなくなります。乗っ取られた場合の影響はさらに大きく、A・MX・ACME のチャレンジ応答がすべて攻撃者の任意の値となり、正規の証明書まで発行される恐れがあります。

  対応手順

  1. 別系統のインフラに権威サーバをもう 1 台以上用意します。
  2. 別事業者の DNS を併用するか、BIND であればプライマリ側で also-notify / allow-transfer を設定し、もう一方を type secondary; としてゾーン転送を構成します。
  3. 用意後は、レジストラ側の NS 設定に全サーバを登録してください。
  4. ここを更新しない限り、親ゾーンの委任は 1 台のままです。
  5. 確認は dig +trace NS example.com の最後の委任（親 TLD の権威サーバが返す NS）に全サーバが並ぶこと、および各サーバへの dig SOA example.com @<ns> が同一のシリアルを返すことで行います。
  関連用語

  • 権威 DNS サーバー - そのドメインについての正式な答えを持ち、他のサーバーからの問い合わせに答える役目のサーバー。
  • 委任 - あるドメインについての回答を、親の側が特定のサーバー群に任せると宣言すること。
  • ゾーン転送 - ある権威サーバーが持つドメインの記録一式を、別の権威サーバーへまるごと複製する仕組み。
  • SOA レコード - ゾーンの管理情報と、内容が更新されるたびに増える通し番号を持つ DNS の記録。
  • ACME チャレンジ - 証明書を自動発行する際に、そのドメインを本当に管理しているかを確認するための応答のやり取り。
  根拠データを表示 (1 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

• 再帰問い合わせの非提供

  検査エンジン原文（英語）

  none of the 2 name servers resolves for strangers

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  権威 DNS が誰の問い合わせにも再帰的に応答する場合、そのサーバは DNS リフレクション攻撃の増幅器として使われます。小さな問い合わせに大きな応答を返す性質を利用され、送信元を詐称された第三者へ大量の通信が向けられます。被害を受けるのは第三者ですが、送信元として記録されるのはこちらのサーバです。

  対応手順

  1. 権威 DNS では再帰を無効にします。
  2. BIND は options に recursion no; と allow-recursion { none; }; を記載します。
  3. PowerDNS は権威サーバと再帰サーバが別の製品であるため、権威側に再帰の設定はありません。
  4. 社内向けの再帰サーバが必要な場合は、権威 DNS とは別のサーバとして立て、社内からの問い合わせだけを受け付けるようにします。
  5. 確認は dig @ns1.example.com example.org が REFUSED を返すことです。
  関連用語

  • 権威 DNS サーバー - そのドメインについての正式な答えを持ち、他のサーバーからの問い合わせに答える役目のサーバー。
  • 総当たり攻撃 - パスワードや認証情報の組み合わせを片っ端から試して、正解を探し当てようとする攻撃。
  根拠データを表示 (1 件)

  • dns-auth対象 example.com取得 2026/09/01 09:00 JST

    child_ns

    ns1.example.net・ns2.example.net

    根拠 ID dns-auth:dns.authority:example.com

• SOA タイマの妥当性

  検査エンジン原文（英語）

  SOA timers are within the usual range

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  SOA のタイマは、副の権威 DNS が主から情報を取り直す間隔と、取り直せない状態が続いたときに応答をやめるまでの猶予を決めます。expire が短すぎると、主が短期間止まっただけでゾーン全体が消えます。retry が refresh より長いと、失敗したあとの再試行が通常の更新より遅くなり、意図と逆になります。

  対応手順

  1. refresh は 20 分から 24 時間、retry は 2 分から 2 時間かつ refresh より短く、expire は 2 週間から 8 週間、minimum は 5 分から 24 時間の範囲に収めます。
  2. ゾーンファイルの SOA 行を編集し、シリアル値を増やしてから再読み込みします。
  3. 外部の DNS サービスを使っている場合は管理画面の該当項目です。
  4. 確認は dig +short SOA example.com の後半 4 つの数値で行います。
  関連用語

  • SOA レコード - ゾーンの管理情報と、内容が更新されるたびに増える通し番号を持つ DNS の記録。
  • 権威 DNS サーバー - そのドメインについての正式な答えを持ち、他のサーバーからの問い合わせに答える役目のサーバー。
  根拠データを表示 (1 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

• サブドメインの参照先の実在

  検査エンジン原文（英語）

  none of the 1 subdomains points at a claimable name

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  外部サービスを解約したあと、そのサービスを指す CNAME をゾーンに残していると、同じ名前を後から取得した者が、こちらのサブドメインで自由に内容を配信できます。証明書も取得できるため、鍵マークの付いた本物のドメインで偽のページが動きます。利用者にも、ブラウザにも、見分けは付きません。

  対応手順

  1. 参照先が消えている CNAME をゾーンから削除します。
  2. 削除の順序が重要です。
  3. 外部サービスを解約する前に、まず DNS のレコードを消してください。
  4. 逆の順序では、解約からレコード削除までの間、名前が空いた状態になります。
  5. 既に空いている場合は、直ちにレコードを削除したうえで、その名前で証明書が発行されていないかを https://crt.sh/?q=<サブドメイン> で確認します。
  6. 確認は dig +short <サブドメイン> が何も返さないことです。
  関連用語

  • サブドメイン乗っ取り - 使われなくなった外部サービスへの案内が残ったままのサブドメインを、第三者が代わりに登録して乗っ取ること。
  • CT ログ - 発行された証明書を、誰でも確認できるよう公開の記録に残しておく仕組み。偽って発行された証明書もここに痕跡が残る。
  • フィッシング - 実在する相手を装った連絡で、パスワードなどを利用者自身に入力させて盗み取る詐欺の手口。
  根拠データを表示 (1 件)

  • DNS 応答対象 api.example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.2

    根拠 ID dns-sub:dns.host:api.example.com

• ワイルドカード DNS の統制

  検査エンジン原文（英語）

  an unregistered name does not resolve

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  ワイルドカードを置いたゾーンは、存在しない名前にも応答します。綴りを間違えた名前がそれらしく開いてしまうため、利用者は誤りに気づけません。攻撃者にとっては、任意の名前で証明書を取り、こちらのドメインで動く偽のページを用意する足がかりになります。

  対応手順

  1. ゾーンから * のレコードを削除し、必要なホスト名を個別に定義します。
  2. ワイルドカードを意図して使っている場合（利用者ごとのサブドメインを動的に割り当てる構成など）は、その旨を運用手順に明記し、ワイルドカード証明書の管理と、未使用の名前へのアクセスの扱いを併せて定めてください。
  3. 確認は、無作為な名前を dig +short random-name-check.example.com で引き、何も返らないことです。
  関連用語

  • サブドメイン乗っ取り - 使われなくなった外部サービスへの案内が残ったままのサブドメインを、第三者が代わりに登録して乗っ取ること。
  • ワイルドカード証明書 - *.example.com のように、同じ名前の下にあるサブドメインをまとめて対象にできる証明書。
  根拠データを表示 (1 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

• ドメイン登録の有効期間

  検査エンジン原文（英語）

  the registration runs for another 26644 days

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  ドメインの登録が切れると、Web もメールも一斉に止まります。さらに、一定の期間を過ぎたドメインは第三者が取得できる状態になり、そこで発行された証明書と受信されたメールは、こちらの名前で行われたことになります。失効は設定の誤りでは無く、更新の失念で起きます。

  対応手順

  1. レジストラの管理画面で自動更新を有効にし、登録に使っているクレジットカードの有効期限も併せて確認します。
  2. 連絡先のメールアドレスが現に受信できるものであることも重要です。
  3. 更新通知はそのアドレスにしか届きません。
  4. 担当者個人のアドレスでは無く、部署の共有アドレスにしてください。
  5. あわせて、期限の 60 日前と 30 日前に通知が出るよう、社内の監視に登録します。
  6. 確認は whois example.com の Expiry Date です。
  関連用語

  • サブドメイン乗っ取り - 使われなくなった外部サービスへの案内が残ったままのサブドメインを、第三者が代わりに登録して乗っ取ること。
  • フィッシング - 実在する相手を装った連絡で、パスワードなどを利用者自身に入力させて盗み取る詐欺の手口。
  根拠データを表示 (1 件)

  • rdap対象 example.com取得 2026/09/01 09:00 JST

    found

    true

    service_available

    true

    expiration

    2099-08-13T00:00:00Z

    registration

    0001-01-01T00:00:00Z

    last_changed

    0001-01-01T00:00:00Z

    statuses

    clienttransferprohibited・clientdeleteprohibited

    registrar

    Example Registrar, Inc.

    根拠 ID rdap:rdap.domain:example.com

• レジストラの移転ロック

  検査エンジン原文（英語）

  the registration carries the transfer and delete locks

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  移転ロックが掛かっていない場合、レジストラの管理画面に侵入した者は、そのままドメインを別のレジストラへ移せます。移転が完了すると、こちらから取り戻す手続きは著しく困難になります。ドメインを失うことは、Web とメールと、その名前で発行される証明書のすべてを失うことです。

  対応手順

  1. レジストラの管理画面で、移転ロック（clientTransferProhibited）と削除ロック（clientDeleteProhibited）を有効にします。
  2. 多くのレジストラでは既定で有効ですが、過去に移転を行った際に解除したまま戻していない例があります。
  3. あわせて、レジストラのアカウントに多要素認証を設定してください。
  4. ロックはレジストラのアカウントを守るものでは無く、侵入された後の被害を抑えるものです。
  5. 確認は whois example.com の Domain Status です。
  関連用語

  • 多要素認証 - パスワードだけでなく、手元の端末に届く確認コードなど別の要素も合わせて確かめる本人確認の方法。
  根拠データを表示 (1 件)

  • rdap対象 example.com取得 2026/09/01 09:00 JST

    found

    true

    service_available

    true

    expiration

    2099-08-13T00:00:00Z

    registration

    0001-01-01T00:00:00Z

    last_changed

    0001-01-01T00:00:00Z

    statuses

    clienttransferprohibited・clientdeleteprohibited

    registrar

    Example Registrar, Inc.

    根拠 ID rdap:rdap.domain:example.com

• API 仕様の公開範囲

  検査エンジン原文（英語）

  no API specification is served at the checked paths

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  OpenAPI の定義や仕様の閲覧画面は、利用できる操作、引数、内部の識別子の形式を網羅した一覧です。公開を意図している場合は問題ありませんが、社内向けの API や管理用の操作まで同じ定義に含まれていることがあります。攻撃者にとっては、試すべき操作を列挙する手間が省けます。

  対応手順

  1. 本項目は警告です。
  2. 公開している API 仕様それ自体は正当な運用です。
  3. 確認すべきは、その定義に社内向けの操作や管理用の経路が含まれていないかです。
  4. 含まれている場合は、公開用と内部用で定義を分けるか、仕様の閲覧画面を認証の内側に置きます。
  5. 認証が要る操作については、認証が実際に効いていることを併せて確認してください。
  6. 仕様が公開されていること自体は脆弱性では無く、仕様どおりに認可が効いていないことが脆弱性です。
  根拠データを表示 (1 件)

  • http対象 example.com取得 2026/09/01 09:00 JST

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    根拠 ID http:http.probes:example.com

• バナーにおけるバージョン情報の非開示

  検査エンジン原文（英語）

  no issues across indexed hosts

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  公開索引には、当該ホストのバージョン付き CPE が記録されています。これはホスト自身がバージョンを応答したためであり、攻撃者はそれを参照するだけで当該バージョンに有効な既知の脆弱性を絞り込めます。この影響は実際の修正適用状況とは無関係に生じます。索引は応答されたバージョンで CVE を突き合わせるため、修正済みのホストであっても「脆弱な nginx」の一覧に掲載され続け、その一覧が標的リストとして利用されます。

  対応手順

  1. nginx であれば http ブロックに server_tokens off; を追加し、nginx -t && systemctl reload nginx を実行します。
  2. Apache であれば ServerTokens Prod と ServerSignature Off を設定します。
  3. Postfix であれば smtpd_banner = $myhostname ESMTP とします。
  4. アプリケーション側では X-Powered-By 等のヘッダを除去します。
  5. 確認は curl -sI https://example.com | grep -i '^server:' がバージョンを含まないことで行います。
  6. バージョンの非開示は防御そのものではなく、更新の代替にはなりません。
  7. 公開索引の表示は次回スキャンまで更新されません。
  関連用語

  • バナー - サーバーが接続してきた相手に返す、自分が使っているソフトウェアの名前や版数を含む応答。
  • CVE - 世の中に見つかったソフトウェアの欠陥それぞれに振られる、共通の識別番号。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• クロスドメインポリシーの統制

  検査エンジン原文（英語）

  no cross-domain policy file is served

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  `crossdomain.xml` は Flash と Silverlight のための設定で、いずれも提供が終了しています。`domain="*"` を含む場合、当時の実装では任意のサイトがこちらのドメインに対して資格情報付きの要求を行えました。現在のブラウザは読みませんが、ファイルが残っているということは、そのポリシーが必要だった時期の設定が見直されないまま残っているという意味です。

  対応手順

  1. 使っている Flash も Silverlight も無いのであれば、crossdomain.xml と clientaccesspolicy.xml を削除します。
  2. 削除できない事情がある場合は、domain="*" を具体的なドメイン名に置き換えてください。
  3. 現在のオリジン間の制御は CORS（web.cors）で行います。
  4. 確認は curl -sI https://example.com/crossdomain.xml が 404 を返すことです。
  根拠データを表示 (1 件)

  • http対象 example.com取得 2026/09/01 09:00 JST

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    根拠 ID http:http.probes:example.com

• データベースの非公開

  検査エンジン原文（英語）

  no issues across indexed hosts

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  Redis・Memcached・Elasticsearch・MongoDB は既定で認証を持ちません。インターネットから届く状態にした時点で、誰でも中身を読み書きできます。MySQL・PostgreSQL・SQL Server は認証こそありますが、公開されていれば総当たり攻撃の最初の標的になります。いずれも信頼できる内部ネットワークを前提に設計されたものです。

  対応手順

  1. 各データベースを内部アドレスに bind します。
  2. MySQL は mysqld.cnf の bind-address = 127.0.0.1、PostgreSQL は postgresql.conf の listen_addresses = 'localhost'、Redis は redis.conf の bind 127.0.0.1 と protected-mode yes、Elasticsearch は elasticsearch.yml の network.host: 127.0.0.1、MongoDB は mongod.conf の net.bindIp: 127.0.0.1 です。
  3. アプリケーションが別ホストにある場合は、ファイアウォールまたはセキュリティグループでそのサブネットのみに限定します。
  4. 再起動後、外部から nmap -Pn -p 1433,3306,5432,6379,9200,11211,27017 <ip> が open を返さないこと、およびアプリケーションから従来どおり接続できることの両方を確認します。
  関連用語

  • 総当たり攻撃 - パスワードや認証情報の組み合わせを片っ端から試して、正解を探し当てようとする攻撃。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• 既定ページの不放置

  検査エンジン原文（英語）

  the response is a configured site, not a stock page

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  サーバソフトウェアの初期ページが表示されるということは、その名前に対して誰も設定を行っていないという意味です。放置された仮想ホストは、更新の対象から外れたまま古い版で動き続けます。攻撃者にとっては、管理が行き届いていない入口を示す目印です。

  対応手順

  1. その名前を使う予定が無ければ、DNS のレコードを削除します。
  2. サーバ側では、想定していない Host ヘッダの要求に対して既定の仮想ホストが応答しないよう設定します。
  3. nginx では server_name _; の既定サーバを用意し return 444; とし、Apache では最初の VirtualHost を同様の扱いにします。
  4. 確認は curl -sI https://example.com/ が想定した応答を返すことです。
  関連用語

  • バナー - サーバーが接続してきた相手に返す、自分が使っているソフトウェアの名前や版数を含む応答。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• 開発・運用ツールの管理画面の非公開

  検査エンジン原文（英語）

  no issues across indexed hosts

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  Jenkins・GitLab・Grafana・Kibana などの管理画面は、公開された時点で、そこに映る情報そのものが下調べの材料になります。多くは初期設定のまま匿名閲覧を許し、Jenkins のようにジョブ実行からホスト上のコマンド実行につながるものもあります。本項目は公開索引が記録した製品の指紋で判定するため、既定以外のポートに移していても検出されます。

  対応手順

  1. 管理画面をインターネットから直接到達できない場所へ移します。
  2. VPN か踏み台の内側に置くか、リバースプロキシで認証を前置し、到達元のアドレスを限定します。
  3. ポート番号を変えるだけでは対処になりません。
  4. 索引は製品の指紋で認識しており、番号を変えても記録は残ります。
  5. あわせて各製品の匿名アクセスを無効にします（Jenkins は Configure Global Security で Anonymous の権限を外す、Grafana は grafana.ini の [auth.anonymous] enabled = false）。
  6. 公開索引の表示は次回スキャンまで更新されません。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• ディレクトリ一覧の無効化

  検査エンジン原文（英語）

  none of the checked directories lists its contents

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  索引ファイルの無いディレクトリで一覧表示が有効になっていると、そこに置いてある全ファイルの名前が見えます。作業用の控えや、公開する前の資料、命名から用途が分かる管理用のファイルまで、意図せず一覧に載ります。攻撃者にとっては、推測せずに中身を確かめられる場所です。

  対応手順

  1. nginx は既定で無効ですが、有効にしている場合は autoindex off; に戻します。
  2. Apache は該当ディレクトリの Options から Indexes を外し、Options -Indexes とします。
  3. 設定後、curl -s https://example.com/uploads/ | head が一覧を返さないことを確認してください。
  4. あわせて、公開領域に置いたままになっている作業用ファイルの有無も見直します。
  根拠データを表示 (1 件)

  • http対象 example.com取得 2026/09/01 09:00 JST

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    根拠 ID http:http.probes:example.com

• 平文の旧式プロトコルの停止

  検査エンジン原文（英語）

  no issues across indexed hosts

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  FTP と Telnet は認証情報も本文も平文で流します。経路上にいる者は、そのまま利用者名とパスワードを読み取れます。TFTP には認証そのものがなく、ファイル名を知っていれば誰でも取得できます。いずれも暗号化された代替が広く使えるようになった現在、公開しておく理由がありません。

  対応手順

  1. FTP（21）は SFTP または FTPS に、Telnet（23）は SSH に置き換え、旧いデーモンを停止します。
  2. systemctl disable --now vsftpd や systemctl disable --now telnet.socket のように停止したうえで、ファイアウォールでも遮断します。
  3. TFTP（69/udp）は装置の起動用途に限り、内部ネットワークだけに閉じます。
  4. 確認は外部から nmap -Pn -p 21,23 <ip> と nmap -Pn -sU -p 69 <ip> が open を返さないことで行います。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• 基盤管理 API の非公開

  検査エンジン原文（英語）

  no issues across indexed hosts

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  Docker の API（2375、2376）と Kubernetes の API サーバ（6443）、kubelet（10250）は、いずれもホスト上で任意のコンテナを起動できる権限に直結します。とくに 2375 は暗号化も認証も持たないため、到達できる者はそのホストで実質的に root を取得できます。基盤全体が一度に奪われる経路です。

  対応手順

  1. これらの API をインターネットに向けて公開しません。
  2. Docker は dockerd の -H tcp:// を外し、Unix ソケットのみで待ち受けます。
  3. 遠隔から使う必要がある場合は 2376 で TLS 相互認証を有効にし、到達元も限定します。
  4. Kubernetes の API サーバは限定したネットワークまたは踏み台の内側に置き、kubelet の匿名アクセスは --anonymous-auth=false で無効にします。
  5. 確認は外部から nmap -Pn -p 2375,2376,6443,10250 <ip> が open を返さないことで行います。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• 公開サービス数の最小化

  検査エンジン原文（英語）

  no issues across indexed hosts

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  待受が 1 つ増えるごとに、適用すべきパッチと、攻撃者がバージョンを照合できるバナーが 1 つ増えます。公開ポートが多いホストには、管理者が把握していないサービスが含まれていることが少なくありません。

  対応手順

  1. まず ss -tulpn で実際に待ち受けているサービスを一覧化し、1 つずつ「停止する（systemctl disable --now <unit>）」「localhost または内部 NIC に bind する」「意図して公開する」のいずれかに分類します。
  2. そのうえで境界を既定拒否に設定します（ufw default deny incoming に必要なポートのみ allow を追加、クラウドでは列挙したポートのみのセキュリティグループ）。
  3. 本項目は 1 ホストあたりの公開ポートが 10 を超えると警告しますので、確認は外部から nmap -Pn --top-ports 1000 <ip> を各ホストに実行し、open が 10 以下であることをもって行います。
  関連用語

  • バナー - サーバーが接続してきた相手に返す、自分が使っているソフトウェアの名前や版数を含む応答。
  • セキュリティグループ - クラウド事業者が提供する、通信の送信元や宛先ごとに許可・拒否を設定する仕組み。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• リモートデスクトップの非公開

  検査エンジン原文（英語）

  no issues across indexed hosts

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  RDP と VNC がインターネットから届く状態は、認証情報の総当たり攻撃が常時発生することを意味します。RDP は過去に認証前の遠隔コード実行の脆弱性が繰り返し見つかっており、公開されているだけで危険が続きます。VNC は設定によっては認証なしで画面を渡します。

  対応手順

  1. RDP（3389）と VNC（5900）をインターネットに向けて公開しません。
  2. VPN または踏み台サーバの内側に置き、ファイアウォールで到達元を限定します。
  3. ufw であれば ufw allow from 203.0.113.0/24 to any port 3389 proto tcp を登録したうえで ufw deny 3389 を追加し、ufw status numbered で既存の無条件許可が残っていないか確認します。
  4. クラウドではセキュリティグループで同じ制限を行います。
  5. 確認は外部から nmap -Pn -p 3389,5900 <ip> を実行し、open ではなく filtered が返ることで行います。
  関連用語

  • 総当たり攻撃 - パスワードや認証情報の組み合わせを片っ端から試して、正解を探し当てようとする攻撃。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• 非公開ファイルの非提供

  検査エンジン原文（英語）

  none of the checked sensitive paths is served

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  `.git/config` が読める場合、リポジトリ全体を取得できることがあります。`.env` はデータベースの資格情報や API キーをそのまま含みます。いずれも配置の誤りで公開されるもので、攻撃者は自動化した走査で日常的にこれらを探しています。読まれた時点で、内部の資格情報が渡ったものとして扱う必要があります。

  対応手順

  1. まず該当ファイルを公開領域から取り除きます。
  2. 次に、読まれた前提で資格情報をすべて更新してください。
  3. ファイルを消すだけでは、既に取得された内容は無効になりません。
  4. 再発防止として、Web サーバでドットから始まるパスへのアクセスを拒否します。
  5. nginx は location ~ /\. { deny all; }、Apache は <FilesMatch "^\.">Require all denied</FilesMatch> です。
  6. デプロイの手順を、リポジトリごとコピーする方式から、必要な成果物だけを配置する方式へ変えることが根本的な対策です。
  関連用語

  • 秘密鍵 - 持ち主だけが知っていることを前提に、暗号化や身元証明に使われる値。外部に漏れると持ち主になりすませてしまう。
  • 総当たり攻撃 - パスワードや認証情報の組み合わせを片っ端から試して、正解を探し当てようとする攻撃。
  根拠データを表示 (1 件)

  • http対象 example.com取得 2026/09/01 09:00 JST

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    根拠 ID http:http.probes:example.com

• ファイル共有の非公開

  検査エンジン原文（英語）

  no issues across indexed hosts

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  SMB はインターネットに向けて公開する設計ではありません。公開されていれば、共有の一覧と認証情報の総当たりを許し、過去には認証前に遠隔コード実行を許す脆弱性が広く悪用されました。ランサムウェアの侵入口として最も知られた経路の一つです。

  対応手順

  1. SMB（139、445）をインターネットから遮断します。
  2. ファイアウォールで内部ネットワークのみに限定するか、境界で破棄します。
  3. 外部からファイルを渡す必要がある場合は SMB ではなく SFTP か HTTPS を使います。
  4. Windows であればプロファイル別のファイアウォール規則で、パブリック プロファイルの「ファイルとプリンターの共有」を無効にします。
  5. 確認は外部から nmap -Pn -p 139,445 <ip> が open を返さないことで行います。
  関連用語

  • 総当たり攻撃 - パスワードや認証情報の組み合わせを片っ端から試して、正解を探し当てようとする攻撃。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• SNMP の非公開

  検査エンジン原文（英語）

  no issues across indexed hosts

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  SNMP v1 と v2c の community 文字列は平文で流れ、既定値の public が残っていることも珍しくありません。読めるだけでも、稼働しているプロセス、ネットワーク構成、機器の型番と版数が一覧で取得でき、次の攻撃の下調べがそのまま完了します。UDP のため、送信元を偽った増幅攻撃の踏み台にも使われます。

  対応手順

  1. SNMP（161/udp）をインターネットから遮断し、監視サーバのアドレスのみに限定します。
  2. あわせて v1 と v2c を止め、認証と暗号化のある v3 に移行します。
  3. net-snmp であれば snmpd.conf の rocommunity 行を削除し、createUser と rouser で v3 の利用者を定義します。
  4. 既定の community 文字列 public と private は残さないでください。
  5. 確認は監視サーバ以外から nmap -Pn -sU -p 161 <ip> が open を返さないことで行います。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• 公開バージョンに紐づく既知脆弱性（CVE）の不在

  検査エンジン原文（英語）

  no issues across indexed hosts

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  本項目で示す CVE は、公開しているバナーのバージョンを公開索引が CVE データベースと機械的に突き合わせた結果です。この方法ではディストリビューションによるバックポート修正を判別できません。Ubuntu や Debian は修正を取り込んでもアップストリームのバージョン番号を変更しないため、修正済みのホストと未修正のホストは外部からは同一の文字列に見えます（実例: nginx 1.24.0-2ubuntu7.17 は CVE-2025-23419 と CVE-2023-44487 の修正を適用済みでありながら、両 CVE とも索引に掲載されていました）。ただし放置してよいわけではありません。同じ索引はそのまま標的リストとして利用され、索引に掲載される程度に知られた CVE には実証コードが出回っていることが一般的です。

  対応手順

  1. まず実機で確認します。
  2. deb 系であれば dpkg -l <パッケージ> で導入バージョンを確認し、zcat /usr/share/doc/<パッケージ>/changelog.Debian.gz | grep CVE-XXXX-NNNNN に当該 CVE の修正記載があるか、その版が導入版以下であるかを確認します。
  3. rpm 系であれば rpm -q --changelog <パッケージ> | grep CVE-XXXX-NNNNN を用います。
  4. 修正が適用済みであれば、当該 CVE についてこのホストは該当しません。
  5. 索引の表示は次回スキャンまで更新されないため、掲載が消えるのを待つ必要はありません。
  6. 未適用であれば更新します（apt update && apt upgrade または dnf upgrade の後にサービスを再起動、コンテナであればイメージを更新して再デプロイ）。
  7. 修正版が提供されていない場合はベンダの回避策を適用し、それも無い場合は修正版が提供されるまで公開インターフェースから切り離します。
  関連用語

  • CVE - 世の中に見つかったソフトウェアの欠陥それぞれに振られる、共通の識別番号。
  • バナー - サーバーが接続してきた相手に返す、自分が使っているソフトウェアの名前や版数を含む応答。
  • バックポート - 配布元が、修正だけを古い版に取り込むこと。版数は上がらないため、外からは修正済みか未適用かを見分けられない。
  根拠データを表示 (0 件)

  この項目は根拠 ID を持っていません。

• 証明書有効期間の短縮（47 日運用への対応）

  検査エンジン原文（英語）

  certificate lifetime 90 days

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  有効期間 1 年の証明書は、秘密鍵が漏えいした場合にその鍵が 1 年間使われ続ける可能性を意味します。失効（CRL/OCSP）は実運用では十分に機能せず、有効期間の短さが実質的に唯一の歯止めとなります。加えて CA/Browser Forum は有効期間の上限を段階的に 47 日まで短縮する方針であり、手作業による更新は近い将来、運用が困難になります。

  対応手順

  1. 有効期間を手動で短縮するのではなく、ACME による自動発行を導入し、有効期間を運用負荷から切り離します。
  2. certbot の systemd タイマ、acme.sh の cron、または CDN／ロードバランサのマネージド証明書を利用します。
  3. 反映は --deploy-hook "systemctl reload nginx" のようにフックで行い、certbot renew --dry-run で無人更新の経路が機能することを確認します。
  4. 確認は、次に発行された証明書について openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates の notBefore と notAfter の差が 90 日以内であることで行います（自動化できていれば、将来の 47 日運用にもそのまま対応できます）。
  関連用語

  • 秘密鍵 - 持ち主だけが知っていることを前提に、暗号化や身元証明に使われる値。外部に漏れると持ち主になりすませてしまう。
  • 失効 - 発行済みの証明書を、期限が来る前に無効だと宣言すること。受け取った側がその宣言を毎回確かめてくれるとは限らない。
  • ACME チャレンジ - 証明書を自動発行する際に、そのドメインを本当に管理しているかを確認するための応答のやり取り。
  根拠データを表示 (1 件)

  • CT ログ（crt.sh + Cert Spotter）対象 example.com取得 2026/09/01 09:00 JST

    証明書

    1

    example.com, www.example.com

    C=US, O=Let's Encrypt, CN=R11 · 2099-01-01 → 2099-04-01

    根拠 ID crtsh:crtsh.certs:example.com

• 耐量子暗号によるハイブリッド鍵交換への対応

  検査エンジン原文（英語）

  hybrid post-quantum key exchange accepted

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  現在記録された通信は、量子計算機が楕円曲線の鍵交換を解読できるようになった時点でまとめて復号される恐れがあります（いわゆる harvest now, decrypt later）。ハイブリッド鍵交換（X25519MLKEM768）を有効にすれば、現在の安全性を損なわずに、通信を記録しておく価値を失わせることができます。

  対応手順

  1. ハイブリッド群を提供できる TLS スタックが必要です。
  2. OpenSSL 3.5 以降や近年の BoringSSL は X25519MLKEM768 を既定で提供します。
  3. nginx はそのスタックに対してビルドしたうえで ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1; を指定します。
  4. 古い OpenSSL のままでは未知の曲線として起動に失敗するため、事前に openssl version で対応状況を確認してください。
  5. CDN では既定で有効か、ゾーン設定の項目になっている場合が多いです。
  6. 確認は openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null がハンドシェイクに成功し、Negotiated TLS1.3 group: X25519MLKEM768 と表示されることで行います。
  関連用語

  • 耐量子暗号 - 将来の量子計算機でも解読されないように設計された暗号の方式。
  • ハイブリッド鍵交換 - 今使われている方式と将来を見据えた新しい方式を両方同時に使い、どちらかが破られてももう一方が守る鍵の決め方。
  • 先に集めて後で解く攻撃 - 今は解読できない通信をそのまま保存しておき、将来解読できる技術が揃った時点でまとめて開く攻撃のやり方。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• 有効な ROA による経路 origin の保護

  検査エンジン原文（英語）

  all prefixes RPKI valid

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  ROA が無い場合、BGP を運用する第三者が当該アドレス空間を自らのものとして広告し、通信を引き込むことができます。引き込んだ先で ACME の HTTP 検証に応答すれば、正規の証明書まで取得されます。RPKI invalid な経路を破棄する ISP が増えているため、ROA があればその広告は多くの経路で拒否されます。

  対応手順

  1. これはサーバ上の設定ではなく、IP アドレスの保有者が RIR 側で行う作業です。
  2. 自社でプレフィックスを保有している場合は、RIR のポータル（JPNIC / APNIC / RIPE NCC / ARIN）で各プレフィックスと origin AS の ROA を作成します。
  3. maxLength は実際に広告している長さより長くしないでください。
  4. 長く設定すると、より細かいプレフィックスでの乗っ取りを自ら許可することになります。
  5. アドレスがホスティングやクラウド事業者の保有である場合は、該当プレフィックスの ROA を公開するよう事業者に依頼することが本項目の作業となります。
  6. 確認は RIPEstat や bgp.he.net で当該広告が RPKI valid と表示されることで行います（反映まで 1 時間程度を要します）。
  関連用語

  • RPKI - あるアドレス範囲への経路を、どの組織が広告してよいかをデジタル署名付きで登録しておく仕組み。
  • ROA - あるアドレス範囲への経路を広告してよい組織を宣言する、デジタル署名付きの証明書。
  • BGP - インターネット上の各組織が、自分の持つアドレス範囲への経路を互いに知らせ合うための仕組み。
  • AS 番号 - インターネット上で経路をやり取りする単位となる、組織ごとに割り当てられた番号。
  • IP プレフィックス - 連続したアドレスをまとめて表す、アドレス範囲の書き方。
  • ACME チャレンジ - 証明書を自動発行する際に、そのドメインを本当に管理しているかを確認するための応答のやり取り。
  根拠データを表示 (1 件)

  • RIPEstat（RPKI）対象 192.0.2.1取得 2026/09/01 09:00 JST

    Prefix

    192.0.2.0/24

    ASN

    AS64500

    RPKI の状態

    valid

    根拠 ID rpki:rpki.prefix:192.0.2.1

• スクリプトへの資格情報の不記載

  検査エンジン原文（英語）

  no credential recognised in the 1 scripts read

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  ブラウザへ配信するスクリプトは、閲覧した誰もが全文を読めます。そこに API キーや秘密鍵が含まれていれば、公開したのと同じです。難読化しても、圧縮しても、読めることは変わりません。取り除いた時点で無効になるのではなく、読まれた時点で渡っています。

  対応手順

  1. まず資格情報を再発行し、古いものを無効化してください。
  2. ファイルからの削除は次の手順です。
  3. 順序を逆にすると、削除から再発行までの間、有効な資格情報が出回ったままになります。
  4. そのうえで、サーバ側でしか使わない値をクライアントの成果物へ混ぜない構成に変えます。
  5. ビルド時の環境変数を全て埋め込む設定が原因であることが多いため、公開してよい値だけを明示的に列挙する方式にしてください。
  関連用語

  • 秘密鍵 - 持ち主だけが知っていることを前提に、暗号化や身元証明に使われる値。外部に漏れると持ち主になりすませてしまう。
  • XSS - 本来のページには無いはずのスクリプトを第三者が紛れ込ませ、利用者のブラウザ上で動かしてしまう攻撃。
  根拠データを表示 (1 件)

  • http対象 example.com取得 2026/09/01 09:00 JST

    fetched

    https://example.com/app.js

    observed

    true

    根拠 ID http:http.scripts:example.com

• robots.txt での機微パスの不記載

  検査エンジン原文（英語）

  robots.txt names no sensitive-looking path

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  `robots.txt` は誰でも読めるファイルです。ここに `Disallow: /admin/` と書くことは、検索結果に出さないための指示であって、アクセスを防ぐものではありません。むしろ、管理画面の場所を明示的に伝えることになります。攻撃者が最初に読むファイルの 1 つです。

  対応手順

  1. 管理用のパスを robots.txt から削除します。
  2. 検索結果に出したくない場合は、該当ページの応答に X-Robots-Tag: noindex を付けるか、<meta name="robots" content="noindex"> を置きます。
  3. これらはページを取得した検索エンジンにだけ伝わり、一覧としては公開されません。
  4. そのうえで、当該パスに認証を掛けるか、接続元を限定してください。
  5. 隠すことは対策では無く、アクセスを制御することが対策です。
  根拠データを表示 (1 件)

  • http対象 example.com取得 2026/09/01 09:00 JST

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    根拠 ID http:http.probes:example.com

• security.txt の公開

  検査エンジン原文（英語）

  security.txt found

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  連絡先が公開されていない場合、脆弱性を発見した第三者は宛先を推測するほかなく、報告は届かないまま放置されるか、脆弱性がそのまま公表されます。連絡先が 1 つあるだけで、第三者より先に自社が把握できます。

  対応手順

  1. https://example.com/.well-known/security.txt に RFC 9116 形式のテキストファイルを配置します。
  2. 最低限 Contact: mailto:security@example.com と Expires:（1 年以内の RFC 3339 形式の日時）が必要です。
  3. 加えて Preferred-Languages: ja, en、方針があれば Policy: を記載します。
  4. HTTPS で Content-Type: text/plain; charset=utf-8 として応答してください。
  5. Expires を過ぎると無効扱いとなるため、更新を予定に組み込みます。
  6. 加えて、そのメールボックスを実際に確認する担当者を定めてください。
  7. 確認は curl -sI https://example.com/.well-known/security.txt が 200 と text/plain を返すことで行います。
  関連用語

  • security.txt - 脆弱性を見つけた人がどこに連絡すればよいかを、決まった場所に置いた平文ファイルで公開しておく仕組み。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    security.txt

    あり

    根拠 ID http:http.security_txt:example.com

• 本番ソースマップの統制

  検査エンジン原文（英語）

  the page advertises no source map

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  ソースマップは、圧縮されたスクリプトを元のコードに対応付けるための情報です。`sourcesContent` を含む形で公開すると、圧縮前のコードそのものが読めます。変数名、コメント、未公開の機能、内部の API の呼び出し方まで、開発時の内容がそのまま外部に渡ります。

  対応手順

  1. 本番の生成物にソースマップを含めないか、sourcesContent を除いた形で出力します。
  2. webpack は devtool: false、Vite は build.sourcemap: false です。
  3. 障害調査のために残す場合は、マップだけを公開範囲外に置き（.map へのアクセスを Web サーバで拒否する）、必要なときに手元で対応付けます。
  4. 確認は、公開しているスクリプト末尾の sourceMappingURL が指す URL を開き、404 が返ることです。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• DMARC の全通適用

  検査エンジン原文（英語）

  DMARC pct absent, so the policy applies to all mail

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  `pct` は、DMARC の方針を適用するメールの割合を指定します。`pct=20` であれば、なりすましメールの 8 割は方針の対象外となり、`p=reject` を設定していても受信箱まで届きます。段階導入の途中であれば妥当な設定ですが、そのまま残っている場合、レポート上の見かけほど守られていません。

  対応手順

  1. DMARC の集計レポートで、正規送信元がすべて DKIM または SPF で整合していることを確認します。
  2. そのうえで _dmarc の TXT レコードから pct を削除するか、pct=100 に変更します（pct を省略した場合の既定値が 100 です）。
  3. 確認は dig +short TXT _dmarc.example.com の出力に pct が無いか pct=100 であること、および次のレポートで正規送信元の拒否が増えていないことで行います。
  関連用語

  • DMARC - 送信元の確認に失敗したメールを受信側がどう扱うか(そのまま届ける・迷惑メール扱いにする・拒否する)を指示する仕組み。
  • 集計レポート - 誰がそのドメインを名乗ってメールを送っているかを、送信を受け取った側がまとめて送り返してくる定期報告。
  • アライメント - 差出人として表示されるドメインと、実際に送信を確認できたドメインが一致していること。
  • SPF - そのドメインの差出人を名乗ってよいサーバーの一覧を、DNS に公開する仕組み。
  • DKIM - 送信するメールにデジタル署名を付け、途中で書き換えられていないことと送信元を受信側が確かめられるようにする仕組み。
  根拠データを表示 (2 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

• DMARC レコードの公開

  検査エンジン原文（英語）

  DMARC present

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  SPF と DKIM だけでは、それらに失敗したメールの取り扱いを受信側に指示できず、送信の実態も把握できません。DMARC が無いドメインは、なりすましの請求書やパスワード再設定メールが送られていても、その事実を検知する手段がありません。

  対応手順

  1. まず監視モードで _dmarc.example.com に TXT レコードを公開します: v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1。
  2. DNS ゾーンではホスト名を _dmarc として TXT レコードを追加します。
  3. 数日後に集計レポートが届き始めたら、その内容から正規の送信元を特定したうえでポリシーを引き上げます（mail.dmarc.policy を参照）。
  4. 確認は dig +short TXT _dmarc.example.com がこのレコードを返すことで行います。
  関連用語

  • DMARC - 送信元の確認に失敗したメールを受信側がどう扱うか(そのまま届ける・迷惑メール扱いにする・拒否する)を指示する仕組み。
  • SPF - そのドメインの差出人を名乗ってよいサーバーの一覧を、DNS に公開する仕組み。
  • DKIM - 送信するメールにデジタル署名を付け、途中で書き換えられていないことと送信元を受信側が確かめられるようにする仕組み。
  • 集計レポート - 誰がそのドメインを名乗ってメールを送っているかを、送信を受け取った側がまとめて送り返してくる定期報告。
  • TXT レコード - ドメイン名に自由な文字列をひも付けて公開できる DNS の記録の型。設定の宣言によく使われる。
  根拠データを表示 (2 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

• DMARC 集計レポート送付先（rua）の設定

  検査エンジン原文（英語）

  DMARC rua present

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  `rua` が無い場合、集計レポートは 1 通も届きません。誰が当該ドメインを名乗って送信しているのか、それがなりすましなのか、見落としていた正規の送信元なのかを判別できず、ポリシーを安全に強化する根拠が得られません。

  対応手順

  1. _dmarc.example.com の TXT レコードに rua=mailto:dmarc@example.com を追加します（既存の v= と p= はそのまま維持）。
  2. 例: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; fo=1。
  3. 受信先を別ドメインにする場合は、その別ドメイン側に example.com._report._dmarc.<別ドメイン> の TXT レコードで v=DMARC1 を公開しないと受信できません。
  4. レポートは gzip 圧縮された XML であるため、目視で確認する場合はパーサまたは SaaS に取り込みます。
  5. 確認は dig +short TXT _dmarc.example.com に rua= が含まれること、および 1〜2 日以内に実際にレポートが届くことで行います。
  関連用語

  • DMARC - 送信元の確認に失敗したメールを受信側がどう扱うか(そのまま届ける・迷惑メール扱いにする・拒否する)を指示する仕組み。
  • 集計レポート - 誰がそのドメインを名乗ってメールを送っているかを、送信を受け取った側がまとめて送り返してくる定期報告。
  • TXT レコード - ドメイン名に自由な文字列をひも付けて公開できる DNS の記録の型。設定の宣言によく使われる。
  根拠データを表示 (2 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

• サブドメインへの DMARC 方針の適用

  検査エンジン原文（英語）

  DMARC enforces on subdomains (subdomains inherit p=quarantine)

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  攻撃者は apex を騙る必要がありません。`billing.example.com` のような、実在しないサブドメインを差出人にすれば、受信者の目には同じ組織のメールとして映ります。`sp` を明示せず `p` も緩い場合、この経路には対策が及びません。

  対応手順

  1. _dmarc の TXT レコードに sp=reject を追加します。
  2. メールを送信しないサブドメインしか無い場合はこれで問題ありません。
  3. 送信しているサブドメインがある場合は、DMARC の集計レポートでそれらが DKIM または SPF で整合していることを先に確認し、そのうえで適用してください。
  4. 確認は dig +short TXT _dmarc.example.com に sp=reject が含まれること、および実在しないサブドメインからの試験送信が拒否されることで行います。
  関連用語

  • DMARC - 送信元の確認に失敗したメールを受信側がどう扱うか(そのまま届ける・迷惑メール扱いにする・拒否する)を指示する仕組み。
  • アライメント - 差出人として表示されるドメインと、実際に送信を確認できたドメインが一致していること。
  • 集計レポート - 誰がそのドメインを名乗ってメールを送っているかを、送信を受け取った側がまとめて送り返してくる定期報告。
  • フィッシング - 実在する相手を装った連絡で、パスワードなどを利用者自身に入力させて盗み取る詐欺の手口。
  • apex ドメイン - www などを付けない、そのドメインそのものの名前。
  根拠データを表示 (2 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

• DNS における MTA-STS の宣言

  検査エンジン原文（英語）

  MTA-STS declared

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  SMTP は STARTTLS が無い相手や証明書を検証できない相手にも平文で配送を続けるため、経路上の攻撃者は暗号化を除去してメールを読み書きできます。MTA-STS は暗号化の引き下げを送信側に拒否させる宣言ですが、DNS レコードが無ければ送信側はポリシーを取得しに来ません。

  対応手順

  1. _mta-sts.example.com に TXT レコードを公開します: v=STSv1; id=20260905000000。
  2. id は任意の版番号で、ポリシーを変更した際には必ず更新します（更新しないと送信側はキャッシュを使い続けます）。
  3. これだけでは不十分で、https://mta-sts.example.com/.well-known/mta-sts.txt のポリシーファイルも必要です（mail.mtasts.policy を参照）。
  4. 確認は dig +short TXT _mta-sts.example.com で行います。
  関連用語

  • MTA-STS - メールを配送する側に、暗号化できない接続なら配送をやめるよう指示しておく仕組み。
  • STARTTLS - 平文で始めたメールのやり取りの途中から、暗号化した通信に切り替える仕組み。切り替えの合図自体は平文で流れるため、途中の誰かに消されうる。
  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  • TXT レコード - ドメイン名に自由な文字列をひも付けて公開できる DNS の記録の型。設定の宣言によく使われる。
  根拠データを表示 (2 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

• MX の逆引きの整合

  検査エンジン原文（英語）

  every MX host has forward-confirmed reverse DNS

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  多くの受信側は、送信元 IP アドレスの逆引きが正引きで同じアドレスに戻るかを見て、正規のメールサーバかどうかを判断します。整合していない送信元は、迷惑メール扱いになるか、接続の時点で拒否されます。SPF や DKIM が整っていても、この段階で落ちます。

  対応手順

  1. 逆引きの登録は IP アドレスの割り当て元、つまりクラウド事業者や ISP が行います。
  2. 管理画面に逆引き設定の項目があればそこで、無ければ申請してください。
  3. 登録する名前は MX のホスト名と同じにし、その名前が同じ IP アドレスに解決することを併せて確認します。
  4. 確認は dig +short -x <IP> で名前が返り、dig +short <その名前> で元の IP に戻ることです。
  関連用語

  • 権威 DNS サーバー - そのドメインについての正式な答えを持ち、他のサーバーからの問い合わせに答える役目のサーバー。
  根拠データを表示 (2 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

• 受信時の STARTTLS の提供

  検査エンジン原文（英語）

  all 1 mail exchangers offer STARTTLS

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  STARTTLS を提供していない MX 宛のメールは、平文のまま経路を通ります。件名も本文も添付も、途中の中継点で読めます。取引先が送った請求書も、パスワード再設定の通知も同じです。送信側は暗号化を要求できず、平文で送るか送らないかしか選べません。

  対応手順

  1. Postfix は main.cf に smtpd_tls_security_level = may と smtpd_tls_cert_file / smtpd_tls_key_file を設定します。
  2. Exim は tls_certificate と tls_privatekey を設定します。
  3. 証明書は MX のホスト名で取得してください。
  4. 外部のメールサービスを使っている場合は既定で有効です。
  5. 確認は openssl s_client -starttls smtp -connect mail.example.com:25 が握手を完了することです。
  関連用語

  • STARTTLS - 平文で始めたメールのやり取りの途中から、暗号化した通信に切り替える仕組み。切り替えの合図自体は平文で流れるため、途中の誰かに消されうる。
  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  • MTA-STS - メールを配送する側に、暗号化できない接続なら配送をやめるよう指示しておく仕組み。
  根拠データを表示 (3 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

  • smtp対象 example.com取得 2026/09/01 09:00 JST

    根拠 ID smtp:smtp.mx:example.com

• 受信時の証明書の妥当性

  検査エンジン原文（英語）

  all 1 exchangers present a valid certificate

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  STARTTLS を提供していても、証明書の名前が合わない、期限が切れている、信頼された認証局に届かない場合、送信側は相手が本物かどうかを確かめられません。多くの送信側はそれでも配送します。暗号化はされますが、経路上の攻撃者が割り込んでも気づけない状態であり、暗号化の効果は大きく損なわれます。

  対応手順

  1. MX のホスト名（dig +short MX example.com が返す名前）で証明書を取得し、SMTP のサービスに設定します。
  2. Web と同じ証明書を流用する場合は、SAN に MX のホスト名が含まれている必要があります。
  3. 中間証明書の連結も忘れずに行ってください。
  4. MTA-STS を enforce で運用している場合、この不備は配送の失敗そのものになります。
  5. 確認は openssl s_client -starttls smtp -connect mail.example.com:25 の Verify return code が 0 であることです。
  関連用語

  • STARTTLS - 平文で始めたメールのやり取りの途中から、暗号化した通信に切り替える仕組み。切り替えの合図自体は平文で流れるため、途中の誰かに消されうる。
  • 認証局 - サーバーの身元を確認したうえで証明書を発行する会社。
  • MTA-STS - メールを配送する側に、暗号化できない接続なら配送をやめるよう指示しておく仕組み。
  • DANE - 署名付きの DNS の記録を使って、メールの配送先が本物の鍵を提示しているかどうかを送信側に確かめさせる仕組み。
  根拠データを表示 (3 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

  • smtp対象 example.com取得 2026/09/01 09:00 JST

    根拠 ID smtp:smtp.mx:example.com

• SPF の参照回数

  検査エンジン原文（英語）

  SPF costs 1 of the 10 permitted DNS lookups

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  受信側が SPF を評価する際に行う DNS 参照は 10 回までと定められています（RFC 7208 第 4.6.4 節）。超えた時点で評価は打ち切られ、記載内容にかかわらず SPF は機能しません。送信サービスを追加するたびに include が増えるため、気づかないうちに超えている例が多くあります。

  対応手順

  1. 使っていない include を削除します。
  2. 残ったもののうち、送信元 IP が固定の事業者については、include を ip4: の直接記載に置き換えると 1 回分が消えます。
  3. それでも収まらない場合は、送信するサブドメインを分け（mail.example.com など）、apex の SPF を軽くします。
  4. 参照回数は公開の検証ツールで数えられます。
  5. 整理後、DMARC の集計レポートで正規送信元が pass のままであることを確認してください。
  関連用語

  • SPF - そのドメインの差出人を名乗ってよいサーバーの一覧を、DNS に公開する仕組み。
  • 集計レポート - 誰がそのドメインを名乗ってメールを送っているかを、送信を受け取った側がまとめて送り返してくる定期報告。
  根拠データを表示 (2 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

• SPF の ptr 機構の不使用

  検査エンジン原文（英語）

  SPF uses no ptr mechanism

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  ptr 機構は、受信側に送信元 IP の逆引きと、その結果に対する正引きを要求します。RFC 7208 第 5.5 節は、負荷の大きさと結果の不確かさを理由に、受信側には ptr を使わないよう、公開側には ptr を書かないよう求めています。逆引きを引けない受信側では該当の機構が無視されるため、正規の送信元が拒否される場合があります。

  対応手順

  1. ptr で表現していた送信元を、実際の IP アドレスまたはサービス提供元の include に置き換えます。
  2. 自社サーバであれば ip4:203.0.113.10 のように直接記載し、外部サービスであれば提供元が案内する include: を使います。
  3. 置換後、dig +short TXT example.com | grep spf1 の出力に ptr が含まれないこと、および DMARC の集計レポートで正規送信元の SPF が pass のままであることを確認してください。
  関連用語

  • SPF - そのドメインの差出人を名乗ってよいサーバーの一覧を、DNS に公開する仕組み。
  • 集計レポート - 誰がそのドメインを名乗ってメールを送っているかを、送信を受け取った側がまとめて送り返してくる定期報告。
  根拠データを表示 (2 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

• SPF レコードの公開

  検査エンジン原文（英語）

  SPF present

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  SPF が無い場合、受信側には「当該ドメインを名乗るメールが正規の送信基盤から送出されたものか」を判定する材料がありません。第三者が請求書・パスワード再設定・振込先変更のメールを当該ドメイン名で送信でき、それが通常どおり受信箱に届きます。

  対応手順

  1. apex に TXT レコードを 1 本のみ公開し、当該ドメインで送信するすべてのシステムを列挙したうえで-all などの制限的な指定で閉じます。
  2. 例: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all。
  3. SPF レコードは 1 ドメインにつき 1 本のみとし（2 本あると permerror となります）、include: / a / mx による DNS 参照の合計を 10 回以内に収めます。
  4. 確認は dig +short TXT example.com | grep spf1 が 1 本のみ返ること、および外部の受信側へテスト送信して Authentication-Results に spf=pass が表示されることで行います。
  関連用語

  • SPF - そのドメインの差出人を名乗ってよいサーバーの一覧を、DNS に公開する仕組み。
  • TXT レコード - ドメイン名に自由な文字列をひも付けて公開できる DNS の記録の型。設定の宣言によく使われる。
  根拠データを表示 (2 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

• SPF レコードの単一性

  検査エンジン原文（英語）

  exactly one SPF record

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  SPF レコードが 2 件以上ある場合、受信側はどちらかを選ぶのではなく、SPF の評価そのものを打ち切ります（RFC 7208 第 3.2 節の permerror）。個々の内容が正しくても、なりすまし対策としては機能していない状態です。原因の多くは、業務システムの追加時に既存レコードへ追記せず、新しい TXT レコードを足してしまうことにあります。

  対応手順

  1. dig +short TXT example.com | grep spf1 で現在公開している SPF レコードをすべて取得します。
  2. 各レコードの include: ip4: ip6: a mx を重複を除いて 1 行にまとめ、末尾の all 機構は最も厳しいものを採用します。
  3. 統合した 1 件を公開し、残りの TXT レコードを削除します。
  4. 削除後、同じ dig の出力が 1 行のみになること、および DMARC の集計レポートで正規送信元の SPF が pass に戻ることを確認してください。
  関連用語

  • SPF - そのドメインの差出人を名乗ってよいサーバーの一覧を、DNS に公開する仕組み。
  • TXT レコード - ドメイン名に自由な文字列をひも付けて公開できる DNS の記録の型。設定の宣言によく使われる。
  • 集計レポート - 誰がそのドメインを名乗ってメールを送っているかを、送信を受け取った側がまとめて送り返してくる定期報告。
  根拠データを表示 (2 件)

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    A

    192.0.2.1

    NS

    ns1.example.net・ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    根拠 ID dns:dns.host:example.com

  • DNS 応答対象 example.com取得 2026/09/01 09:00 JST

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    根拠 ID dns:dns.mail:example.com

• ドメインの評価情報

  検査エンジン原文（英語）

  the domain is on none of the 1 lists asked

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  ドメイン名そのものが掲載されると、そのドメインを差出人とするメールも、本文中にその URL を含むメールも拒否されます。IP アドレスの掲載と違い、送信元を変えても回避できません。掲載の原因は、乗っ取られたサイトからの誘導や、なりすましメールの大量送信であることが多く、こちらが被害者である場合も掲載自体は行われます。

  対応手順

  1. まずサイトが改ざんされていないか、意図しない転送や誘導が仕込まれていないかを確認します。
  2. なりすましが原因の場合は、SPF・DKIM・DMARC を厳格化し、p=reject まで進めてください。
  3. 原因を除いたうえで、掲載元の解除手続きに従います。
  4. 確認は dig +short example.com.dbl.spamhaus.org が何も返さないことです。
  関連用語

  • DMARC - 送信元の確認に失敗したメールを受信側がどう扱うか(そのまま届ける・迷惑メール扱いにする・拒否する)を指示する仕組み。
  • フィッシング - 実在する相手を装った連絡で、パスワードなどを利用者自身に入力させて盗み取る詐欺の手口。
  • サブドメイン乗っ取り - 使われなくなった外部サービスへの案内が残ったままのサブドメインを、第三者が代わりに登録して乗っ取ること。
  根拠データを表示 (1 件)

  • dns-rep対象 example.com取得 2026/09/01 09:00 JST

    ip_lists_asked

    zen.spamhaus.org

    domain_lists_asked

    dbl.spamhaus.org

    根拠 ID dns-rep:dns.reputation:example.com

• IP アドレスの評価情報

  検査エンジン原文（英語）

  no address is listed on any of the 1 lists asked

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  IP アドレスが評価情報の配布元に掲載されると、そのアドレスから送ったメールは相手に届かなくなります。多くの受信側が同じ一覧を参照しているため、影響は特定の相手に留まりません。掲載の原因は、踏み台にされた社内の端末、設定を誤った転送、解約後も残っていた仮想サーバなど、こちらの側にあることがほとんどです。

  対応手順

  1. 解除申請の前に原因を取り除いてください。
  2. 原因が残ったままの解除は短期間で再掲載され、繰り返すと解除自体が受け付けられなくなります。
  3. まず該当アドレスからの送信内容を確認し、認証を経ない中継や、感染した端末の有無を調べます。
  4. そのうえで、掲載元それぞれの解除手続き（Spamhaus は https://check.spamhaus.org/）に従ってください。
  5. 確認は、同じ照会が掲載無しを返すことです。
  関連用語

  • SPF - そのドメインの差出人を名乗ってよいサーバーの一覧を、DNS に公開する仕組み。
  • DKIM - 送信するメールにデジタル署名を付け、途中で書き換えられていないことと送信元を受信側が確かめられるようにする仕組み。
  • DMARC - 送信元の確認に失敗したメールを受信側がどう扱うか(そのまま届ける・迷惑メール扱いにする・拒否する)を指示する仕組み。
  根拠データを表示 (1 件)

  • dns-rep対象 example.com取得 2026/09/01 09:00 JST

    ip_lists_asked

    zen.spamhaus.org

    domain_lists_asked

    dbl.spamhaus.org

    根拠 ID dns-rep:dns.reputation:example.com

• 外部依存先の健全性

  検査エンジン原文（英語）

  all 1 external dependencies answer with a valid certificate

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  ページが読み込んでいる外部の資源が取得できない場合、そのスクリプトに依存する機能は動きません。証明書が検証できない場合、ブラウザは読み込み自体を拒否します。提供元の廃止や移転は予告なく起こり、こちらの手元では気づけません。古い依存先のドメインが失効し、別人に取得された事例もあります。

  対応手順

  1. 応答しない依存先は、現行の提供元へ交換するか、自サイトに取り込んで配信します。
  2. 取り込む場合は更新の手順を決めてください。
  3. 残す場合も、integrity 属性（web.sri）を付けておくと、提供元が入れ替わった際に実行を止められます。
  4. ページの読み込み時に失敗している要求が無いことを、ブラウザの開発者ツールのネットワークタブで定期的に確認してください。
  関連用語

  • CDN - 世界各地に置いた代理のサーバーを使って、利用者に近い場所からコンテンツを届ける事業者の仕組み。
  • サブドメイン乗っ取り - 使われなくなった外部サービスへの案内が残ったままのサブドメインを、第三者が代わりに登録して乗っ取ること。
  根拠データを表示 (1 件)

  • http対象 example.com取得 2026/09/01 09:00 JST

    observed

    true

    根拠 ID http:http.cdn:example.com

• JavaScript ライブラリの版数

  検査エンジン原文（英語）

  the 1 recognised library versions are all at or above their advisory floor

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  古い版の JavaScript ライブラリには、公開済みの脆弱性が残っていることがあります。jQuery の古い版に含まれる問題のように、利用者の入力を扱う箇所でスクリプトの注入を許すものが典型です。ページを開いた利用者のブラウザ上で、こちらのサイトの権限で動作します。

  対応手順

  1. 該当するライブラリを更新します。
  2. CDN から読み込んでいる場合は URL の版数部分を変更し、integrity 属性も併せて入れ替えてください（web.sri）。
  3. 自前で配信している場合は、パッケージ管理の側で更新し、成果物を作り直します。
  4. 判定が「未確定」と出ている場合、版数はファイル名から読み取ったものです。
  5. 中身が入れ替わっている可能性があるため、実際に配信している内容の版数を確認してください。
  関連用語

  • CVE - 世の中に見つかったソフトウェアの欠陥それぞれに振られる、共通の識別番号。
  • XSS - 本来のページには無いはずのスクリプトを第三者が紛れ込ませ、利用者のブラウザ上で動かしてしまう攻撃。
  • バックポート - 配布元が、修正だけを古い版に取り込むこと。版数は上がらないため、外からは修正済みか未適用かを見分けられない。
  根拠データを表示 (1 件)

  • http対象 example.com取得 2026/09/01 09:00 JST

    fetched

    https://example.com/app.js

    observed

    true

    根拠 ID http:http.scripts:example.com

• 外部スクリプトの把握

  検査エンジン原文（英語）

  the page runs script from 1 external hosts: [cdn.example.net]

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  外部から読み込むスクリプトは、いずれもこちらのページで、こちらのサイトの権限で動きます。フォームの入力値を読むことも、表示を書き換えることもできます。広告や解析のタグは担当部署が個別に追加していることが多く、全体の一覧を誰も持っていない状態になりがちです。

  対応手順

  1. 本項目は観測値の報告であり、減点しません。
  2. 一覧を確認し、用途の分からないもの、契約の切れた提供元、重複している解析タグを外してください。
  3. 残すものには integrity 属性（web.sri）を付け、Content-Security-Policy の script-src を一覧に限定すると、意図しない追加が起きた時点で止まります。
  関連用語

  • CSP - ページの中で実行してよいスクリプトや読み込んでよい外部の場所を、あらかじめ限定しておく仕組み。
  • XSS - 本来のページには無いはずのスクリプトを第三者が紛れ込ませ、利用者のブラウザ上で動かしてしまう攻撃。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• 外部資源の安全な取得

  検査エンジン原文（英語）

  all 1 external resources are fetched over HTTPS

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  外部から読み込む資源を平文で取得すると、経路上の誰でも内容を差し替えられます。差し替えられるのはこちらのページで動くコードであり、利用者から見れば当社のサイトが行った処理です。提供元の信頼性以前の問題として、取得経路を保護する必要があります。

  対応手順

  1. 外部参照の URL をすべて https:// にします。
  2. 提供元が HTTPS を提供していない場合、その依存自体を見直してください。
  3. 2026 年時点で HTTPS を提供していない配信元は、更新も保守もされていない可能性が高いものです。
  4. 確認は、ページの読み込み時に平文の外部要求が発生しないことを開発者ツールのネットワークタブで見ることです。
  関連用語

  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• 脆弱な暗号スイートの拒否

  検査エンジン原文（英語）

  no weak cipher suites

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  本項目で検出対象とするのは RC4・3DES・輸出グレード、および前方秘匿性の無いスイートで、いずれも既知の攻撃により解読またはダウングレードが可能です。経路上の攻撃者はセッションの内容を復元でき、前方秘匿性が無い場合は、後日サーバ鍵が漏えいした時点で記録済みの通信もまとめて復号されます。

  対応手順

  1. 優先順位の入れ替えではなく、許可する一覧そのものを限定します。
  2. nginx であれば ssl_protocols TLSv1.2 TLSv1.3; に加えて ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; と ssl_prefer_server_ciphers off; を設定します。
  3. Apache であれば同じ一覧を SSLCipherSuite に設定し、SSLHonorCipherOrder off とします。
  4. nginx -t で構文を検証してからリロードします。
  5. 確認は nmap --script ssl-enum-ciphers -p 443 example.com（または testssl.sh example.com）で上記以外のスイートが表示されないことで行います。
  関連用語

  • 暗号スイート - 暗号化した通信を始めるときに使う、暗号方式の組み合わせ。
  • 前方秘匿性 - 通信のたびに鍵を使い捨てにすることで、後日サーバーの鍵が漏れても過去に記録された通信までは読まれないようにする性質。
  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• 前方秘匿性のある鍵交換

  検査エンジン原文（英語）

  the negotiated suite has forward secrecy

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  前方秘匿性の無い鍵交換では、通信の内容がサーバの秘密鍵だけで復号できます。攻撃者が今日の通信を記録しておき、数年後に鍵を入手した時点で、記録したすべてを読めることになります。ECDHE は接続ごとに使い捨ての鍵を作るため、後から鍵が漏れても過去の通信は開けません。

  対応手順

  1. ECDHE を使うスイートだけを許可します。
  2. nginx は ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; と ssl_prefer_server_ciphers on; を設定します。
  3. Apache は SSLCipherSuite に同じ一覧を、SSLHonorCipherOrder on と併せて設定します。
  4. TLS 1.3 は仕様上すべてのスイートが前方秘匿性を持つため、1.3 を有効にすること自体が対策になります。
  5. 確認は openssl s_client -connect example.com:443 </dev/null 2>/dev/null | grep -i cipher で ECDHE または TLS 1.3 のスイートが出ることです。
  関連用語

  • 前方秘匿性 - 通信のたびに鍵を使い捨てにすることで、後日サーバーの鍵が漏れても過去に記録された通信までは読まれないようにする性質。
  • 暗号スイート - 暗号化した通信を始めるときに使う、暗号方式の組み合わせ。
  • 先に集めて後で解く攻撃 - 今は解読できない通信をそのまま保存しておき、将来解読できる技術が揃った時点でまとめて開く攻撃のやり方。
  • 秘密鍵 - 持ち主だけが知っていることを前提に、暗号化や身元証明に使われる値。外部に漏れると持ち主になりすませてしまう。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• TLS 圧縮の不使用

  検査エンジン原文（英語）

  the server selects no compression even when it is offered

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  TLS の圧縮を有効にしていると、暗号化された通信の長さから中身を推測できます。CRIME と呼ばれる手法で、攻撃者が同じ接続に既知の文字列を混ぜながら長さの変化を観察すると、Cookie の値を 1 文字ずつ復元できます。暗号そのものは破られておらず、圧縮によって長さが情報を持ってしまうことが原因です。

  対応手順

  1. TLS 圧縮を無効にします。
  2. OpenSSL 1.1.0 以降は既定で無効であり、TLS 1.3 は仕様から削除しています。
  3. 有効になっている場合は、openssl.cnf の Options に NoCompression を追加するか、サーバソフトウェアの設定で明示的に無効にしてください。
  4. 同時に TLS 1.2 以降のみを許可すれば、この問題は構造的に消えます。
  5. 確認は openssl s_client -connect example.com:443 </dev/null 2>/dev/null | grep Compression が NONE を返すことです。
  関連用語

  • 暗号スイート - 暗号化した通信を始めるときに使う、暗号方式の組み合わせ。
  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• 旧版 TLS（1.0 / 1.1）の無効化

  検査エンジン原文（英語）

  no obsolete TLS version accepted

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  TLS 1.0 と 1.1 は暗号強度と実装上の既知の弱点により、通信内容の解読や改ざんの足掛かりとなります。主要ブラウザはすでに接続を拒否しており、有効なまま残す利点はありません。

  対応手順

  1. nginx であれば ssl_protocols TLSv1.2 TLSv1.3; に変更します（TLSv1 と TLSv1.1 を削除）。
  2. Apache であれば SSLProtocol -all +TLSv1.2 +TLSv1.3 とします。
  3. 変更後は該当ホストへ実際に TLS 1.0 でハンドシェイクを試行し、拒否されることを確認します。
  関連用語

  • TLS - 通信の内容を暗号化し、途中で盗み見や書き換えができないようにする仕組み。ウェブでは HTTPS の中で使われている。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• 安全な再ネゴシエーションへの対応

  検査エンジン原文（英語）

  the server states RFC 5746 secure renegotiation

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  再ネゴシエーションの仕組みには、当初の設計に不備がありました。攻撃者が先に接続を確立して任意のデータを送り込み、その後で利用者の接続を継ぎ足すと、利用者が送ったつもりの無い要求がサーバに届きます。RFC 5746 は、継ぎ足しの前後が同じ接続であることを確認する拡張を定めており、これを提示しないサーバは対応していないか、対応が古い版のままです。

  対応手順

  1. OpenSSL 0.9.8m 以降、または同等の対応を含む版へサーバソフトウェアを更新します。
  2. 現行のディストリビューションの標準構成であれば既に対応済みであり、提示されないということは、相当に古い版が動いているか、再ネゴシエーション自体を無効化していることを意味します。
  3. 後者であれば問題はありませんが、その場合も版数の確認をお勧めします。
  4. 確認は openssl s_client -connect example.com:443 </dev/null 2>/dev/null | grep -i renegotiation が Secure Renegotiation IS supported を返すことです。
  関連用語

  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  • TLS - 通信の内容を暗号化し、途中で盗み見や書き換えができないようにする仕組み。ウェブでは HTTPS の中で使われている。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• TLS 1.3 への対応

  検査エンジン原文（英語）

  TLS 1.3 negotiated

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  TLS 1.3 は、危殆化した暗号スイートを仕様から削除し、鍵交換に前方秘匿性を必須としています。TLS 1.2 のみの構成は、それ自体が直ちに破られるわけではありませんが、設定の誤りが安全性の低下に直結する余地を残したままです。握手の往復も 1 回少なく、接続は速くなります。

  対応手順

  1. nginx は ssl_protocols TLSv1.2 TLSv1.3; を設定します。
  2. Apache は SSLProtocol -all +TLSv1.2 +TLSv1.3 です。
  3. いずれも OpenSSL 1.1.1 以降が必要であるため、対応していない場合は先にサーバ本体を更新してください。
  4. 再読み込み後、openssl s_client -connect example.com:443 -tls1_3 </dev/null が握手に成功することを確認します。
  関連用語

  • TLS - 通信の内容を暗号化し、途中で盗み見や書き換えができないようにする仕組み。ウェブでは HTTPS の中で使われている。
  • 暗号スイート - 暗号化した通信を始めるときに使う、暗号方式の組み合わせ。
  • 前方秘匿性 - 通信のたびに鍵を使い捨てにすることで、後日サーバーの鍵が漏れても過去に記録された通信までは読まれないようにする性質。
  根拠データを表示 (1 件)

  • TLS 接続（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    対応バージョン

    TLS1.2・TLS1.3

    弱い暗号

    なし

    発行者

    C=US, O=Let's Encrypt, CN=R11

    有効期限

    2099-04-01

    検証

    あり

    根拠 ID tls:tls.probe:example.com

• Cookie の SameSite 属性

  検査エンジン原文（英語）

  every cookie states a SameSite policy

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  SameSite は、他サイトからの要求に Cookie を添えるかどうかを決めます。指定が無い場合の既定はブラウザごとに異なり、版によっても変わってきました。攻撃者が用意したページから利用者のブラウザ経由で操作を実行させる手口（CSRF）は、この属性で大部分が塞がります。

  対応手順

  1. SameSite=Lax を既定とします。
  2. 通常の遷移では送信され、他サイトからの POST では送信されません。
  3. 外部サイトに埋め込んで使う Cookie のみ SameSite=None; Secure とします。
  4. None は Secure と併記しないとブラウザに拒否されます。
  5. PHP は session.cookie_samesite = "Lax"、Express は cookie: { sameSite: 'lax' }、Rails は config.action_dispatch.cookies_same_site_protection = :lax です。
  6. 確認は curl -sI https://example.com | grep -i set-cookie で全行に SameSite が付くことです。
  関連用語

  • フィッシング - 実在する相手を装った連絡で、パスワードなどを利用者自身に入力させて盗み取る詐欺の手口。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• Cookie の Secure 属性

  検査エンジン原文（英語）

  every cookie is set with Secure

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  Secure の無い Cookie は、平文の HTTP でも送信されます。HTTPS でしか公開していないつもりでも、同じドメインの `http://` へ画像 1 枚を読みに行かせるだけで、セッション Cookie が経路上に流れます。公衆無線や社内の中継点にいる者は、それを読むだけで利用者になりすませます。

  対応手順

  1. Cookie を発行する箇所すべてに Secure を付けます。
  2. PHP は session.cookie_secure = 1（php.ini）、Express は app.use(session({ cookie: { secure: true } }))、Rails は config.force_ssl = true で一括して有効になります。
  3. リバースプロキシの背後にある場合、アプリが HTTPS を認識していないと Secure を付けない実装があるため、X-Forwarded-Proto を渡し、アプリ側で信頼する設定も併せて確認してください。
  4. 確認は curl -sI https://example.com | grep -i set-cookie で全行に Secure が付くことです。
  関連用語

  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• オリジン間共有の統制

  検査エンジン原文（英語）

  an arbitrary Origin is not granted access

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  要求された Origin をそのまま許可として返す設定では、利用者が開いた任意のサイトが、こちらのサイトの応答を読めます。資格情報の許可を併せて返している場合、読めるのはログイン済みの応答です。利用者が別のタブで攻撃者のページを開いただけで、こちらの画面に出るはずの情報が持ち出されます。

  対応手順

  1. Access-Control-Allow-Origin に、許可するオリジンを固定値で設定します。
  2. 複数ある場合は、要求された Origin を許可一覧と照合し、一致したときだけその値を返します。
  3. 照合せずに反射してはいけません。
  4. 資格情報が必要な場合のみ Access-Control-Allow-Credentials: true を付け、そのときワイルドカードは使えません。
  5. 確認は curl -sI -H 'Origin: https://example.invalid' https://example.com/ | grep -i access-control で、その Origin が返らないことです。
  関連用語

  • フィッシング - 実在する相手を装った連絡で、パスワードなどを利用者自身に入力させて盗み取る詐欺の手口。
  根拠データを表示 (1 件)

  • http対象 example.com取得 2026/09/01 09:00 JST

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    根拠 ID http:http.probes:example.com

• エラー画面での内部情報の非開示

  検査エンジン原文（英語）

  the error page discloses no internals

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  例外のスタックトレースには、使用しているフレームワークとその版数、ファイルの絶対パス、内部のクラス名や関数名が並びます。データベースのエラーがそのまま出る場合は、テーブルの構造まで推測できます。攻撃者にとっては、次に何を試すかを決めるための情報です。開発時に有効にした表示が、本番に残っている例が多くあります。

  対応手順

  1. 本番環境で詳細なエラー表示を無効にします。
  2. PHP は display_errors = Off（php.ini）、Django は DEBUG = False、Rails は config.consider_all_requests_local = false、Laravel は APP_DEBUG=false です。
  3. あわせて、404 と 500 に共通のエラー画面を設定し、内容は「見つかりません」程度に留めます。
  4. 詳細はログに残し、画面には出しません。
  5. 確認は、存在しないパスと、エラーを起こす要求の両方で、内部情報が出ないことです。
  関連用語

  • バナー - サーバーが接続してきた相手に返す、自分が使っているソフトウェアの名前や版数を含む応答。
  • CVE - 世の中に見つかったソフトウェアの欠陥それぞれに振られる、共通の識別番号。
  根拠データを表示 (1 件)

  • http対象 example.com取得 2026/09/01 09:00 JST

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    根拠 ID http:http.probes:example.com

• HSTS の有効化

  検査エンジン原文（英語）

  strict-transport-security present

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  HSTS が無い場合、利用者がホスト名のみを入力した初回アクセスや古い `http://` リンクからの遷移は平文で送信されます。同一ネットワーク上の攻撃者はこれを横取りし、セッション全体を平文または自前の TLS プロキシに載せたまま維持できます。HSTS は一度成功した訪問以降、ブラウザに HTTP を使用させません。

  対応手順

  1. HTTPS 側のリスナから Strict-Transport-Security: max-age=31536000; includeSubDomains を応答します（nginx は 443 を listen する server ブロック内で add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;、Apache は Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"）。
  2. 取り消しは max-age=0 を応答することで可能ですが、効果があるのは HTTPS で再訪したクライアントのみで、再訪しない利用者の設定は残ります。
  3. そのため、まず max-age=300 程度で開始し、全サブドメインに有効な証明書があることを確認してから 1 年に延長します。
  4. preload と hstspreload.org への登録はさらにその後に行います。
  5. preload 一覧からの削除には数か月を要します。
  6. 確認は curl -sI https://example.com | grep -i strict-transport-security で行います。
  関連用語

  • HSTS - 一度暗号化された接続で訪れたブラウザに、以後そのサイトへは暗号化なしで接続しないよう覚えさせる仕組み。
  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• HSTS preload の要件充足

  検査エンジン原文（英語）

  HSTS meets the preload requirements

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  HSTS は、ブラウザが一度その応答を受け取った後にしか効きません。初回のアクセスだけは平文の HTTP で出ていくため、その 1 回を経路上の攻撃者に奪われる余地が残ります。preload リストに載せると、ブラウザは最初のアクセスから HTTPS を強制します。

  対応手順

  1. apex の応答に Strict-Transport-Security: max-age=31536000; includeSubDomains; preload を設定します。
  2. includeSubDomains はすべてのサブドメインに及ぶため、HTTPS で提供していないサブドメインが 1 つでもあれば到達不能になります。
  3. 先に全サブドメインの HTTPS 対応を確認してください。
  4. 要件を満たしたうえで hstspreload.org から申請します。
  5. 登録の取り消しには数か月を要します。
  6. 短い max-age で一定期間運用し、問題が出ないことを確かめてから申請してください。
  関連用語

  • HSTS - 一度暗号化された接続で訪れたブラウザに、以後そのサイトへは暗号化なしで接続しないよう覚えさせる仕組み。
  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• HTTP から HTTPS へのリダイレクト

  検査エンジン原文（英語）

  HTTP redirects to HTTPS

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  80 番ポートで応答しながらリダイレクトしない場合、攻撃者は利用者をセッション中ずっと平文のまま留め置くことができます。その間、認証情報も Cookie も読み取られ、ページの内容も改ざんされます。利用者からは通常どおり動作しているページに見えます。

  対応手順

  1. 80 番の server ブロックはリダイレクトのみを行います。
  2. nginx: server { listen 80; listen [::]:80; server_name example.com www.example.com; return 301 https://$host$request_uri; }。
  3. Apache: <VirtualHost *:80> 内で Redirect permanent / https://example.com/ または RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]。
  4. ACME の HTTP-01 チャレンジを使用している場合は /.well-known/acme-challenge/ を除外し、HTTP のまま到達できるようにしておきます。
  5. Let's Encrypt は検証時にリダイレクトを追従し、HTTPS への転送も証明書エラーも許容するため、一括リダイレクトのままでも更新が成功する場合が多くあります。
  6. 失敗するのは HTTPS 側の vhost が同じ webroot を配信していない場合で、除外しておけばその依存自体が無くなります。
  7. 確認は curl -sI http://example.com が 301 と https:// の Location: を返すことで行います。
  関連用語

  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  • ACME チャレンジ - 証明書を自動発行する際に、そのドメインを本当に管理しているかを確認するための応答のやり取り。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• 要求メソッドの限定

  検査エンジン原文（英語）

  no writing or diagnostic method is open

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  TRACE は受け取った要求をそのまま返すメソッドで、条件が揃うと他のスクリプトから資格情報を読み出す経路になります。PUT や DELETE、WebDAV の各メソッドは、設定を誤ればファイルの書き換えや削除を許します。いずれも通常の Web サイトの提供には不要です。

  対応手順

  1. nginx は既定で TRACE を受け付けませんが、明示するなら if ($request_method !~ ^(GET|HEAD|POST)$) { return 405; } を書きます。
  2. Apache は TraceEnable off を設定し、WebDAV のモジュールを使っていなければ無効化します。
  3. 書き込みが必要な経路がある場合は、その場所に限定し、認証を必須にしてください。
  4. 確認は curl -sI -X TRACE https://example.com/ が 405 または 501 を返すことです。
  根拠データを表示 (1 件)

  • http対象 example.com取得 2026/09/01 09:00 JST

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    根拠 ID http:http.probes:example.com

• 混在コンテンツの不在

  検査エンジン原文（英語）

  every referenced resource is loaded over HTTPS

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  HTTPS のページが平文 HTTP で資源を読み込むと、その通信だけが保護されません。経路上の攻撃者は、読み込まれるスクリプトを差し替えてページ全体を制御できます。ブラウザはスクリプトや CSS の混在を既定で遮断するため、表示や機能が壊れる形でも現れます。

  対応手順

  1. 該当する参照の http:// を https:// に書き換えます。
  2. 読み込み先が HTTPS に対応していない場合は、別の提供元に変えるか、自サイトに取り込んで配信します。
  3. 数が多い場合は、応答に Content-Security-Policy: upgrade-insecure-requests を付けるとブラウザ側で HTTPS へ読み替えられますが、対応していない読み込み先では読めなくなるため、恒久策は参照の書き換えです。
  4. 確認はブラウザの開発者ツールのコンソールに混在コンテンツの警告が出ないことです。
  関連用語

  • 経路上の攻撃者 - 利用者とサーバーの間の通信経路のどこかに入り込み、やり取りを覗いたり書き換えたりできる立場の攻撃者。
  • CSP - ページの中で実行してよいスクリプトや読み込んでよい外部の場所を、あらかじめ限定しておく仕組み。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• Web サーバの版数非開示

  検査エンジン原文（英語）

  no product version in the Server or X-Powered-By header

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  応答ヘッダに `nginx/1.24.0` のような版数が載っていると、攻撃者は公開されている脆弱性の一覧と突き合わせるだけで、試すべき攻撃を絞り込めます。版数を隠しても脆弱性は塞がりませんが、無差別な走査の対象から外れる効果はあります。

  対応手順

  1. nginx は nginx.conf の http ブロックに server_tokens off; を記載します。
  2. Apache は apache2.conf に ServerTokens Prod と ServerSignature Off を記載します。
  3. アプリケーション側の X-Powered-By は、PHP であれば php.ini の expose_php = Off、Express であれば app.disable('x-powered-by') で止めます。
  4. 再読み込み後、curl -sI https://example.com | grep -iE 'server|x-powered-by' に版数が含まれないことを確認してください。
  関連用語

  • バナー - サーバーが接続してきた相手に返す、自分が使っているソフトウェアの名前や版数を含む応答。
  • CVE - 世の中に見つかったソフトウェアの欠陥それぞれに振られる、共通の識別番号。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• 外部資源への完全性検証の付与

  検査エンジン原文（英語）

  every cross-origin script and stylesheet states an integrity hash

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  外部から読み込むスクリプトは、提供元が差し替えれば、こちらのページで意図しない処理が動きます。提供元自身が侵害された事例も、その配信網が乗っ取られた事例もあります。integrity 属性を付けると、内容が指定した値と一致しない限りブラウザが実行を拒否します。

  対応手順

  1. 外部の script と link に integrity="sha384-..." と crossorigin="anonymous" を付けます。
  2. 値は openssl dgst -sha384 -binary file.js | openssl base64 -A で作れますが、多くの提供元が公開しています。
  3. 提供元がファイルを更新すると読み込めなくなります。
  4. 版を固定した URL（.../lib@1.2.3/lib.js の形）と併せて使い、更新時は値も入れ替える手順にしてください。
  5. 確認はブラウザのコンソールに integrity の不一致が出ないことです。
  関連用語

  • ノンス - 毎回作り直す使い捨ての値で、これと一致するものだけをそのページ限定で信用してよい印として使う。
  • XSS - 本来のページには無いはずのスクリプトを第三者が紛れ込ませ、利用者のブラウザ上で動かしてしまう攻撃。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com

• X-Content-Type-Options による推測の停止

  検査エンジン原文（英語）

  X-Content-Type-Options is nosniff

  上昇幅: 算出していません

  対象 (全 1 件（未検査の対象を含む）)

  • example.com (適合)

  リスク詳細

  このヘッダが無いと、ブラウザは応答の Content-Type を信用せず、中身から種類を推測します。利用者がアップロードした画像やテキストが、内容次第でスクリプトとして実行され得るということです。投稿機能やファイル置き場を持つサイトでは、これが保存型のスクリプト実行につながります。

  対応手順

  1. すべての応答に X-Content-Type-Options: nosniff を付けます。
  2. nginx であれば http ブロックに add_header X-Content-Type-Options "nosniff" always; を追加し、nginx -t && systemctl reload nginx を実行します。
  3. Apache であれば Header always set X-Content-Type-Options "nosniff" です。
  4. nginx では location に add_header が 1 つでもあると server の add_header が全て無効になるため、該当する location がある場合はそこにも書きます。
  5. 確認は curl -sI https://example.com | grep -i x-content-type-options で行います。
  根拠データを表示 (1 件)

  • HTTP 応答（能動検査）対象 example.com取得 2026/09/01 09:00 JST

    HTTP 状態

    200

    最終 URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    根拠 ID http:http.headers:example.com