WEBサイト
11月13日の夜から14日の未明にかけて、当サイトの無料ツール（🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン。サイトの設定を外から確かめて、点数と指摘を出す。使うにはログインが要る）で、8つのサイトを調べた結果を受け取った。俺はその指摘を「すぐ直す」「確かめが要る」「ツールの誤り」の3つに分けて、各サイトの担当者に渡した。
その後、ツールのコードを読み直して分かったことがある。調べたサイトのどれにも、同じ「機密ファイル露出の可能性」という指摘が2行ずつ出ていた。理由は、サイトに問題があったからではない。ツールが調べる場所の一覧の先頭に、公開するのが前提のファイルが入っていて、応答が200なら「露出」と数えていたからだった。担当者に「確かめが要る」と渡した指摘のうち3つが、この種類のツールの誤りだった。
この記事は、診断ツールの答えを人に渡す前に、何を測り直すか、測り直してもなお残る誤りをどう見つけたかの記録だ。読み終えると、診断ツールや外部のスキャン結果を、担当者や顧客に渡す前に確かめる7つの質問が、そのまま使えるようになる。安全のため、調べた8つのサイトの名前や持ち主、どういう関係のサイトかは書かない。書くのは、日付、数、ツールが間違えていた理由、直したこと、まだ確かめていないことだ。
何が起きたか ── 3行で、そして11月13日の夜から14日の午後まで
3行で言うと
- 8つのサイトを診断ツールで調べた結果を、渡す前にツールとは別の方法で外から測り直した。証明書の期限、存在しないURLの応答、httpからhttpsへの転送、ログインのCookieの属性の4つで、このとき見つかった誤りは「証明書の期限が近い」だけだった。
- 14日の昼にツールのコードを読み直すと、誤りは全部で7項目あった（証明書の件を含む。7番目は4つの誤りをまとめた項目なので、数え方は後の表を見てほしい）。どのサイトにも同じ「機密ファイル露出」が出る、当サイト自身を調べると「MySQLに外から接続できる」と出る、などだ。
- 7種類を直し、別の担当者の点検で一度通らず、直して2回目で通り、14日の午後に本番へ出した。担当者に渡した指摘のうち3つがツールの誤りだったので、調べ直して訂正を届けている途中だ。
日付を並べると
公開してよい範囲の出来事を、日付で並べた。
| 日付 | 起きたこと | そのとき分かったこと |
|---|---|---|
| 11月13日の夜から14日の未明 | 8つのサイトを調べた結果を受け取り、指摘を3つに分けて、各サイトの担当者に渡した | 渡す前の測り直しで、「証明書の期限が近い」は誤りと分かった |
| 11月14日の昼 | ツールのコードを読み直した | 誤りは全部で7種類あった。担当者に渡した3つの指摘が、ツールの誤りだった |
| 11月14日の昼から午後 | 誤りを直し、別の担当者に点検してもらった | 1回目の直しは穴が4つあって通らなかった。直して2回目で通った |
| 11月14日の午後 | 4つのファイルを同時に本番へ出した | 本番の版でも当サイトを調べ、途中のエラーは0だった |
この日の順番も書いておく。診断ツールの結果は、そのままでは担当者に渡せない。渡す相手は、自分のサイトのことを知っている人だ。ツールが「露出の可能性」と出せば、その人は、自分のサイトの中を探しに行く。ツールの誤りだったら、その探す時間は無駄になる。だから、渡す側には、「この指摘は、本当にサイトの問題か」を先に切り分ける役目がある。俺は、指摘を「すぐ直す」「確かめが要る」「ツールの誤り」の3つに分けて渡した。ただ、「確かめが要る」という分類は、控えめに見えて、渡す側の確かめを省く逃げ道にもなる、と今は思っている。ツールの誤りかどうかを、渡す前に確かめきれないものを、全部この分類に入れられてしまうからだ。
「担当者に渡した3つの指摘がツールの誤りだった」という行が、この記事でいちばん苦い。渡す前に測り直したのに、測り直した4つの項目に入っていない誤りは、すり抜けた。本番のサイトを、社外の確認役に見てもらった夜で、自分の確かめは見ようと決めたものしか見ない、と書いた。それと同じ形を、診断ツールの結果でもう一度踏んだことになる。
渡す前に、ツールとは別の方法で測り直した
測り直した4つ
ツールの指摘を担当者に渡す前に、同じことを、ツールを通さずに外から測り直した。測ったのは次の4つだ。
- 証明書の期限。8つのサイトとも、期限は30日より先だった。いちばん短いサイトでも、残りは35日あった。
- 存在しないURLを開いたときの応答。8つのサイトとも404が返った。
- httpで開いたときの、httpsへの転送。
- ログインのCookieの属性。
この4つは、ツールを通さずに、外から測り直した。担当者に渡した指摘のうち、後で誤りと分かった3つは、この4つに入っていなかった。
「証明書の期限が近い」は、誤りだった
ツールは、証明書の期限が近いという指摘を出していた。測り直すと、8つとも30日より先で、最短で35日だった。この指摘は、ツールの誤りだった。
理由は、昼にコードを読み直して分かった。ツールは、証明書の残りが90日を切ると「30日以内です」と出していた。文は30日なのに、判定の線は90日だった。自動で更新される証明書は、90日の有効期間のものが多い。Let's Encryptの公式FAQには、既定の証明書は90日有効と書かれている（2026年11月14日に開いた）。有効期間が90日なら、発行して間もなくても、更新の直前でも、残りはほぼ必ず90日を切る。つまり、いつ調べても当たる指摘になっていた。
期限が近い証明書は、本当に危ない。だから、この指摘を黙って消すのではなく、「何日を切ったら近いと数えるか」を設定に出して、文に残り日数を書く形に直した。後の節で書く。
なぜ、別の方法で測り直すのか
1つの道具の答えは、その道具の癖を持っている。同じ道具で2回測っても、癖は消えない。ツールの癖が、サイトの問題のように見えるときがある。別の方法で測ると、癖の分だけ、答えがずれる。ずれた所が、ツールの誤りの候補になる。
ただし、測り直した項目に入っていない誤りは、見つからない。今回の測り直しで見つかったのは、証明書だけだった。機密ファイルの指摘は、測り直す項目に入れていなかった。本番のサイトを、社外の確認役に見てもらった夜で書いた、自分の確かめの性質と同じだ。
コードを読み直して分かった、7種類の誤り
14日の昼、ツールのコードを読み直した。測り直しの後で、ツールのコードを読み直すと、担当者に渡した「機密ファイル露出」「ファイルを読み込む引数」「ファイルインクルージョン」の3つのほかにも、誤りが見つかった。証明書の件を含めて、全部で7項目ある。7番目は、4つの誤りをまとめた1行だ。この記事で「7種類」と書くのは、この7項目のことだ。先に表で並べる。
| # | ツールが出していた指摘 | 実際に起きていたこと |
|---|---|---|
| 1 | 機密ファイル露出の可能性（どのサイトにも2行） | 調べる場所の一覧の先頭が、robots.txtとsitemap.xmlだった。公開するのが前提のファイルで、応答が200なら「露出」と数えた |
| 2 | ファイルを読み込む引数を検出 | URLに引数を付けて、200が返り、本文が100字を超えれば出た。引数を無視するふつうのページでも当たる |
| 3 | ローカルファイルインクルージョン | 応答の本文に「127.0.0.1」という文字があるだけで、穴と判定した。当サイトの記事にも、この文字が載っている |
| 4 | MySQLに外から接続できる（CRITICAL） | 当サイトを調べたときに出た。調べる先の名前が、機械の内側のアドレスに引かれていた。別の回線から測ると、そのポートは閉じていた |
| 5 | 証明書は30日以内に期限が切れる | 判定の線が残り90日で、いつも当たった |
| 6 | X-XSS-Protectionは「1; mode=block」を推奨 | 推奨が古いまま |
| 7 | 重複・エラーの減点・文の穴・見た場所が出ない | 同じ指摘が別の名前で2行出る。「確かめられなかった」を問題として減点した。文に{description}が残った。どのURLを見たのかが結果に出なかった |
それぞれを、読者が自分のツールに当てはめられる形で書く。
1. 公開するのが前提のファイルを、「露出」と数えた
robots.txtは、検索エンジンのクローラーに読んでもらうために公開するファイルだ。sitemap.xmlも、クローラーにURLの一覧を渡すために公開する（🔧 【SEO】WEBサイトの sitemap.xml 作成ツールは、その一覧を作る道具だ）。読めるのが正しい。ところがツールは、調べる場所の一覧の先頭にこの2つを入れて、200が返れば「機密ファイルが露出している可能性」と数えていた。だから、どのサイトでも2行出た。
見分けるきっかけは、全部のサイトで同じ指摘が出ていることだ。控えファイルを外から確かめた日でも、全部が同じ答えになったときは、まず測り方を疑う、と書いた。同じ指摘がどのサイトにも出るなら、サイトの問題より、ツールの条件のほうが先に疑わしい。
なお、RFC 9309（robots.txtの標準）には、robots.txtの規則はアクセスを制限する仕組みではない、という趣旨が書かれている。クローラーに守ってもらうようお願いするものであって、中身を隠すための場所ではない。ここに隠したいものを書かない、という注意とあわせて覚えておくとよい。
2. 引数を付けて200が返っただけで、「読み込む引数」と判定した
ファイル名を渡す形の引数（fileなど）が、サイトの内部のファイルを読み込んでしまう問題は、実在する。パスをたどって、公開の場所の外のファイルを読む攻撃は、OWASPがパストラバーサルとして説明している。
ところがツールは、URLに引数を付けて、200が返り、本文が100字を超えれば、「引数を検出」と出していた。多くのサイトは、知らない引数を無視して、ふつうのページを返す。すると、引数を付けても付けなくても、同じページが返る。同じページが返っただけで、ファイルを読み込んでいるとは言えない。
3. 本文に「127.0.0.1」という文字があるだけで、穴と判定した
ローカルファイルインクルージョンは、サーバー内のファイルを、ページに取り込んでしまう問題だ。ツールは、応答の本文に「127.0.0.1」という文字があるだけで、その穴と判定していた。この文字は、設定や通信の解説記事なら、ふつうに載る。当サイトの記事にも載っている。記事が、この文字を説明に使っているだけで、穴と判定されていた。
4. 調べる先が、機械の内側の名前に引かれていた
当サイトを調べると、「MySQLに外から接続できる（CRITICAL）」と出た。原因は、名前の引き方の違いで、外から測るつもりが、機械の内側のアドレスに向かっていたことだった。内側から見れば、データベースの待ち受け口は、開いているのがふつうだ。それを、外から接続できると報告していた。
別の回線から、同じ待ち受け口に接続を試すと、閉じていた。外から測るつもりのツールが、内側を測っていたことになる。診断ツールの結果は、どこから測ったかで意味が変わる。外から測るつもりが、内側に向かっていないかは、確かめる価値がある。
5. 文は30日、判定の線は90日
先に書いたとおりだ。ここで足したいのは、更新の設定の話だ。Let's Encryptの証明書は、2027年2月10日から標準で64日になる。「残り何日を切ったら近いと数えるか」の線が90日のままだと、64日の証明書は、発行した日から当たり続ける。線は、有効期間の変更にあわせて、設定で変えられる形にしておくほうがよい。
6. 推奨が古いまま。そして、同じ指摘が2行出る
X-XSS-Protectionというヘッダーに、「1; mode=block」を推奨していた。MDNには、このヘッダーは標準ではなく、本番で使うのは勧めない、XSSのフィルターよりContent-Security-Policyを使うのがよい、と書かれている。値の説明には、「0」はXSSのフィルターを無効にする、とある。これらを踏まえて、ツールの「1; mode=block」という推奨は古いと、俺は判断した。
そのほかに、同じ指摘が別の名前で2行出る（DKIM、CAA、DNSSECなど）、「◯◯エラー」と出るもの（ツールが確かめられなかっただけ）を指摘として減点する、指摘の文に{description}という置き換え前の文字が残る、どのURLを見たのかが結果に出ない、という誤りがあった。どれも、ツールの作りの問題だ。ただ、いちばん困るのは最後で、どこを見た結果なのかが書かれていない指摘は、人が確かめようがない。担当者は、その指摘を、信じるか信じないかしかできなくなる。
直したこと ── 指摘に「確かめた場所」を必ず書く
直した内容を、まとめて書く。
- 調べる場所の一覧から、公開するのが前提の2つを外して、設定ファイルへ移した。
- 存在しないURLの応答と、長さを比べる。同じなら、数えない。
- 確かめた場所（URLと、付けた引数）を、指摘の文に必ず書く。
- X-XSS-Protectionは、未設定でも減点しない（情報として出す）。推奨は「0または設定しない」にした。
- 同じ指摘が2行出るのは、題と本文と確かめた場所が同じなら1つにした。別の名前で同じことを言う組（DKIM、CAA、DNSSECなど）は、減点の大きい方を残す。
- 指摘の文に{description}が残らず、置き換わるようにした。
- 引数は、付けて応答が変わったときだけ数える。ファイルの中身の形が、引数なしの応答には無く、引数ありの応答にだけ在るときだけ、ファイルを読み込んでいると判定する。
- 調べる先が内部のアドレスなら、データベースの待ち受け口は「確かめられませんでした」と書いて、数えない。
- 証明書の線を設定に出した（14日と30日の2段）。文には、残り日数を書く。
- 「エラー」は、減点しない。ただし、証明書の取得の失敗は、期限切れなどを隠すので、残す。検証に失敗したときは、別の指摘として出す。
「確かめられなかった」と「問題がある」を分けることも、同じくらい大事だ。確かめられなかったのは、ツールの側の都合で、サイトの状態については、何も言えていない。それを減点すると、点数は、サイトの状態ではなく、ツールがうまく動いたかどうかを表してしまう。ただし、証明書の取得の失敗だけは、期限切れなどを隠すことがあるので、確かめられなかったことを、別の指摘として残した。
この中でいちばん大事なのは、3つ目だ。どこを見た結果かが書いてある指摘は、担当者が自分で同じ場所を開いて確かめられる。確かめた結果が違えば、ツールの誤りの候補になる。誤りの候補が出る形にしておくことが、診断ツールを長く使うための条件だと思う。
存在しないURLとの比較は、地味だが効く。何を開いても200を返すサイトでは、存在しないURLの応答が、調べる場所の応答と同じ長さ、同じ形になる。同じなら、「その場所に在る」とは言えない。逆に、ふつうの404を返すサイトでは、公開が前提でないファイルが本当に読めたとき、応答がはっきり違う。比べるのは、状態コードだけではなく、長さも見る。状態コードが同じ200でも、長さが違えば、別のものが返っている可能性があるからだ。
存在しないURLと比べる、という考え方は、削除したページに何を返すかで書いた「ソフト404」と同じ形だ。ページが無いのに200を返すサイトでは、200は在る証拠にならない。Googleの公式の説明にも、内容が空やエラーのときに、Search Consoleがソフト404と表示すると書かれている。診断ツールでも、ふつうの404が返るサイトと、何を開いても200が返るサイトで、「200なら在る」は意味が違う。
200が返ることと、中身が正しいことは、別の段だ。「リンク切れ0本」も「200が返る」も、まだ2段目だったで書いた、リンクの文字と飛び先がずれていた話と同じで、表に出る答えと中身が合っているかは、別に確かめる必要がある。
最初の直しは、別の担当者の点検で通らなかった
見つかった4つの穴
直したら、別の担当者に点検してもらう。直した本人は、直した前提で読むので、穴に気づきにくい。点検では、1回目の直しに4つの穴が見つかった。
- 判定を行う部品を、別の場所に置いたため、情報漏洩の確かめが全部止まっていた。本物の機密ファイルが開いていても、指摘が出ない形になっていた。
- 「エラー」の減点を0にしたのに、その0が、点数の計算に効いていなかった。
- 証明書の取得の失敗まで減点なしにしていて、本物の不良を隠す形だった。
- 設定が読めないと、指摘が全部、黙って消える形だった。
1つ目と4つ目は、誤検出を減らす直しが、本物を見逃す方向に倒れていた例だ。誤検出を直すとき、怖いのは、直したあとに「何も出ない」ことだ。何も出ないのは、問題が無いのと、見逃しているのとで、画面が同じになる。
記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だったと同じように、直したツールも、まず当サイト自身に当てて、前後を並べた。もう1つ確かめたいのは、直す前に出ていた本物の指摘が、直した後もちゃんと出るかだ。
点検の指摘を直して、2回目で通った。そして、4つのファイルを同時に本番へ出した。判定の部品と、それを読む側を別々に出すと、片方だけが古い状態が生まれうる。今回は、その状態を作らないように、同時に出した。
点数は、どう変わったか
試験用の環境で、当サイト自身を調べた結果を、直す前と直した後で並べる。
| 項目 | 直す前 | 直した後 |
|---|---|---|
| 指摘の件数 | 34件 | 21件 |
| 点数 | 51.6 | 76.0 |
13件減って、点数は24.4上がった。減った13件のうち、どれが誤りで、どれが解消したのかは、ここでは分けていない。表の数字は、試験用の環境のものだ。本番の版でも、当サイトを調べて、途中でエラーが出ないことは確かめた。本番での点数は、この記事には書かない。
点数が上がっても、サイトが安全になったわけではない。ツールの誤りを直しただけだ。担当者に渡す指摘は、点数ではなく、1つずつの根拠で読んでほしい。
点数は、ツールの中の足し算の結果だ。指摘が減れば上がり、増えれば下がる。今回のように、誤りが指摘として数えられていれば、点数は実際より低く出る。逆に、本物の指摘を見逃す直しをすれば、点数は実際より高く出る。点数だけを担当者や顧客に見せると、どちらの場合も、読む人は、点数が動いた理由を知れない。理由を書いた指摘とセットで渡すのは、そのためだ。
すでに渡した指摘は、訂正して届ける
担当者に「確かめが要る」と渡した指摘のうち、3つがツールの誤りだった。機密ファイル露出、ファイルを読み込む引数、ファイルインクルージョンだ。直した版で8つのサイトを調べ直して、訂正を届ける。この作業は、まだ途中だ。
訂正には、3つを入れる。指摘の名前、ツールの誤りだった理由、直した版で調べ直した結果だ。理由まで書くのは、担当者が、ほかの指摘も同じ理由で誤っていないかを、自分で考えられるようにするためだ。
訂正を届ける側として、正直に書く。渡した指摘が誤りだと分かったとき、もし担当者がその確認に時間を使っていたら、その時間は戻らない。だから、訂正は早く、短く、何が誤りで何が残るのかをはっきり書いて届ける。「ツールの誤りだった」「調べ直したら残らなかった」「調べ直しても残った」の3つを、分けて書く形にしたい。
読者が明日できること ── 診断ツールの答えを、人に渡す前に
渡す前の7つの質問
診断ツールや、外部のスキャンの結果を、担当者や顧客に渡す前に、次の7つを確かめるとよい。
- この指摘は、どこを見た結果か。URLや条件が、指摘の文に書いてあるか。
- 同じ指摘が、調べたサイトのどれにも出ていないか。出ているなら、ツールの条件を先に疑う。
- 存在しないURLを開いて、何が返るか。そのサイトの「200」は、在る証拠になるか。
- 公開するのが前提のファイル（robots.txt、sitemap.xmlなど）を、露出と数えていないか。
- 名前の引き方の違いで、外から測るつもりが、内側に向かっていないか。
- 文の日数と、判定の日数が、一致しているか。
- 「確かめられなかった」と「問題がある」が、分けて出ているか。
7つの質問の意味を、短く足す。1つ目と6つ目は、文と根拠を一致させるための質問だ。文が「30日以内」と言うなら、判定も30日でなければならない。2つ目と3つ目は、ツールのものさしが、そのサイトに合っているかを見る質問だ。全部のサイトに同じ指摘が出るときや、200が在る証拠にならないサイトのときは、ものさしを疑う。4つ目は、公開が前提のものを、問題として数えていないかを見る。5つ目は、外から測るつもりが内側に向かっていないかを確かめる。7つ目は、点数や減点の意味を保つための質問だ。「確かめられなかった」を問題として減点すると、確かめられない項目が多いサイトほど、点数が低くなる。点数が低いのは、問題が多いからではなく、ツールが確かめられなかっただけかもしれない。
ツールを選ぶとき、自分で作るとき
市販のツールでも、自分で作った確認の仕組みでも、同じ7つの質問は使える。診断ツールを選ぶときは、1つ目の「どこを見た結果か」が指摘に出るかを、いちばん先に見るとよい。出ないツールは、結果の根拠を、人が確かめられない。
自分で測り直す道具は、難しいものでなくてよい。ブラウザで、存在しないURLを開く。curlで、状態コードだけを見る。証明書の期限は、ブラウザの鍵の表示から読める。ツールの出す点数より、人の手で1つ見るほうが、早く誤りに気づけることがある。外から確かめる方法は、控えファイルを外から確かめた日にも書いた。robots.txtの状態については、robots.txtがエラーを返し続けると、最後は「制限なし」に行き着くで、HTTPステータス別にまとめている。
外から見た結果の読み間違いは、道具の側にも起きる。「吹き出しが出ていない」と写ったでは、画面なしのブラウザで撮った画像が、読者の画面と違っていた。壊れていたのは作ったものではなく、写し方だった。診断ツールの指摘も、サイトが壊れているのか、測り方が違うのか、先に切り分けてから渡したい。
当サイトの現在地と、確かめていないこと
当サイトの現在地
この記事の内容を、当サイトの実施状況で整理した。
- ✅ 当サイト実施済 診断ツールの結果を担当者に渡す前に、ツールとは別の方法で、外から測り直した（証明書の期限、存在しないURLの応答、httpsへの転送、ログインのCookieの属性。11月13日の夜から14日の未明）
- ✅ 当サイト実施済 診断ツールの誤り7種類を直して、本番へ出した（11月14日の午後。4つのファイルを同時に。本番の版でも当サイトを調べて、途中のエラーは0）
- ✅ 当サイト実施済 指摘の文に、確かめた場所（URLと付けた引数）を必ず書く形にした
- ✅ 当サイト実施済 「確かめられなかった」と「問題がある」を分けた（エラーは減点しない。証明書の取得の失敗は、期限切れなどを隠すので残す）
- 🔧 当サイト、これから 8つのサイトを、直した版で調べ直して、担当者に渡した3つの指摘の訂正を届ける
- 🔧 当サイト、これから 画面に出る重さの表示（CRITICALなど）と、点数から引く大きさが食い違っている所を見直す
- 🔧 当サイト、これから データベースに関する別の指摘の文が、言い過ぎになっていないかを見直す
確かめていないこと
確かめていないことも、書いておく。1つ目は、調べ直した結果だ。8つのサイトを直した版で調べ直す作業は、これからで、どの指摘が残るのかは、まだ分からない。2つ目は、本番の版での点数だ。本番の版でも、当サイトを調べて、途中のエラーが出ないことは確かめたが、点数の前後は並べていない。表の34件から21件、51.6から76.0は、試験用の環境のものだ。3つ目は、この記事に書いた7種類のほかに、誤りが無いかどうかだ。コードを読んで見つけたものは7種類だが、読んでいない部分に、同じ種類の誤りが無いとは言えない。
また、この記事には、調べた8つのサイトの名前や、持ち主、サイトどうしの関係は書いていない。ツールの設定や、内部の構造にも、書く必要の無いことには触れていない。書いたのは、起きたこと、日付、数、ツールが間違えていた理由、直した内容までだ。
まとめ ── 渡す前に測り直して、どこを見たかを書いて、全部同じなら疑う
診断ツールが、調べたどのサイトにも同じ「機密ファイル露出」を出していた。原因は、サイトではなく、ツールの調べる場所の一覧の先頭が、公開するのが前提のファイルだったことだ。
渡す前に測り直したのは4つで、見つかった誤りは1つだった。残りの6種類は、コードを読み直して、はじめて見つかった。担当者に渡した指摘のうち3つがツールの誤りだったので、調べ直して、訂正を届ける途中だ。
診断ツールは、サイトを見る道具であると同時に、人に判断を渡す道具でもある。判断を渡すなら、どこを見たのか、確かめられなかったのはどこか、まで一緒に渡すほうがよい。そうすれば、受け取った人は、ツールを信じるか疑うかではなく、自分の目で同じ場所を開いて確かめられる。
明日からできることは、3つある。指摘に「どこを見たか」を書くこと。同じ指摘が全部のサイトに出たら、サイトより先にツールを疑うこと。存在しないURLを開いて、そのサイトの「200」の意味を確かめること。診断ツールの答えは、そのまま信じるものではなく、人が確かめられる形にして渡すものだと思っている。使うときは、🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルンの指摘の文を、見た場所から読んでみてほしい。
関連 archives（連載軸として読む）
- 本番のサイトを、社外の確認役に見てもらった夜 ── 自分の確かめが、見ようと決めたものしか見ないという話（11月13日）
- 控えファイルを外から確かめた日 ── 外から、中身を取らずに状態コードだけで確かめた記事。全部が同じ答えになったときの疑い方も書いた（10月23日）
- 「リンク切れ0本」も「200が返る」も、まだ2段目だった ── リンクの文字と飛び先がずれていた、という記事
- 「吹き出しが出ていない」と写った ── 自動で撮った画像が、読者の画面と違う3つ（9月30日）
- 記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── 書いた手順を、自分のサイトに当てた記事（10月7日）
解説記事では、削除したページに何を返すかと、robots.txtがエラーを返し続けると、最後は「制限なし」に行き着くと、Let's Encryptの証明書は2027年2月10日から標準で64日になるが、この記事の話題に近い。ツールでは、🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン（要ログイン）と、🔧 【SEO】WEBサイトの sitemap.xml 作成ツールが関係する。
出典
すべて2026年11月14日に開いた。
- MDN: X-XSS-Protection（標準ではないこと、Content-Security-Policyを使うことが勧められていること、値「0」の説明）
- IETF: RFC 9309 Robots Exclusion Protocol（robots.txtの規則はアクセスの制限の仕組みではない、の項）
- Google 検索セントラル: HTTPステータスコード、ネットワークとDNSのエラー（空やエラーの内容に対するソフト404の項）
- OWASP: Path Traversal（公開の場所の外のファイルに触れる攻撃の説明）
- MDN: 404 Not Found（存在しないページの応答の意味）
- Let's Encrypt: FAQ（既定の証明書の有効期間の項）
