WEBサイト
2026年10月30日の午後、当サイトの公開の場所（Webサーバーが外へ返すフォルダ）の中に、Basic認証のパスワードのファイルが9本あった。外から開くと、9本とも403（読めない）で、中身は見えなかった。それでも、この日のうちに、9本すべてを公開の場所の外へ移した。公開の場所に残ったパスワードのファイルは、いま0本だ。
パスワードのファイルは、ログインの「答え合わせ」に使う表だ。Apacheの文書は、この表を、Webサーバーが外へ返す範囲の外に置くよう書いている。読めなかった9本は、その置き場所の約束を守っていなかったことになる。それでも403が返っていたのは、置き場所のおかげではなく、ほかの1つの決まりのおかげだった。この記事は、そのことと、移すときに何を測ったか、見つけたきっかけを書く。
読み終えたら、担当サイトで「パスワードのファイルがどこに在るか」「外から読めないのは何のおかげか」を確かめ、移すときに何を測ればよいかが分かるようにしたい。安全のため、フォルダの名前、ファイルの置き場所、サーバーの構成、認証の利用者名、パスワードの値や形は書かない。書くのは、本数、日付、応答の番号、確かめ方、順番までだ。
何をしたか ── 3行で、そしてきっかけ
3行で言うと
- 公開の場所の中に、Basic認証のパスワードのファイルが9本あった（いちばん古いものは2024年10月の日付）。外から開くと9本とも403だった。
- 9本のうち、使っていたのは5本、使っていなかったのは4本だった。使っていた5本は、公開の場所の外へ写し、設定の指す先を新しい置き場に書き換えた。使っていなかった4本は、消さずに「使わないものの置き場」へ移した。
- 移す前と後で、認証なし・違う認証・正しい認証の応答（401・401・200）が同じことを確かめ、公開の場所の中の本数を数え直して、9本から0本になったことを確かめた。名前で外から開いたときの403は、置き場所の証拠にならない。
きっかけは、仲間への返事に書いた「自分のまずい点」
きっかけは、チームの仲間からの質問だった。「サイトの情報（ホストの名前やパスワードなど）を、どう管理していますか」という内容だ。返事を書きながら、当サイトのやり方を1つずつ思い出した。その中に、自分でも「これはまずい」と思う点があった。パスワードのファイルを、公開の場所の中に置いている、ということだ。
返事には、自分のやり方のまずい点として、パスワードのファイルを公開の場所の中に置いていることを、正直に書いた。書いた瞬間に、その一文は、書いた本人に宿題を出すことになる。ナミオさんの方針は、見つけたものはその場で直す、だ。だから、返事を書いたその日のうちに、数えて、移すことにした。
同じ型の話を、過去にも書いている。記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だったでは、記事のチェック項目を書く途中で自分のサイトへ当てたら、自分のサーバーが対象だった。今回は、仲間への返事が、自分に当てるきっかけになった。人に説明しようとすると、自分のやり方の穴が見えることがある。
パスワードのファイルとは何か ── 中身と、置き場所についての文書の書き方
Basic認証は、パスワードのファイルを読んで答え合わせをする
Basic認証は、ページを開こうとしたときにブラウザが出す、利用者名とパスワードを入れる小さな窓のことだ。入れた内容が正しいかどうかを、Webサーバーは、あらかじめ用意された1つのファイルを読んで調べる。これがパスワードのファイルだ。設定には、このファイルの場所を指す行がある。Apacheでは、その指定はAuthUserFileと呼ばれる。AuthUserFileの説明は、ファイルの中身をこう書いている。
"Each line of the user file contains a username followed by a colon, followed by the encrypted password."
（日本語訳: 利用者のファイルの各行には、利用者名、コロン、暗号化されたパスワードが、この順に入っている。）
つまり、1行に1人ぶん、利用者名と、パスワードを変換した値が入っている。パスワードそのものが書いてあるわけではない。この表は、htpasswdというApacheに付いてくる道具で作る。
仕組みを手で触って見たいときは、サンプルの文字で試せる無料ツールがある。🔧 Apache ベーシック認証パスワード発行は、入れた文字から、パスワードのファイルに書く形の1行を作るものだ。試すのは、本物のパスワードではない、サンプルの文字にしてほしい。本物のパスワードを作るときは、手元の端末で作るのが基本になる。htpasswdの文書も、パスワードを命令の行の中に書く方法は、平文のパスワードが命令の行に現れるので勧めない、と書いている。
文書は、置き場所について何と書いているか
パスワードのファイルをどこに置くかについて、Apacheの文書は、3か所で同じことを書いている。1つ目は、AuthUserFileの説明にある「Security」の項だ。
"Make sure that the AuthUserFile is stored outside the document tree of the web-server. Do not put it in the directory that it protects. Otherwise, clients may be able to download the AuthUserFile."
（日本語訳: AuthUserFileは、Webサーバーが公開する範囲（ドキュメントツリー）の外に置くこと。守る対象のフォルダの中に置いてはいけない。そうしないと、クライアントがAuthUserFileをダウンロードできてしまうことがある。）
2つ目は、htpasswdの文書の「Security Considerations」にある。
"Web password files such as those managed by htpasswd should not be within the Web server's URI space -- that is, they should not be fetchable with a browser."
（日本語訳: htpasswdで管理するようなWebのパスワードのファイルは、Webサーバーが返すURLの範囲の中に置いてはいけない。つまり、ブラウザで取り出せてはいけない。）
3つ目は、Basic認証の入門にあたる認証の使い方の文書だ。
"This file should be placed somewhere not accessible from the web. This is so that folks cannot download the password file."
（日本語訳: このファイルは、Webから届かない場所に置くこと。人がパスワードのファイルをダウンロードできないようにするためだ。）
3つとも、言っていることは同じだ。外から取り出せる場所に置かない。当サイトの9本は、この約束に反する置き場所にあった。ただし、文書は「置いてはいけない」と書くだけで、置いてしまったらどうなるかは、サーバーの設定しだいだ。
数えた結果 ── 9本あって、使っていたのは5本だった
本数と、外からの応答
公開の場所の中を探して、パスワードのファイルを数えた。当サイトと、同じサーバーにある親のサイトの両方を合わせて、9本あった。いちばん古いものは、2024年10月の日付だった。最初の数え方では、親のサイトの確認用のサイトにある、使っていた1本を見落とし、8本と数えていた。あとで気づいて、同じ手で外へ移した。9本を、使っていたか、使っていなかったかで分け、外から1本ずつ要求して状態コードだけを見た。
| 区分 | 本数 | 外から開いた応答 | どう扱ったか |
|---|---|---|---|
| 使っていた: 確認用のサイト（test）全体を守るもの | 1本 | 403 | 公開の外へ写し、設定を書き換えた |
| 使っていた: 本番の下の階層の3か所を守るもの | 3本 | 403 | 公開の外へ写し、設定を書き換えた |
| 使っていた: 親のサイトの確認用のサイトを守るもの（最初の数え方で見落とした） | 1本 | 403 | 公開の外へ写し、設定を書き換えた |
| 使っていなかった: 設定の認証の行が、#で止めてあったもの（本番と親のサイト） | 2本 | 403 | 消さずに、使わないものの置き場へ移した |
| 使っていなかった: どこの設定からも指されていなかったもの（test） | 2本 | 403 | 消さずに、使わないものの置き場へ移した |
| 合計 | 9本 | 9本とも403 | 公開の場所に残ったのは0本 |
使っていたかどうかは、設定の認証の行が、どのファイルを指しているかで決めた。行が生きていて、あるファイルを指していれば「使っていた」。行が#で止めてあれば、そのファイルは、いまは使われていない。どの設定からも指されていなければ、これも使われていない。
使っていなかった4本と、数字の読み方
使っていなかった4本が、なぜ残っていたのかを示す記録は、見つけられなかった。ただ、よくある形ではある。認証を一時的に止めたあと、設定の行は#で止めたまま、ファイルだけが残る。ファイルを作り直したときに、古い方がそのまま残る。確認用のサイトで試しに作ったものが、誰の持ち物か分からなくなる。控えファイルを外から確かめた日で書いた控えファイルと同じで、悪意のある誰かが置いたのではなく、丁寧に作業した人の善意の副産物だと思う。
使っていないからといって、安全なわけではない。使っていないファイルにも、誰かのパスワードを変換した値が入っているかもしれない。しかも、使っていないファイルは、見直される機会が少ない。
数字の読み方を1つ書いておく。この「9本」は、見つけられた範囲の数だ。名前を変えて置かれたパスワードのファイルは、名前で探しても見つかりにくい。控えファイルを外から確かめた日で、名前の先頭に日付を付けた写しが、既定の守りから漏れることを書いた。パスワードのファイルにも、同じ形の写しがありうる。担当サイトで数えるときは、1回の探し方で拾えるのは、その探し方の形に合う名前だけだ、と思っておくのがよい。
「外から読めない」は、何のおかげだったか
名前が「.ht」で始まるファイルは出さない、という1つの決まり
9本とも403だったのは、置き場所のおかげではなかった。名前が「.ht」で始まるファイルを、Webで出さない、という決まりが効いていたからだ。Apacheの設定の雛形には、この決まりが、次のコメントとともに書いてある。
"The following lines prevent .htaccess and .htpasswd files from being viewed by Web clients."
（日本語訳: 次の数行は、.htaccessと.htpasswdのファイルが、ウェブのクライアントから見られるのを防ぐ。）
コメントの下には、名前が「.ht」で始まるファイルへのアクセスを拒否する、という指定が書かれている。この指定は、ファイルの名前だけを見る。Filesの説明は、こう書いている。
"The directives given within this section will be applied to any object with a basename (last component of filename) matching the specified filename."
（日本語訳: この区画の中に書いた指定は、名前の最後の部分（ファイル名）が、指定した名前に合うすべての対象に適用される。）
見られているのは、ファイルの名前だけだ。フォルダの場所ではない。だから、名前が「.ht」で始まっているかぎり、公開の場所のどこに置いても、同じ決まりに当たる。当サイトの9本は、そのとおりに403を返した。置き場所が約束に反していても、読まれなかったのは、この名前の決まりが、置き場所の代わりをしていたからだ。
ただし、これは、403が置き場所の証拠にならない、ということでもある。名前が「.ht」で始まる名前なら、ファイルが存在しなくても403が返る。実際に、存在しない「.ht」で始まる名前を外から開いても403で、存在しないふつうの名前は404だった。403を見て「ファイルは外に出ていない」と読むことはできない。
その決まりは足してあるもので、効かなくなる場面がある
ただし、この決まりは、最初から在るものではない。設定に書いてあって、初めて効く。Apacheのセキュリティの手引きは、既定の動きをこう書いている。
"unless you take steps to change it, if the server can find its way to a file through normal URL mapping rules, it can serve it to clients."
（日本語訳: 変える手順を取らないかぎり、サーバーが通常のURLの対応づけの規則でそのファイルにたどり着けるなら、サーバーはそれをクライアントに返せる。）
拒否の指定がなければ、公開の場所の中のファイルは、返る。名前の決まりは、誰かが足した守りか、配布された設定の雛形に入っていた守りだ。足した人が覚えているあいだは、気にしなくても効く。人が入れ替わり、サーバーが替わると、足したことごと忘れられる。控えファイルを外から確かめた日の「403でも置かない」理由の1つ目と2つ目が、そのままパスワードのファイルにも当てはまる。
名前の決まりに頼ったままだと、次のような場面で、読めなかったものが読めるようになりうる。
- サーバーを替える。新しいサーバーの設定が、雛形のままとは限らない。
- Webサーバーの種類や、設定の書き方を替える。名前の決まりは、種類ごとに書き方が違う。
- 設定を書き直す。直すときに、その行が消えても、画面は変わらないので気づかない。
- ファイルの名前を変える。先頭に日付を付けた写しのように、名前が「.ht」で始まらなくなると、決まりに当たらない。
どれも、日常の作業で起きる。しかも、起きても、画面には何も出ない。読めるようになったことに気づくのは、外から1本ずつ叩いて確かめた日だけだ。当サイトは、近く新しいサーバーへ引っ越す。引っ越しは、上の最初の場面そのものだ。引っ越し先では、パスワードのファイルを最初から公開の外に置く、と、サーバーの作り方の決まりに書いた。
パスワードのファイルの中身は、パスワードそのものではない
「中身は変換した値なのだから、読まれても大丈夫ではないか」と思う人もいると思う。半分は合っている。パスワードそのものではなく、変換した値が入っている。htpasswdの文書は、変換に使える方式がいくつかあり、その中に、いまの基準では安全とは言えないものがある、と書いている。
"The SHA-1 and crypt() formats are insecure by today's standards."
（日本語訳: SHA-1とcrypt()の方式は、いまの基準では安全とは言えない。）
パスワードの形式を説明した文書は、Basic認証で使える形式を5つ挙げている。bcrypt、Apache独自のMD5、SHA1、CRYPT、平文の5つだ。そのうち、SHA1、CRYPT、平文の3つには「Insecure（安全でない）」と付いている。bcryptについては、htpasswdの文書が、現在「very secure（非常に安全）」と考えられている、と書いている。当サイトの9本が、どの形式だったかは、ここには書かない。htpasswdの文書には、変換のしかたについて、こうも書いてある。
"The crypt() and MD5 formats permute the representation by prepending a random salt string, to make dictionary attacks against the passwords more difficult."
（日本語訳: crypt()とMD5の方式は、ランダムな塩（ソルト）の文字列を前に付けて表現を変えることで、パスワードへの辞書攻撃を、より難しくしている。）
この文は、変換した値が手元で試されることを、文書が想定しているようにも読める（これは筆者の読みで、文書がそう書いているわけではない）。手に入れた人は、サーバーの外でも試せる、と考えておくのが無難だ。守りが強いかどうかは、使った方式と、パスワードの長さと複雑さで決まる。ファイルが読まれたあとでは、すでに渡った値は取り戻せない。だから、慌てて全部のパスワードを変えるより前に、そもそも読まれない場所に置く、が先になる。
移し方 ── 写す、書き換える、確かめる、古い方を移す
順番と、その理由
使っていた5本は、次の順で移した。順番には理由がある。
- 設定の認証の行を全部拾い、どのファイルを指しているかを一覧にする。使っているものと、使っていないものに分ける。
- 使っているファイルを、公開の場所の外へ写す。写す前に、中身から計算する目印（指紋。md5と呼ばれる）を控え、写した先の指紋と同じことを確かめる。
- 写した先を、Webサーバーだけが読める権限にする。
- 設定の認証の行を、新しい置き場に書き換える。
- 移す前と同じ応答の確かめ（次の章）を走らせ、結果が前と同じことを見る。公開の場所の中の本数も数え直す。
- 確かめが終わってから、古い方を「使わないものの置き場」へ移す。
写してから書き換える順にしたのは、書き換えた瞬間に、設定が指す先が実在していなければならないからだ。先に古い方を動かしてしまうと、設定が存在しないファイルを指す時間ができる。その間は、正しい利用者でも入れない。逆に、新しい置き場を先に用意しておけば、書き換えは1行の差し替えで済み、うまくいかなければ、1行を戻すだけで済む。
使っていなかった4本は、消さなかった。「使わないものの置き場」へ移し、戻し方の説明も一緒に置いた。ここで、自分の見落としがあった。移した直後の置き場は、サーバーに入れるほかの利用者が読める権限のままだった（Webからは読めない）。気づいてすぐ、その置き場の中を、持ち主だけが読める権限に直した。公開の外へ移すだけでは足りず、移した先の権限まで見る必要がある。消してしまうと戻せないが、移すだけなら戻せる。使っていなかったかどうかの判定は、設定を読んだ結果で、見落としがありうる。本当に消すかどうかは、しばらく様子を見てから決める。消すのは、確かめてからでよい。
権限の考え方と、設定を書き換えるときの注意
権限は、2つの失敗の間にある。緩すぎると、同じサーバーにいる別のアカウントや別のサイトから読めてしまう。きつすぎると、Webサーバー自身が読めなくなり、認証の判定ができない。考え方は1つで、「Webのサーバーだけが読める」にする。読み手はWebサーバーだけで、書き手は管理者だけだ。数字は、サーバーによって違うので、ここには書かない。
設定を書き換えるときは、行の指す先だけを変える。ほかの行には触らない。書き換える前に控えを取るなら、その控えも公開の場所の外に置く。控えファイルを外から確かめた日で書いたとおり、控えは、作った人が善意で公開の場所に置くと、そのまま積もる。パスワードのファイルを外へ出す作業で、設定の控えを公開の場所に作ってしまっては、元も子もない。
確かめ方 ── 401・401・200と、本数の数え直し
5つの確かめと、前後の結果
移す前と後で、3つの応答（401・401・200）と、名前で開いたときの403を確かめ、さらに公開の場所の中の本数を数え直した。応答は前と後で同じで、本数は9本から0本になった。
| 確かめ方 | 前 | 後 | 何が分かるか |
|---|---|---|---|
| 認証なしで開く | 401 | 401 | 認証が掛かったままであること |
| わざと違う利用者名とパスワードで開く（本番の下の階層3か所） | 401 | 401 | 新しい置き場のファイルを、Webサーバーが読めていること。読めなければ、401ではなくサーバー側のエラー（500）になるのがふつう |
| 正しい認証で開く（確認用のサイト全体と、本番の下の階層の1ページ） | 200 | 200 | 正しい人は、これまでどおり入れること |
| 外から、パスワードのファイルの名前で開く | 403 | 403 | 名前の決まりが残っているだけ。存在しない「.ht」で始まる名前でも403なので、ファイルが外に出ていない証拠にはならない |
| 公開の場所の中のパスワードのファイルを、数え直す | 9本 | 0本 | 本当に公開の外へ出たこと。置き場所の証拠は、これだ |
本番のトップ、解説記事の1ページ、ブログの1ページ、一覧の1ページの4か所は、前後とも200だった。
この記事の表は、状態コードと本数までだ。ブラウザで開いた画面の中身は、移した後にだけ見ていて、移す前は取っていなかったので、前後の比較にはなっていない。ブラウザで開いたときの見出しや画像、構造化データまでを、前後で同じ式で比べる方法は、控えファイルを外から確かめた日に書いた。パスワードのファイルは、認証の判定に使うだけで、ページの表示には直接関わらない。それでも、認証を掛けている場所を巻き添えにしていないかは、画面の中身まで見ておくと安心できる。
前後を比べるときは、測り方を前と同じにする。測り方を書き直すと、違いが、サイトではなく測り方の側から生まれる。応答の確かめは、前と後で、同じものを走らせた。「全部同じ答え」が出たときに、測る側を疑う、という控えファイルを外から確かめた日の考え方も、そのまま使える。
「違う認証で401」が教えてくれること
表の2行目が、この作業でいちばん役に立った。わざと違う利用者名とパスワードを送る確かめだ。Webサーバーは、送られた利用者名を、パスワードのファイルから探す。ファイルが読めれば、「見つからない」または「合わない」と判定でき、401を返す。ファイルが読めなければ、判定そのものができず、サーバー側のエラー（500のようなもの）を返すのがふつうだ。
ここで注意がある。この動きは、文書で確かめたものではなく、よくある見方だ。当サイトで、わざと読めない状態を作って500になるところまでを再現した記録は、この記事には無い。だから、断定はしない。それでも、この確かめには大きな利点がある。パスワードを知らない場所でも、できる。制作会社に納めたサイトのように、パスワードを知らされていない場所でも、「違う認証で401が返るか、500が返るか」で、置き場の読み違いを確かめられる。正しい認証での200が確かめられない相手でも、2行目の確かめだけは、できる。
test と本番がつながっていた
見つけたこと、困ること、見つけ方
設定の認証の行を全部拾って、指す先を一覧にしたとき、気づいたことがある。確認用のサイト（test）の下の階層の設定が、本番のパスワードのファイルを指していた。testと本番は、別のサイトのつもりでいた。しかし、パスワードのファイルを通して、知らないうちにつながっていた。
一般に、こうなる。
- 本番側のファイルを移すと、test側の設定が、存在しない場所を指す。test側のログインが、前触れなしに動かなくなる。
- testのつもりで直した内容が、本番にも効く。逆に、本番で直した内容が、testにも効く。
- 「確認用だから、緩くてよい」と思って作った設定が、本番の守りと同じファイルを使っている。確認用の扱いが、本番の扱いに引っ張られる。
今回は、移すときに、設定の指す先を新しい置き場に書き換えて、揃えた。このつながり自体を切って、testと本番でそれぞれ別のファイルにするかどうかは、別に考える。
こうしたつながりは、サイトごとに1つずつ見ていても気づきにくい。設定の認証の行を、サイトをまたいで全部拾い、指す先を並べて見て、初めて見える。確かめるのは、パスワードの中身ではなく、指す先の名前と場所だけでよい。
担当サイトで確かめること ── 10項目のチェックリスト
自分で確かめる10項目
担当サイトで、明日から確かめられる10項目を挙げる。設定を読むのが難しければ、制作会社やサーバーの担当に頼んでよい。
- パスワードのファイルが、何本あるか。公開の場所の中か外かを、一覧にしてもらう。
- 公開の場所の中にあるものは、自分が管理するサイトにかぎり、外から名前で要求して、状態コードだけを見る（403・404・200のどれか）。中身は取らない。403は、ファイルが在ることも、無いことも意味しない。
- 200が返ったものがあれば、そこで止める。ほかの作業より先に、担当に伝える。
- 設定の認証の行を全部拾い、それぞれが指すファイルの一覧を作る。
- 一覧のうち、使っているものと、使っていないもの（行が止めてある、どこからも指されていない）に分ける。
- 確認用のサイトと本番のあいだで、同じファイルを指している行がないか見る。
- 「外から読めないのは、何のおかげか」を担当に聞く。名前の決まりだけなのか、置き場所なのか、両方なのか。
- 移す前に、全ファイルの指紋を控える。移す先が、公開の場所の外であることを、道すじで確かめる。
- 移す前と後で、認証なし・違う認証・正しい認証の応答を同じ測り方で確かめ、公開の場所の中の本数を数え直して0になったことを確かめる。名前での要求（403）は、置き場所の証拠にならない。
- 新しく作るときは、最初から公開の外に置く、と作り方の決まりに書く。サーバーを替えるときの引き継ぎの項目にも入れる。
制作会社・サーバーの担当への聞き方と、使える無料ツール
担当サイトを制作会社や運用会社に任せている場合は、次のように聞くと、状況が分かる。
- 「パスワードのファイルは、どこにありますか。公開の場所の中ですか、外ですか」
- 「外から読めないのは、何のおかげですか。名前の決まりだけですか、置き場所ですか」
- 「サーバーを替えるとき、その守りは引き継がれますか。引き継ぎの項目に入っていますか」
- 「使っていないパスワードのファイルは、残っていませんか。残っているなら、誰のものですか」
答えが「確かめたことはない」でも、責める話ではない。確かめる日を決めるきっかけになる。控えファイルを外から確かめた日と同じで、サイトは何人もの手を通るので、誰かが悪いのではなく、確かめる仕組みが無かっただけのことが多い。
外から見える範囲を、自分が管理するサイトで点検したいときは、🔧 外からできるセキュリティ対策監査ツール（会員登録が必要）が入口になる。ただし、このツールが、パスワードのファイルを名前で探せるかどうかは、確かめていない。名前の一覧を作って、1本ずつ状態コードを見る作業は、公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移すに手順がある。
移す前後の画面を日付つきで残すなら、🔧 WEBサイトのスクリーンショット、まとめて撮っちゃおツールが使える。置き場所を決めるのが先で、パスワードを作るのは後だ。新しく作るときも、先に公開の外の置き場を決めてから作る。
見直すものを一覧にする考え方は、IPAは、外部に公開しているアプリ・利用中の外部サービス・保有データの3つを速やかに点検するよう呼びかけたの、利用者・ログの保持日数・不要なデータを一覧にして確かめる項目と、同じ向きだ。
当サイトの現在地 ── 実施したことと、これから
この記事で書いたことについて、当サイトの現在地を、正直に書く。
✅ 当サイト実施済 公開の場所の中のパスワードのファイル9本を数え、使っていた5本を公開の外へ写して設定を書き換え、使っていなかった4本を使わないものの置き場へ移した（10月30日）。最初の数え方で1本を見落とし、同じ日に移した。移した先の置き場の権限も、持ち主だけが読める形に直した。公開の場所に残ったのは0本。
✅ 当サイト実施済 移す前と後で、認証なし・違う認証・正しい認証の応答（401・401・200）を同じ測り方で確かめ、公開の場所の中の本数を数え直して9本から0本になったことを確かめた。応答は前後で同じで、本番のトップ・解説記事・ブログ・一覧の4か所も、前後とも200だった。
✅ 当サイト実施済 testと本番が、同じパスワードのファイルを指していたつながりを見つけ、移すときに、指す先を新しい置き場へ揃えた。
🔧 当サイトこれから 新しいサーバーでは、パスワードのファイルを最初から公開の外に置く。サーバーの作り方の決まりには書いた。実際に新しいサーバーを作ったら、公開の場所の中の本数を数えて、0であることを確かめる（外から名前で開いた403は、置き場所の証拠にならない）。
🔧 当サイトこれから 公開の場所に、秘密に近いファイル（パスワードのファイル、設定の控え、環境の設定ファイルなど）が増えていないかを、週に1回数える。控えファイルを外から確かめた日で書いた、控えを週に1回数える約束の続きだ。数えた結果を、誰が読むかを決めてから作る。数えるだけで、読む人がいなければ、鳴らない。
まとめ
持ち帰ってほしいことは、5つだ。
- Apacheの文書は、パスワードのファイルを、Webサーバーが返す範囲の外に置くよう、3か所で書いている。
- 当サイトの9本は、置き場所の約束に反していたが、外からは403だった。名前が「.ht」で始まるファイルを出さない、という1つの決まりのおかげだった。
- その決まりは、足してある守りで、サーバーを替える・設定を書き直す・名前を変えるで、効かなくなりうる。置き場所を決められるものは、決まり1つに預けない。
- 移すときは、写す、書き換える、確かめる、古い方を移す、の順にする。確かめは、認証なし・違う認証・正しい認証の応答を前と後で同じ測り方で行い、最後に公開の場所の中の本数を数え直す。外から名前で開いた403は、置き場所の証拠にならない。パスワードを知らない場所でも、違う認証で401が返るかを見れば、置き場の読み違いを確かめられる。
- 設定の認証の行は、サイトをまたいで全部拾って並べる。testと本番が、知らないうちにつながっていることがある。
確かめていないことも書いておく。1つ目は、9本の外に、名前を変えて置かれたパスワードのファイルがないかだ。2つ目は、ほかのサーバーや貸しサーバーの既定の設定が、Apacheの雛形のとおりかどうかだ。3つ目は、パスワードのファイルが読めない状態を作ったときに、500が返るかを、当サイトで再現していないことだ。4つ目は、使っていなかった4本を将来消したときの影響で、これはしばらく様子を見てから考える。5つ目は、testと本番のつながりを切る方法と時期で、これは別に決める。
関連 archives（連載軸として読む）
- 控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順 ── 公開の場所に残った控えを数えて外へ移した記録。今回の、パスワードのファイル版の元になった記事（10月23日）
- 記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── Apache 2.4.***を、記事を公開したその日に上げるまで ── 記事のチェック項目を、書く途中で自分のサイトへ当てた記録。今回は、仲間への返事が当てるきっかけになった
- PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法 ── 期限の日に、値と件数で確かめた記録（10月29日）
- PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録 ── 版の表示は修正の証拠にならないという話。見た目が同じでも、値で確かめる型（10月27日）
- PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録 ── 更新の順番と、更新の後に確かめることをまとめた記事（10月22日〜23日）
解説記事では、公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移す（この記事の元になった、控えの棚卸しの手順）のほか、IPAは、外部に公開しているアプリ・利用中の外部サービス・保有データの3つを速やかに点検するよう呼びかけたもあわせて読める。
出典
すべて2026年10月30日に開いた。ApacheのAuthUserFile・htpasswd・パスワードの形式の文書は2026年5月31日、Basic認証の入門は同年6月19日、Filesの説明は6月8日、セキュリティの手引きは9月29日に更新されていた（いずれも、サーバーが返した更新日。時刻は世界標準時）。設定の雛形は、GitHubで公開されているファイルを開いた（更新日はサーバーから得られなかった）。
- Apache HTTP Server 2.4: mod_authn_file（AuthUserFile の説明と Security の項）
- Apache HTTP Server 2.4: htpasswd（Security Considerations）
- Apache HTTP Server 2.4: Authentication, Authorization and Access Control
- Apache HTTP Server 2.4: core（Files ディレクティブ）
- Apache HTTP Server 2.4: Password Formats
- Apache HTTP Server 2.4: Security Tips（Protect Server Files by Default）
- apache/httpd: docs/conf/httpd.conf.in（設定の雛形）
