これはアクティブな攻撃ですか？
いいえ。通常の GET、HEAD、OPTIONS リクエスト、TLS ハンドシェイク（TLS 1.0 と 1.1 の試行を含む）、Cloudflare の DNS over HTTPS による DNS 問い合わせ、12 ポートへの単純な TCP 接続を行うだけです。何も悪用せず、フォームも送信せず、何も変更しません。
どのウェブサイトでもスキャンできますか？
自分が所有している、またはテストする権限があるものだけです。許可なく第三者のインフラをスキャンすることは、あなたのいる場所によっては違法となる可能性があります。
チェックが「未チェック」と表示されるのはなぜですか？
完了できなかったためです - 通常はその発信元から何の応答もなかったことが原因です。これは合格として記録されるのではなく、正直に報告されます。
レポートをエクスポートできますか？
はい、Markdown または JSON で 1 時間以内なら可能です。ダウンロードのためにレポートはその間サーバーのキャッシュに残り、その後は失効します。どちらのエクスポートにもモデルは使いません。利用記録に残るのは検出件数と評価で、ドメインは残りません。
どのファイルとポートを調べますか？
ファイル: /.git/HEAD, /.git/config, /.env, /.env.local, /.env.production, /.aws/credentials, /id_rsa, /backup.zip, /backup.sql, /dump.sql, /wp-config.php.bak, /phpinfo.php, /server-status, /actuator/env を含む 23 の固定パスです。応答がそのファイル固有のシグネチャと一致した場合にだけ報告します。/.well-known/security.txt が公開されていれば加点として扱います。ポート: 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080 へ通常の TCP 接続を試すだけで、ログインは一切試みません。外部から到達できるデータベースのポート (MySQL、PostgreSQL、Redis、MongoDB、Elasticsearch) や Telnet は重大と評価します。
SPF と DMARC のチェックでは何を指摘しますか？
どちらのレコードも公開 DNS から読み取ります。メールを送らないサイトでも確認するのは、これがないと誰でもあなたのドメインを名乗るメールを送れるからです。SPF レコードがなければ中、インターネット上のすべてのサーバーを許可する +all を含む SPF は高です。_dmarc に DMARC レコードがなければ中、p=none (または p= タグなし) は監視のみで低、p=quarantine か p=reject なら合格です。メールを一切送らないドメインは v=spf1 -all を公開できます。
どのセキュリティヘッダーを確認し、どの値なら合格ですか？
トップページの応答にある 6 つのヘッダーです。ない場合、HSTS と Content-Security-Policy は高、X-Content-Type-Options と X-Frame-Options は中、Referrer-Policy と Permissions-Policy は低です。Strict-Transport-Security は max-age が 15552000 (180 日) 以上必要で、それより短いと低、max-age=0 は中です。script-src が 'unsafe-inline' を許可している、ポリシーが 'unsafe-eval' を許可している、または default-src か script-src に単独の * ワイルドカードがある場合、Content-Security-Policy は弱体化 (中) と判定されます。X-Content-Type-Options は正確に nosniff でなければなりません。X-Frame-Options は DENY か SAMEORIGIN にし、CSP で frame-ancestors を設定していれば不要です。Referrer-Policy は unsafe-url か no-referrer-when-downgrade のときだけ指摘されます。Permissions-Policy はあるだけで構いません。欠けているヘッダーや弱いヘッダーには、ご自身で確認できる curl -sI コマンドが付きます。
Cookie の属性 (Secure、HttpOnly、SameSite) はどう確認しますか?
トップページの応答にあるすべての Set-Cookie ヘッダー (最大 12 個の Cookie) を読み、それぞれ Secure、HttpOnly、SameSite を確認します。Secure か HttpOnly がなければ中、SameSite だけがなければ低です。Secure のない SameSite=None はブラウザーがその Cookie を拒否するため、別途指摘します。3 つそろった Cookie は合格です。一般的な修正は Secure; HttpOnly; SameSite=Lax です (Django では SESSION_COOKIE_SECURE、SESSION_COOKIE_HTTPONLY、SESSION_COOKIE_SAMESITE)。スキャンはログインしないため、ログイン後にだけ設定される Cookie は見えません。ご自身で確認するには curl -sI https://your-site/ | grep -i set-cookie
CORS チェックはどう動き、どんなときに重大になりますか?
トップページに Origin: https://scanner-probe.example を付けた GET リクエストを 1 回送り、応答の Access-Control-Allow-Origin と Access-Control-Allow-Credentials を読みます。Access-Control-Allow-Origin ヘッダーがない、またはテスト用オリジンを返さない固定のオリジンなら合格です。テスト用オリジンを Access-Control-Allow-Credentials: true と一緒に返すのは重大です。ログイン中のユーザーが訪れたどのサイトでも、そのユーザーの応答を読めてしまうからです。認証情報なしでオリジンを返すのは中です。ワイルドカード * は低、認証情報も許可していれば中です (ブラウザーはこの組み合わせを拒否します)。調べるのはトップページだけで、OPTIONS のプリフライトも送らないため、API のルートは別途 curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control で確認してください。
TLS チェックでは何を調べますか（証明書の有効期限、TLS 1.0 と 1.1）？
ポート 443 に接続し、証明書チェーンとホスト名を検証します。検証に通らない証明書は高、期限切れの証明書はさらに重大としても示され、残り 15 日未満の証明書は中です。それ以外の場合は、サブジェクト、発行者、有効期限、SAN 名が合格として表示されます。ネゴシエートされたプロトコルは TLS 1.2 か TLS 1.3 である必要があり、それより古いものは高です。続いて TLS 1.0 と TLS 1.1 のハンドシェイクを個別に試します。どちらかを受け入れるサーバーは中の指摘になります。どちらも RFC 8996 で非推奨とされているためです。スキャナー自身の OpenSSL が古いバージョンを提示できない場合は、推測せずに何も報告しません。nginx での修正は ssl_protocols TLSv1.2 TLSv1.3; 日付は次のコマンドで自分で確認できます： echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates
HTTP から HTTPS へのリダイレクトも確認しますか？
はい。リダイレクトをたどらずに http://your-site/ をリクエストします。https:// のアドレスへの 301 または 308 は合格です。HTTPS への 302、303、307 は低です。ブラウザは一時的なリダイレクトを記憶しないため、新しい訪問のたびに暗号化されていないリクエストが 1 回発生するからです。暗号化されていない HTTP でページを返す場合（2xx 応答）は高です。ポート 80 がまったく応答しない場合は情報扱いで、失敗ではありません。nginx での修正は server { listen 80; return 301 https://$host$request_uri; } で、そのうえで Strict-Transport-Security を追加します。次のコマンドで自分で確認できます： curl -I http://your-site/
どの HTTP メソッドを指摘しますか（TRACE、PUT、DELETE）？
ホームページに OPTIONS リクエストを 1 回送り、Allow ヘッダーを読みます。Allow がなければ Access-Control-Allow-Methods を読みます。TRACE、TRACK、PUT、DELETE のいずれかが提示されていれば中、PATCH や CONNECT だけなら低、標準の読み取りメソッドだけなら合格です。サーバーがどちらのヘッダーも返さない場合は何も報告しません。提示されているからといって実際に動くとは限らないので、変更する前に確認してください。TRACE は Cookie を含むリクエストヘッダーを呼び出し元にそのまま返すことがあります（Cross-Site Tracing）。nginx は既定で TRACE を拒否します。Apache では TraceEnable Off を設定します。PUT と DELETE は必要な API ルートだけに限定し、認証の内側に置いてください。次のコマンドで自分で確認できます： curl -X OPTIONS -i https://your-site/
ディレクトリリスティング（"Index of /"）はどう検出しますか？
7 つのパスをリクエストします： /, /static/, /assets/, /uploads/, /images/, /files/ と /backup/。HTTP 200 で、タイトルまたは主見出しが "Index of /" で始まるページを返すパスは中として報告されます（CWE-548）。どこからもリンクされていないファイル、たとえばバックアップ、エクスポート、古いバージョンが一覧で見えてしまうためです。該当がなければ合格、サイトに到達できなければ未実施として報告されます。nginx での修正は autoindex off;（これが既定値なので、明示的に書かれた autoindex on を探してください）、Apache では Options -Indexes で、そのうえで機密性のあるものをすべてウェブルートの外に移します。次のコマンドで自分で確認できます： curl -s https://your-site/uploads/ | head -20
混在コンテンツや HTTP で送信するフォームを検出できますか？
はい、トップページについて検出します。サーバーが返す HTML をそのまま読み（JavaScript は実行しません）、src または href が http:// で始まる script、link、iframe、img タグをすべて一覧にします。その中に .js または .css ファイルがあれば中リスクです。途中で差し替えられたスクリプトやスタイルシートが HTTPS ページ内で実行されるためです。画像とフレームだけなら低、1 つもなければ合格です（CWE-311）。action が http:// で始まるフォームは高リスク（CWE-319）と報告されます。入力した内容はパスワードも含めて暗号化されずに送信されるためです。対策は、それらの URL を https:// にするか相対パスにし、保険として Content-Security-Policy: upgrade-insecure-requests ヘッダーを追加することです。自分で確認するには curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"
robots.txt と security.txt では何を確認しますか？
robots.txt：/robots.txt を取得し、HTTP 200 のテキストファイルであれば先頭 8000 文字の Disallow 行を読みます。admin, internal, private, backup, config, staging, test, api, secret, dev のいずれかを含む Disallow パスは低リスク（CWE-200）と報告されます。robots.txt は公開されており、行儀のよいクローラーに立ち入らないよう頼むだけなので、そうしたパスを書くことはかえって宣伝になります。ログインで保護し、検索から外したいページには noindex を使ってください。security.txt：RFC 9116 が定める場所 /.well-known/security.txt をリクエストし、ファイルに Contact: 行があれば加点として扱います。ファイルがなくても減点はありません。RFC 9116 は Expires: フィールドも必須としていますが、スキャンはこれを確認しないので、両方を公開してください。例：Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z。自分で確認するには curl -s https://your-site/.well-known/security.txt
CAA チェックは何を見ますか。CAA レコードはどう追加しますか。
入力したホスト名の CAA レコード（RFC 8659）を Cloudflare の DNS-over-HTTPS で照会します。見つかればチェックは合格で、証拠に最大 5 件を表示します。1 件もなければ "No CAA record" を重要度「低」で報告します。その場合、どの公開認証局でもこの名前の証明書を発行できるからです。CAA レコードには実際に使う CA を列挙します。例: your-site. IN CAA 0 issue "letsencrypt.org"。報告を受け取るには 0 iodef "mailto:security@your-site" も追加します。使う CA ごとに issue 行を 1 行ずつ追加し、ワイルドカード証明書を別の CA から発行する場合は issuewild 行も加えます。自分で確認するには dig CAA your-site
www やサブドメインをスキャンすると CAA、SPF、DMARC がないと出るのはなぜですか。
DNS チェックはすべて入力した名前そのものに対して行われるため、www.example.com は example.com ではなく www.example.com として照会されます。そして 3 種類のレコードは継承の仕方が異なります。CAA: www.example.com に CAA レコードがない場合、認証局は example.com までさかのぼってそのレコードを使います（RFC 8659 セクション 3）。そのため、サブドメインでの "No CAA record" は誤検知のことがあります。DMARC: 受信側は組織ドメインのポリシーにフォールバックし、そのポリシーは sp= でサブドメイン用に別の設定ができます（RFC 7489 を廃止した RFC 9989）。そのため _dmarc.www.example.com にレコードがなくても、通常は _dmarc.example.com でカバーされます。SPF: 継承はありません（RFC 7208）。そのため、その名前について "No SPF record" は正確です。メールを送らないホスト名は v=spf1 -all を公開できます。DNS 照会が失敗した場合もレコードなしと表示されます。www なしのドメインもスキャンするか、dig CAA example.com と dig TXT _dmarc.example.com で確認してください