本文へスキップ
>_ITDITDセキュリティ対策プラットフォーム

技術別対策

公開ディレクトリに秘密ファイルを置き忘れていないか:webrootの棚卸し

トークンや認証情報のファイルが、Web公開ディレクトリ(webroot)に置き忘れられていないか。URLを直接叩けば誰でも取得できてしまう典型ミスと、共通テンプレート由来で全サイトに同じ穴が横展開する罠、そして自分のサーバーを棚卸しして塞ぐ手順を、当サイトの運用視点で解説します。

公開日 2026-06-11 更新日 2026-06-11 9分で読める

対象:レンタル/共用サーバーやVPSで、複数のサイトを公開ディレクトリ(public/public_html/htdocs/ 等)にデプロイして運用している人。ここでは攻撃手順は扱わず、自分のサーバーを棚卸しして塞ぐことだけを扱います。.envそのものの守り方は 共用サーバーでの.env保護 も参照。

当サイトの視点:『置き場所』はアクセス制御そのもの

秘密が漏れる原因は、難しい攻撃よりも置き場所の事故が多いです。webrootは『誰でもURLで取りに来られる場所』。そこに秘密を置いた時点で、どんなに強いパスワードのサーバーでも意味がありません。当サイトは秘密をwebrootにもgitにも置かないのを土台にしています(→ 秘密の安全な保管)。考え方はシンプルで、「公開ディレクトリ=公開棚」。棚に置くのは見られて困らない物だけです。

public/ = URLで誰でも取得可

置いてよい

画像・CSS・JS など公開アセット

置くな

.env・token.json・.sql.git.bak

アプリのルートより上 = 配信されない

ここに置く

秘密・トークン・認証情報・バックアップ。権限600(所有者だけ読める)。URLからは到達できない。

公開ディレクトリ=公開棚。秘密はその外へ(配信されない場所・権限600)。

なぜ「公開ディレクトリの置き忘れ」が起きるのか

実際にありがちなのは、便利のために置いたファイルや、ひな形に最初から入っていたファイルが、そのまま公開され続けるパターンです。

URL一発
webrootのファイルは誰でも取得可
年単位
気づかず放置されがち
全サイト
テンプレ由来は横展開する
即失効
漏れたら『漏れた前提』で対応

たとえば、外部サービス連携のために作ったアクセストークン入りのJSONが、public/ の下に置かれたまま長期間放置される——しかもそれが共通テンプレート由来だと、同じファイルが複数サイトに同じ場所でコピーされ、全部が同じ穴を抱えます。1サイトを直しても、他が空いていれば意味がありません。同様に危ないのは、.env・データベースのバックアップ(.sql)・.git ディレクトリ・エディタのバックアップ(*.bak)・ショートカット等の置き忘れです(関連:パストラバーサル.envが丸ごと公開された話)。

自分のサーバーを棚卸しする

まず「自分の公開ディレクトリに、秘密らしきファイルが無いか」を機械的に洗い出します。これは自分の資産の点検であって、他者のサイトを覗く行為ではありません。

1

公開ディレクトリ配下の秘密らしきファイルを探索

自分のホーム配下で、public/ 等に紛れた秘密候補(トークン/認証情報のJSON・.env・鍵・ショートカット)を洗い出す。
2

横展開を前提に『全台・全サイト』へ広げる

同じひな形から作ったサイトは同じ場所に同じ物がある前提で、全ホスト・全サイトに同じ点検をかける。1件は氷山の一角。
3

本当に公開が必要かを1つずつ判断

出てきたファイルが『公開してよい物』か『秘密』かを仕分ける。秘密なら次節の手順で除去・失効・移動。
# 自分のサーバーの公開ディレクトリ配下を棚卸し(自分の資産の点検)
find ~ -path '*/public/*' \( -iname '*token*.json' -o -iname '*credential*.json' \
      -o -iname '*.bak' -o -iname '*.sql' -o -iname '.env*' \) 2>/dev/null
# .git ディレクトリの公開も危険
find ~ -path '*/public/*/.git' -maxdepth 8 2>/dev/null

見つけたときの対応

見つけたら、除去・失効・移動の3点をセットで行います。どれか欠けると塞ぎきれません。

1

webrootから除去し、URLで取れない状態に

該当ファイルを公開ディレクトリの外へ移すか削除し、URLを叩いても404になることを確認する。
2

漏れた可能性のある鍵・トークンは失効/再発行

『たぶん大丈夫』で残さない。露出していた以上、漏れた前提で該当トークン・鍵をリフレッシュまたは失効させる。
3

秘密はwebrootの外+権限600へ

今後は秘密を公開ディレクトリの外(アプリのルートより上など)に置き、権限を600(所有者だけが読める)にする。設定で機微な拡張子の配信を拒否できるなら併用する。

やりがちな配置(危険)

  • 連携用トークンのJSONを public/ に置く
  • ひな形に入っていた秘密ファイルをそのまま公開
  • バックアップ(.sql/.bak)や .git を公開下に放置
  • 1サイトだけ直して『対応完了』

正しい配置

  • 公開ディレクトリには公開してよい物だけ
  • 秘密はwebrootの外+権限600
  • 機微な拡張子は配信を拒否(設定で deny)
  • 1件見つけたら全台・全サイトを棚卸し

『公開して良い物だけ置く』を運用ルールに

個別の対処より、ルール化が効きます。公開ディレクトリ=公開棚と決め、秘密・バックアップ・バージョン管理データ(.git)・設定ファイルは原則そこに置かない。ひな形(テンプレート)を更新するときは、ひな形側から秘密を抜く——そうしないと、次に量産するサイトにも同じ穴がコピーされ続けます。

当サイトはどうしているか

当サイトは、秘密(鍵・トークン・接続情報)を公開ディレクトリにもコードのリポジトリにも置かないのを土台にしています。デプロイ成果物に含めるのはビルド済みの公開アセットだけで、秘密は実行環境の環境変数として、配信されない場所に保持します。理由は、この記事の事故クラスが「1つの置き忘れが、URL一発で全部漏れる」典型だからです。置き場所そのものをアクセス制御として設計し、棚卸しは 脆弱性対応の棚卸し と同じタイミングで一緒に回しています。

次に読む

よくある質問

Q公開ディレクトリにファイルを置くと何が危険ですか?
A

Web公開ディレクトリ(webroot=public/ や public_html/ など)に置いたファイルは、URLを直接叩けば誰でも取得できます。トークン・認証情報のJSON・.env・バックアップ・鍵ファイルなどを置き忘れると、人が気づかないうちに取得され、即・実害につながります。公開ディレクトリには『公開してよい物だけ』を置くのが原則です。

Q1サイトで見つかったら、他も点検すべきですか?
A

すべきです。共通テンプレートやひな形からサイトを量産していると、同じ置き忘れが全サイトに横展開していることが多いからです。1か所で見つけたら、同じ由来の全サイト・全ホストを一括点検してください。

Q見つけたらどう対応しますか?
A

①該当ファイルをwebrootから除去し、URLで取得できない(404)状態にする②漏れた可能性のあるトークン・鍵はリフレッシュ/失効させる(漏れた前提で動く)③秘密は今後webrootの外に置き、権限を600(所有者のみ読める)にする。この3点をセットで行います。