対象：Laravelでアプリを運営している人。ここでは攻撃手順は扱わず、運用で起きる三大事故と、その塞ぎ方を解説します。全体像は フレームワーク別セキュリティの入口 も参照。
三大落とし穴（既定が守ってくれない場所）
Laravelのエスケープや認証は優秀ですが、次の3つは開発者が自分で塞ぐ領域です。
① 秘密の公開露出
.env・バックアップ・鍵が public/ からURL取得可能に。設置ミスで即漏えい。
② 本番のデバッグ有効
APP_DEBUG=true でエラー画面に環境変数・接続情報が露出。故意のエラーで抜かれる。
③ 認可漏れ
認証はあるが所有者スコープ無し（IDOR）／Mass Assignmentで is_admin 等を上書き。
塞ぎ方（3ステップ）
秘密を公開ディレクトリの外へ（権限600）
.env をドキュメントルート外に置く構成だが、バックアップ・エクスポート・鍵ファイルを誤って public/ に置かない。秘密はアプリルートの外に、権限600（所有者のみ）。（→ 公開ディレクトリに秘密を置かない ／ .env全公開の事例）本番はデバッグ無効＋設定キャッシュ
APP_DEBUG=false・APP_ENV=production を確実に。設定キャッシュで反映を固定し、詳細エラーの外部露出を止める。デプロイ手順に組み込み、毎回確認する。認可を作り込む（Policy/Gate＋$fillable）
$fillable を明示して想定外フィールドの上書きを防ぐ。（→ IDORとは）やりがち（危険）
- バックアップや鍵を
public/に置いてURL到達 - 本番を
APP_DEBUG=trueのまま運用 - 認可を作らず「ログイン＝閲覧可」
Model::create($request->all())で全フィールド受け入れ
正しい
- 秘密はドキュメントルート外・権限600
- 本番 debug無効＋設定キャッシュ
- Policy/Gateで所有者スコープ
$fillableを明示してMass Assignment遮断
当サイトの視点：堅いのは既定まで、認可は自分の責任
Laravelは良い既定を多く持ちますが、「誰が・何を・してよいか」という認可だけは、アプリ固有なのでフレームワークが自動で守れません。当サイトが繰り返し見てきた事故も、SQLiやXSSより「認証はあるのに所有者チェックが無い」型が多い。だから守りの重心は、派手な設定より「取得・更新のたびに所有者でスコープする」地味な作り込みにあります。あわせて秘密を公開面から外し、本番のデバッグを切る——この3つで、Laravelの実運用事故の大半は防げます。
次に読む
- 入口：フレームワーク別セキュリティ（入口） ／ WordPressのセキュリティ対策
- 秘密：公開ディレクトリに秘密を置かない ／ 事例：.env全公開の事例
- 認可：IDORとは ／ 実務：脆弱性(CVE)対応の実務
よくある質問
QLaravelは安全なフレームワークですか？
Laravelはエスケープや認証など安全な既定を多く備え、素の状態では比較的堅いフレームワークです。しかし“既定が安全”と“運用が安全”は別問題で、実際の事故は本体のバグでなく設定・運用から起きます。とくに.envや秘密の露出、本番でのデバッグ有効、認可の作り込み不足は、フレームワークが守ってくれない領域です。既定に頼りきらず、この3点を自分で塞ぐ必要があります。
QAPP_DEBUG=true のまま本番に出すと何が危険ですか？
デバッグが有効だと、エラー発生時の画面に、スタックトレースだけでなく環境変数や接続情報など内部の機密が表示され得ます。攻撃者はわざとエラーを起こして情報を引き出せます。本番では必ず APP_DEBUG=false にし、設定をキャッシュ（config cache）して確実に反映させてください。あわせて詳細エラーの外部露出も止めます。
Q『ログインしていれば見られる』状態はなぜ危険ですか？
それは“認証”はあるが“認可”が無い状態です。ログイン済みでも、そのデータが本当にそのユーザーのものかを user_id 等でスコープしていないと、URLのIDを差し替えるだけで他人のデータが見えてしまいます（IDOR）。Laravelでは Policy / Gate で所有者チェックを実装し、Mass Assignment は $fillable を明示して想定外フィールドの上書きを防ぎます。