「ファイル名のところに ../ を混ぜると、サーバーの奥にある .env まで読めてしまった」——それがパストラバーサルです。仕組みと確実な防ぎ方を解説します（攻撃手順は載せません）。
どこに出るか
「利用者の入力でファイルを選ぶ」場所すべてが候補です。
| 機能 | 危ない使い方 |
|---|---|
| ダウンロード/プレビュー | ?file= にファイル名をそのまま使う |
| 画像/添付の表示 | パスの一部をURLパラメータから組み立てる |
| アップロード | 保存先パスにユーザー指定の名前を使う（書き込み型・最も危険） |
| テンプレート/言語ファイル読込 | ?lang= 等でファイルを動的に選ぶ |
なぜ成立するか（仕組み）
../ は「一つ上の階層へ」を意味します。アプリが 公開フォルダ + 利用者入力 をそのまま連結してファイルを開くと、../ を重ねた入力で公開フォルダの外へ“歩いて”出られます。
読み取りなら情報漏えい、書き込み（アップロード）なら任意の場所にファイルを置かれ、RCE につながることもあります。
防御：入力をパスにしない＋基準内に閉じ込める
利用者入力を生のファイルパスにしない（最重要）
公開するファイルは ID→実ファイルの対応表（許可リスト）で引く。利用者が渡すのは「3番」「invoice」等の識別子だけにし、実パスはサーバーが決める。
正規化してから“基準ディレクトリの内側か”を必ず確認
言語標準のパス正規化（resolve/realpath 相当）で絶対パス化し、それが許可した基準ディレクトリで始まっているかを検証。外なら拒否。../ の単純な文字列除去はエンコード回避があるため不可。
アプリを最小権限で動かす
アプリ実行ユーザーが読めるファイルを業務に必要な範囲へ絞る。万一抜け出されても、そもそも読めなければ被害が出ない。
“出してはいけない物”を公開ルートの外へ
.env・.git・鍵・バックアップは、そもそもWebルートやアップロードフォルダに置かない。配置で攻撃面を消す。
当サイトの視点：配置ミスと地続き。塞ぐ順番を間違えない
パストラバーサルは、.env 公開の事故と地続きです。どちらも「本来Webから届くべきでない物に、Web経由で届いてしまう」問題。応急処置（ヘッダや単純フィルタ）で“症状”を隠しても、コードと配置が直っていなければ別経路で抜けます。順番は①入力をパスに使わないコード ②基準ディレクトリ内チェック ③そもそも秘密を公開ルート外へ。共有レンタルサーバーでの安全な配置も合わせて読むと、根本対処の形が見えます。
次に読む
- 事故：.env を丸ごと公開してしまった事故
- 対策：レンタルサーバーでの .env 保護 / 用語：RCE とは
よくある質問
Qパストラバーサルで何が漏れる？
本来そのアプリが触らせるべきでないファイルです。代表例は .env（DB認証・APIキー）、設定ファイル、秘密鍵、ソースコード、OSの /etc 配下など。読み取りだけでなく、アップロード先のパス指定に悪用されると任意の場所へ書き込まれ、RCE（任意コード実行）に発展することもあります。
Q一番の防御は？
『利用者の入力を、そのままファイルパスに使わない』ことです。どうしても使うなら、許可リスト（IDやファイル名の固定セット）に変換し、ライブラリでパスを正規化したうえで『基準ディレクトリの内側に収まっているか』を必ず確認します。拡張子チェックや ../ の単純除去だけでは回避されます。
Q.htaccess やヘッダで塞げばいい？
それは“出してはいけないファイルが公開ディレクトリにある”という別問題への応急処置です。根本は『アプリ本体・.env・.git を公開ルートの外に置く』配置の是正と、入力をパスに使わないコードです。応急処置と根本対処は別作業です。