# ウェブサイトセキュリティスキャン

URL: https://discuvr.org/security-scan/?hl=ja
Last updated: 2026-11-07
MCP tool: `security_scan`

ドメインをスキャンして、不足しているセキュリティヘッダー、TLSの問題、公開されたファイルを検出します。各結果には生の証拠と、それを再現するための正確なコマンドが表示されます。

多くのスキャナーは、アルファベットの評価と不安をあおる言葉の一覧を渡してきます。このツールも評価を付けますが、差し引く 1 点 1 点が、実際に受け取った応答と、同じ応答を自分で得られる 1 行のコマンドを示す検出結果に結びついています。検出結果は信じるものではなく、確かめられるものです。

## 機能

- DNS と CAA、SPF と DMARC、TLS 証明書と TLS 1.0/1.1、HTTPS へのリダイレクト、セキュリティヘッダー、Cookie の属性、CORS、バージョン表示、HTTP メソッド、混在コンテンツ、23 の機密パス、ディレクトリ一覧、robots.txt、security.txt、12 のサービスポートを確認します。
- 各発見事項には、生の観察結果とそれを再現するためのシェルコマンドが付いています。
- 実行できなかったチェックは「未チェック」として報告されます - 黙って合格扱いにすることはありません。
- レポートはMarkdownまたはJSON形式でダウンロードできます。

## 仕組み

1. 自分が責任を持つドメインを入力します。
2. スキャンはパッシブなプローブを実行します - 通常のリクエストであり、攻撃は行いません。
3. 各発見事項をその根拠とともに読み、重要なものを検証します。

## 発見事項は何も作り話ではありません

スキャナーには言語モデルが一切入っていません。深刻度、影響、対処法はチェックごとに固定され、検出結果はすべて実際の観測から生成されます。画面のレポートも Markdown と JSON のダウンロードも同じ検出結果から作られ、どこにもモデルは関わりません。

## 評価の計算方法

スコアは 100 から始まり、重大な検出結果 1 件につき 34 点、高は 13 点、中は 5 点、低は 1.5 点を引きます。深刻度ごとに上限があります（高 45、中 22、低 9）。情報と合格の結果は減点しません。90 以上が A、75 以上が B、60 以上が C、40 以上が D、それ未満が F です。公開された .env ファイルや外部から届くデータベースポートが 1 つあるだけで、問題のないサイトが 100 から 66 の C に下がり、そうした検出結果が 2 件なら 32 の F になります。

## 誤検知を避ける仕組み

/.git/HEAD や /backup.sql のようなパスを調べる前に、スキャナーは存在しえないランダムなアドレスを要求し、サイトの応答を記録します。パスが公開されていると報告されるのは、HTTP 200 を返し、その「見つからない」基準と異なり、さらにそのファイル固有の特徴と一致する場合だけです。どの URL にもトップページを返すサイトが重大な検出結果で埋め尽くされることはありません。

## きれいなレポートは証明書ではありません

これらは稼働中のサイトに対するパッシブなチェックです。アプリケーションのロジック、認証、アクセス制御、ログインの背後にあるものはカバーしません - 実際の侵害が通常始まる場所です。完了できなかったチェックは、まさにこの理由から未チェックとして記載されます。失敗した接続から導かれた合格は偽の安心感であり、発見事項のないスキャンは何も見つからなかったことを意味し、何も存在しないことを意味するわけではありません。

## 自分のものだけをスキャンしてください

自分が所有している、またはテストする書面での許可を得ているドメインをスキャンしてください。このツールは、プライベートまたは内部アドレスに解決されるホストを拒否し、IPごとにレート制限されていますが、認可については依然として自己責任です。

## 質問

**これはアクティブな攻撃ですか？**

いいえ。通常の 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 で確認してください

## プライバシー＆セキュリティのその他のツール

- [画像スクラブ](https://discuvr.org/image-scrub/?hl=ja)

## よく一緒に使われるツール

- [IPアドレス確認](https://discuvr.org/what-is-my-ip/?hl=ja)
- [パスワード生成ツール](https://discuvr.org/password-generator/?hl=ja)

---

Part of Discuvr (https://discuvr.org/): Discuvr is a collection of free, focused tools for day-to-day professional work - office and data utilities, legal and compliance helpers, privacy and security checks, and developer formatters. Every tool has its own page, and most can also be called from ChatGPT or Claude over MCP.