WEBサイト
2026年10月23日の未明（1時台）、チームの仲間から知らせが届いた。別のサイトでは、設定ファイルの控え（元のファイルを直す前に写しておいたもの）が、読める場所に残っていた、という内容だった。当サイトのサーバーを調べると、サーバーの設定ファイルの控えが17本見つかった。内訳は、当サイトが13本、同じサーバーの別のサイトが4本だ。外からは読めない状態（403）だったが、公開の場所（Webサーバーが外へ返すフォルダ）の外へ移した。同じ23日の2時台には、公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移すで書いた手順を、当サイトにそのまま当てた。
この記事は、その記録だ。手順の解説は、解説記事の公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移すが受け持つので、ここでは繰り返さない。書くのは「自分のサイトで実際にやったら、何本あり、何が分かり、何を踏んだか」だ。読み終えたら、担当サイトで同じことを明日できるようにするのが目的になる。安全のため、フォルダやファイルの名前、置き場所、サーバーの設定の中身は書かない。書くのは、件数、確かめ方、順番、踏んだことまでだ。
何をしたか ── 3行で、そしてなぜ今日だったか
3行で言うと
- 名前に控えの印（.bakや日付つきなど）があるファイルのうち、PHP以外の1,271本を、外から1本ずつ叩いて状態コードだけを見た。403が1,246本、200（外から読めた）が25本だった。
- 読めた25本は、どのページからも読み込まれていない古いCSS・JS・HTMLだった。すぐ公開の場所の外へ移し、25本とも404になったのを確かめた。
- 外から読めた25本は、先に移した。続けて、残りの控え3,095本を、消さずに、元と同じ並びのまま、公開の場所の外へ移した。そのうち外から状態を確かめたのは1,535本（1,246本と289本）で、すべて403だった。移す前と後で、指紋（中身から計算する目印）は全部一致した。
なぜ今日だったか ── PHPの件の翌日に、記事の手順を自分に当てた
前日までの2日間は、PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本での対応で動いていた。その中で、更新の前に「設定ファイルの控えを取っておく」作業を何度もした。控えを取るのは正しい習慣だが、その控えを置く場所を決めていなかったら、どうなるか。
そこで、記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だったと同じ型を使った。記事に書いた確認項目を、書いた日のうちに自分のサイトに当てる。その記事で書いたとおり、自分で書いたチェック項目を自分に向けると、記事の弱点が見つかることがある。今回も、記事を公開したその日のうちに当てることにした。
担当サイトを預かるWEBディレクターには、他人事ではない話だと思う。サイトは、何人もの手を通る。制作会社が納めたあとの修正、運用担当の急ぎの直し、引き継ぎのときの作業。そのたびに「念のため写しを取る」が起き、取った写しは、取った人の頭の中にしか残らない。公開の場所に残った控えは、誰のものかも、いつ取ったかも、あとから分からなくなる。当サイトは小さなサイトだが、それでも、公開の場所には3,095本の控えが残っていた。担当サイトが複数あれば、数がもっと増えていても不思議はない。
何本あったか ── 状態コード別、名前の形別に数えた
最初に見つけた17本は、設定ファイルの控え
10月23日の未明に見つけたのは、サーバーの設定ファイルの控えが17本だ（当サイトが13本、同じサーバーの別のサイトが4本）。外からは読めない状態だったので、緊急ではなかった。それでも、公開の場所の外へ移した。本物の設定ファイル4本には触っていない。移す前と後で、指紋が同じことを確かめた。
ここで、「名前が.htで始まるファイルは、既定で外から読ませない」という考え方が出てくる。Apacheの設定の雛形のコメントには、こう書かれている。
"The following lines prevent .htaccess and .htpasswd files from being viewed by Web clients."
（日本語訳: 次の数行は、.htaccessと.htpasswdのファイルが、ウェブのクライアントから見られるのを防ぐ。）
この雛形のコメントの下には、<Files ".ht*"> という指定が書かれている。ファイル名の指定について、Apacheの文書は次のように説明している。
"The filename argument should include a filename, or a wild-card string, where ? matches any single character, and * matches any sequence of characters."
（日本語訳: ファイル名の引数には、ファイル名か、ワイルドカードの文字列を書く。?は任意の1文字に、*は任意の文字の並びに当たる。）
文書に書かれている範囲で読むと、.ht* は「名前の先頭が .ht のファイル」に当たる。ここまでは文書の話だ。例として、先頭に日付を付けたあとに、設定ファイルの元の名前が続く形の名前は、先頭が .ht ではない。この既定の指定では、守りの対象にならない。ただし、配布されている設定や、貸しサーバーの設定が雛形のままとは限らない。自分のサイトでは、状態コードを叩いて確かめるまで、守られているとは言えない。
名前に控えの印があるPHP以外の1,271本を、外から叩いた
同じ23日の2時台には、公開の場所のうち、PHP以外のファイルを対象にした。名前に控えの印（.bakや.old、日付つきの名前など）があるものが1,271本あった。これを外から1本ずつ叩いて、状態コードだけを見た。結果は次の表のとおりだ。
| 状態コード | 本数 | 意味 |
|---|---|---|
| 403 | 1,246本 | 外から読めない（拒否された） |
| 200 | 25本 | 外から読めた |
| 合計 | 1,271本 | PHP以外の、控えの印がある名前 |
1,271本のうち98.0%は403で、読めなかった。残る25本（2.0%）は読めた。割合だけを見れば小さいが、読めたものは、守りの網から漏れていた、ということだ。
この割合は、当サイトの場合の数字だ。担当サイトで同じ割合になるとは限らない。サイトの作り方、作業の癖、サーバーの設定しだいで、200の本数は0にも、何百にもなる。大事なのは割合ではなく、自分のサイトで数えると何本出るかを、一度は知っておくことだと思う。数えていなければ、「守られているはず」という推測のまま過ごすことになる。仕組みは在った。運ぶ気もあった。探す形が違っていたで書いたように、仕組みが在っても、探す形が違えば見つからない。
読めた25本の中身 ── どのページからも使われていない古いファイル
200が返った25本の中身は、次のとおりだ。
| 種類 | 本数 | どのページから読み込まれているか |
|---|---|---|
| 古いCSS | 12本 | どのページからも読み込まれていない |
| 古いJS | 11本 | どのページからも読み込まれていない |
| HTML | 2本 | どのページからも読み込まれていない |
25本とも、サイトの表示には使われていなかった。そこで、公開の場所の外へ移した。移したあとで、25本とも404になったことを確かめた。
外から確かめる方法 ── 中身は取らず、状態コードだけを見る
手順は、名前の一覧を作り、1本ずつ叩くだけ
やったことは単純だ。公開の場所から、控えの印がある名前の一覧を作る。その名前を、自分のサイトのアドレスに付けて、外から要求する。返ってきた状態コードだけを記録する。中身は読まない。これは、自分が運営するサイトにだけやる。他人のサイトに同じことをしてはいけない。
OWASPのガイドは、状態コードの読み方について、こう書いている。
"automated tools report on status codes and fingerprints, not on whether a file actually contains sensitive data"
（日本語訳: 自動の道具が報告するのは、状態コードと指紋であって、ファイルが実際に機密を含んでいるかどうかではない。）
だから、403だから安全、404だから無い、とは言い切れない。200が返ったものは、その場で「読めた」と数える。403のものは「外からは読めなかった」と数える。それ以上は言わない。今回も、状態コードを数えただけで、中身が何だったかは別の話として扱っている。
状態コードだけを出力するには、curlの書き出しの指定を使える。curlのマニュアルは、response_codeという変数を、直前の転送で見つかった数値の応答コードと説明している（要旨）。ヘッダーだけを取るやり方もあり、HTTPのHEADという命令を使う。この手順の中身は、公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移すの2段目に、そのまま使える形で書いてある。
状態コードを読むときは、200以外にも目を向ける。OWASPのガイドは、301や302（転送）、401（認証が要る）、403（拒否）、500（サーバーの内部のエラー）も、さらに調べる価値のある手がかりになると書いている。今回の1,271本では、403と200だけを数えた。1,271本は、403と200のどちらかに収まった。もし担当サイトで別の状態コードが混ざっていたら、それも一覧に残しておくとよい。
全部同じ答えが出たら、まず測る側を疑う ── 289本が「000」になった
この作業で、最初に踏んだのがこれだった。残っていた控えのうち、289本を外から叩く1回目は、289本とも「000」（つながらない）と出た。サイトのトップは200を返していたので、サイトの側には問題がなかった。
原因は、手元のWindowsの端末（Git Bash）にあった。URLに渡した「/」で始まる文字列を、端末が手元のフォルダの道すじだと思い、別の文字列に書き換えていた。MSYS2の文書は、この動きをこう書いている。
"When calling native executables from the context of Cygwin, then all the arguments that look like Unix paths will get auto converted to Windows."
（日本語訳: Cygwinの環境からネイティブの実行ファイルを呼ぶとき、Unixの道すじに見える引数は、すべて自動でWindowsの道すじに変換される。）
書き換えを止めて測り直すと、289本とも403だった。教訓は、「全部が同じ答え」が出たら、サイトより先に測る側を疑うことだ。289本が全部000という結果は、289本が全部壊れていることよりも、測り方が1つ壊れていることのほうがずっと起こりやすい。トップが200を返していたことが、疑う手がかりになった。
同じ形の失敗は、担当サイトの点検でも起きやすい。手元の端末、社内のネットワーク、点検用の道具の設定は、点検する人の数だけ違う。「全件エラー」「全件0件」「全件同じ値」という結果が出たら、サイトの故障を疑う前に、1本だけ、結果が分かっているものを叩く。トップページでも、存在しないと分かっている名前でもよい。その1本が期待どおりなら測る側は動いている。期待と違えば、測る側が壊れている。この確認は、数秒で済む。
動かす前に確かめたこと ── 移して壊さないために
「参照が0件」は、数え方が効くと確かめてから言う
控えを移す前に、生きているコードや定期実行の設定が、その名前やフォルダを参照していないかを数えた。結果は0件だった。ただし、「0件」だけでは何も言えない。数え方が壊れていても0件になるからだ。
そこで、必ず在ると分かっている名前（ふだん使っている部品の名前）で、同じ数え方を先に走らせた。5件と2件と出た。数え方が生きていると分かってから、控えの名前で数えて0件だった。この順番が大事で、「探したが無かった」と「探せなかった」を区別するための一手間になる。
フォルダごと読み込まれる仕組みに、当たらないか
もう1つ確かめたのは、フォルダごと自動で読み込まれる仕組みだ。拡張機能を置いたフォルダは、名前を指定しなくても、まとめて読み込まれることがある。控えのフォルダがそこに入っていたら、移した途端に動かなくなる。
有効な拡張機能は、データベースの一覧に10個あった。控えのフォルダは、その一覧に入っていなかった。一覧と、移す対象の名前を突き合わせて、重なりが0であることを確かめた。
移す前に、全ファイルの指紋（md5）と大きさを一覧に控えた。移した先で、同じ一覧と突き合わせる。不一致があれば、元を消さずに止まる。戻し方を書いた説明書きも、同じ場所に置いた。
移す形は、消さずに「元と同じ並びのまま、公開の場所の外へ置く」ことにした。消すかどうかは、1週間なにも起きなければ、ナミオさんと決める。控えが要るか要らないかは、見ただけでは決められない。消すと戻せないが、移すだけなら戻せる。
移す先も、慎重に決めた。移し先が公開の場所の中だと、移しても意味がない。外から同じ道すじで読めてしまうからだ。移す前に、移し先が公開の場所の外であることを、道すじで確かめた。この確認は、公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移すの4段目の手順にも、止まる条件として書いてある。
3,095本を、2回に分けて移した
10月23日の昼（12時7分から17分）に、先に移した25本とは別に、残っていた控えを全部、公開の場所の外へ移した。2回に分けて、計3,095本だ。外から1本ずつ状態を確かめたのは、そのうち1,535本（1回目の中の1,246本と、2回目の289本）で、すべて403だった。1回目のPHPの控えは、外から1本ずつ確かめていない。
| 回 | 本数 | 中身 |
|---|---|---|
| 1回目 | 2,806本 | 日付つきで丸ごと写したフォルダが7つ（1,635本）。残りの1,171本は、編集の前に取った控えなど |
| 2回目 | 289本 | 外から叩くと289本とも403。うち名前が.phpで終わるものが203本（先頭に日付の印が付いた名前が73本、日付つきのフォルダの中にあるものが128本、その他が2本） |
| 合計 | 3,095本 | 移した先で、指紋は全部一致（不一致0）。公開の場所に残った数も0 |
外から読めた25本は、先に移した。続けて残りの控え3,095本を外へ移した。そのうち外から状態を確かめたのは1,535本で、すべて403だった。数だけを見ると、25本よりずっと大きい。公開の場所に、3,095本の控えが残っていた。なお、本番では、名前の先頭に印を付けた写しを、探し方を広げて探したら、さらに1本出て、それも外へ移した。1回の探し方では、拾えない形が残る。
内訳を見ると、日付つきで丸ごと写したフォルダが7つあり、それだけで1,635本、全体の半分を超えた。作業の前に、フォルダごと写しておく。その気持ちは分かるが、フォルダごとの写しは、1回で数百本の控えを生む。1本ずつ消す手間が大きいので、そのまま積もる。もしこれから同じ作業をするなら、写す先を最初から公開の外にしておくのが、いちばん安い。
2回目の289本は、1回目とは別の束として、移す前にもう一度外から叩いた。結果は289本とも403だった。「全部移した」と言う前に、もう一度数え、もう一度叩く。1回の探し方で拾えるのは、その探し方の形に合う名前だけだからだ。
名前の形で分けると、控えは大きく3つの形に分かれた。1つ目は、元の名前の後ろに印が付く形（.bakなど）。編集の前に取る、いちばん典型的な控えだ。2つ目は、名前の先頭や途中に日付が入る形。名前の最後が元のままなので、末尾だけで探す方法では漏れる。3つ目は、フォルダごと日付つきで写した形で、1回で大量の控えを生む。公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移すも、名前の型を分けて探し方を変えることを勧めている。
2回目の289本のうち、名前が.phpで終わるものは203本あった。内訳は、先頭に日付の印が付いた名前が73本、日付つきのフォルダの中にあるものが128本、その他が2本だ。名前の最後が.phpのままなので、遮断の書き方しだいでは、控えのつもりのファイルが、そのまま実行されうる。「外から読めない」と「安全」は、別の話だ。この形は、403が返っていても、置かないほうがよいと判断した。当サイトでは403が返っていたので、実行できたかどうかは確かめていない。
読者への注意を1つ書く。PHPの控えを外から要求すると、遮断がなければ、実行される恐れがある。PHPの控えは、外から叩いて確かめるより、サーバーの中で名前を数えて、外へ移すほうが安全だ。当サイトの2回目の289本は、外から要求して、403が返った。実行されたかどうかは、確かめていない。
動かした後に比べたこと ── 前と同じか
応答とブラウザの中身を、前後で並べた
移す作業の前後で、サイトの表示が変わっていないかを、次のとおり比べた。200が返るだけでは足りないので、ブラウザで開いた中身まで見た。
| 比べたもの | 数 | 結果 |
|---|---|---|
| 主な箇所の応答の状態と大きさ | 14か所 | 同じ。違ったのは、トップの時計の表示の1バイトだけ |
| ブラウザで開いたページの中身 | 10ページ | 同じ。見出しの数、リンクの数、画像の数、構造化データ、本文の長さ。壊れた画像は0、PHPのエラー表示も0 |
| エラーの記録 | — | 新しい種類のものは出ていない |
| 移した先の指紋 | 3,095本 | 全部一致（不一致0） |
| 公開の場所に残った控え | — | 0本 |
「前と同じ」は、同じ測り方で測る
前後を比べるときに、もう1つ気をつけることがある。比べる測り方は、前と同じにする。測り方を書き直すと、違いがその測り方の側から生まれる。測る側の読み違いを書いた外から取った画面は、目当ての画面とは限らないと、同じ形の話だ。測り方が変わると、結果の違いが、サイトの違いなのか測り方の違いなのか、分からなくなる。
403でも置かない4つの理由
1つ目と2つ目 ── 名前の形に頼っている、設定は外れることがある
1,246本は403で、外から読めなかった。それでも移した理由は、4つある。1つ目は、Apacheの既定の設定では、遮断が名前の形に頼っていることだ。先頭に日付を付けた設定ファイルの控えは、既定の守りから漏れることがある。
2つ目は、遮断の設定そのものが外れることがあることだ。サーバーの引っ越し、設定の変更、使っているソフトの更新で、遮断の指定が消えることがある。そのとき、公開の場所に控えが残っていれば、一斉に読めるようになる。Apacheの文書は、既定の動きをこう説明している。
"if the server can find its way to a file through normal URL mapping rules, it can serve it to clients."
（日本語訳: サーバーが、通常のURLの対応づけの規則でファイルにたどり着けるなら、それをクライアントに返せる。）
拒否の指定がなければ、公開の場所の中のファイルは、返る。守りは「足してある」ものであって、最初から在るものではない。足してある守りは、足した人が覚えているあいだは効く。人が入れ替わり、サーバーが替わると、足したことごと忘れられる。
3つ目と4つ目 ── 古い写しは弱点を持ち、見分ける手間も増える
3つ目は、古いコードの写しが、直す前の弱点をそのまま持っていることだ。OWASPのガイドは、脅威の1つに、いまの版では直した脆弱性が、古い控えに残る場合を挙げている。PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本でで書いたような更新の日は、古い写しの存在が気になる日でもある。
4つ目は、点検のたびに「本物か、控えか」を見分ける手間が増えることだ。3,095本の控えが紛れていれば、本物のファイルを探す一覧にも、その3,095本が混ざる。点検が重くなると、点検が遠のく。「リンク切れ0本」を確認して、安心しかけたで書いたように、数えた結果の読み方は、何を数えたかで変わる。控えの棚卸しでも、控えが減れば、本物のファイルだけを見ればよくなる。確かめる範囲が狭くなるのは、それだけで点検の質を上げる。
担当サイトを制作会社や運用会社に任せている場合は、次のように聞けば、状況が分かる。「納品のあと、公開の場所に控えを置かない決まりはありますか」「定期的に、控えの印がある名前を探して、外から読めないか確かめていますか」。答えが「確かめたことはない」でも、責める話ではない。確かめる日を決めるきっかけになる。
積もった理由と、次から積もらない手順
作ったのは、自分たちだった
控えの多くは、当サイトの作業から生まれた。3,095本のうち、2025年7〜8月の作業の控えが1,834本（59%）、2026年8〜9月の作業の控えが1,192本（39%）だった。半数以上は1年以上前の作業の控えで、約4割が今年8〜9月に、記事を一括で直したときなどの作業の控えだ。ブログの案内のページに使うデータの控えも、10月上旬まで、公開の場所に作っていた。誰かが外から置いたのではない。自分たちが作った。
OWASPのガイドは、サーバー上で直接編集する習慣を、とくに悪いものとして挙げている。
"Editing files in-place on the web server or application server file systems. This is a particularly bad habit, since it is likely to generate backup or temporary files by the editors."
（日本語訳: Webサーバーやアプリケーションサーバーのファイルシステムの上で、ファイルを直接編集すること。エディタが控えや一時ファイルを作りやすいので、とくに悪い習慣である。）
当サイトの控えは、エディタが勝手に作ったものではなく、手順のなかで自分たちが意図して取ったものだ。ただ、取った控えの置き場所を、決めていなかった。
片づけただけでなく、次から積もらない手順に変えた
片づけは、1回で終わる。控えは、また生まれる。しかも、控えを取るのは良い習慣なので、やめるわけにはいかない。やめるのではなく、置き場所を変える。そこで、手順書に書き足した。「控えは、公開の場所の外の、決まった場所に作る」。今まで、これが書かれていなかった。書かれていなければ、作業する人は、いちばん近い場所に置く。
OWASPは、この種の問題への対策として、次のように書いている。
"Adopt configuration management policies that prevent obsolete and unreferenced files from accumulating in served directories."
（日本語訳: 古くなったファイルや、どこからも参照されていないファイルが、公開のフォルダに積もらないようにする、構成管理の決まりを採用する。）
教訓は1つ。「片づけた」だけでは、終わらない。「次から積もらない手順に変えた」までやって、初めて終わる。
WEBディレクターが、担当サイトで明日やること
13項目のうち、このブログで分かった落とし穴の7つ
公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移すには、13項目のチェックリストがある。ここでは、当サイトで実際に踏んだ落とし穴から、明日できる7つを選んだ。13項目の全部は、その記事を開いてほしい。
- 状態コードが全部同じだったら、サイトより先に、測る側（端末や道具）を疑う。トップが200かを、先に1本叩く。
- 「参照が0件」と書く前に、必ず在る名前で同じ数え方を走らせて、0でない結果が出ることを確かめる。
- フォルダごと自動で読み込まれる仕組みの一覧を見て、移す対象のフォルダが入っていないことを確かめる。
- 移す前に、全ファイルの指紋と大きさを一覧にする。移した先で突き合わせ、戻し方を書いた説明書きを同じ場所に置く。
- 前後で、主要な箇所の応答と、ブラウザで開いた複数ページの中身を、同じ測り方で比べる。
- 403で返っていた控えにも、「移す」か「残す理由を書く」かを決める。名前が.phpのままの写しは、とくに先に決める。
- 控えを置く場所を、公開の場所の外に決めて、手順書に書く。定期的に（当サイトは週に1回にする）、同じ探し方をもう一度走らせる日を、予定に入れる。
自分でログを調べる必要がある場面では、🔧 IPAのiLogScannerでアクセスログを調べるツール（会員登録が必要）が役に立つ。外から見える範囲を、自分が管理するサイトで確かめたいときは、🔧 外からできるセキュリティ対策監査ツール（会員登録が必要）を使える。
まとめと、当サイトの現在地
全体を通した感想を1つ書く。控えは、悪意のある誰かが置くものではなく、丁寧に作業する人が善意で生むものだ。だから、見つけたときに責める相手がいない。責める相手がいない問題は、仕組みで直すしかない。
持ち帰ってほしいことは4つ。①外から読めた控えは、全体の2%でも、守りの網から漏れていた。②全部同じ答えが出たら、測る側を疑う。③403でも、名前の形に頼った守りは外れることがある。④片づけたら、次から積もらない手順まで変える。
確かめていないことも、書いておく。1つ目は、ほかのサーバーや貸しサーバーの既定の設定が、Apacheの雛形のとおりかどうかだ。雛形は雛形であって、各社の設定ではない。2つ目は、外から叩く段階で取ったのは状態コードだけで、控えの中身を調べる作業とは別だということ。3つ目は、移した控えを将来消したときの影響で、これは1週間様子を見てから考える。4つ目は、MITREのCWE-530を開けなかったので、その内容には触れていないことだ。
この記事で書いたことについて、当サイトの現在地を、正直に書く。
✅ 当サイト実施済 本番の控えを、全部、公開の場所の外へ移した（10月23日）。外から読めた25本は404になり、3,095本の指紋は全部一致した。
✅ 当サイト実施済 公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移すの07章で「棚卸しを続けている」と書いた分を、この日に終えた。外から読めたものは移し、読めなかったものも移した。
✅ 当サイト実施済 控えを公開の場所の外の決まった場所に作る、という決まりを、手順書に書いた。
✅ 当サイト実施済 公開前の確認用のサイトでも、同じ日の昼に、同じ手順で外へ移した。権限の都合で動かせなかったログの置き場の2本（外からは届かない場所）だけは残した。
📋 予告 移した控えは、消していない。1週間なにも起きなければ、ナミオさんと、本当に消すかを決める。
🔧 当サイトこれから 名前に控えの印があるファイルが、公開の場所に増えていないかを、週に1回、自動で数えて知らせる仕組みを作る。今回は手で数えた。
関連 archives（連載軸として読む）
- PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 更新の前に取る控えの話が出てくる、直前の記録
- 記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── 記事の確認項目を、公開した日に自分のサイトへ当てた記録
- 外から取った画面は、目当ての画面とは限らない ── 外から取った画面と、測る側を疑う話
- 「リンク切れ0本」を確認して、安心しかけた ── 「0本」で安心しかけた記録
- 仕組みは在った。運ぶ気もあった。探す形が違っていた ── 探す形が違っていた記録
解説記事では、公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移す（この記事の手順の解説）のほか、削除したページに何を返すか（移したあとの元のアドレスが何を返すかを決める項目）も、あわせて読める。
出典
すべて2026年10月23日に開いた。OWASPのガイドは、最後の更新が2026年9月23日（GitHubの履歴）で、Apacheの「Security Tips」の更新日は2026年9月29日、curlのマニュアルは2026年10月22日、MSYS2の文書は2026年10月17日だった（いずれも、サーバーが返した更新日。時刻は世界標準時）。
- OWASP Web Security Testing Guide: Review Old Backup and Unreferenced Files for Sensitive Information（WSTG-CONF-04）
- Apache HTTP Server 2.4: Security Tips
- Apache HTTP Server 2.4: core（Files ディレクティブなど）
- apache/httpd: docs/conf/httpd.conf.in（設定の雛形）
- curl: man page
- MSYS2: Filesystem Paths
開けなかったページ: MITREのCWE-530は、この記事を書いた時間には開けなかったので、根拠にしていない。
