フレームワーク別セキュリティ
WordPress・Laravel・Next.js・Spring など、使っているフレームワークごとに『既定の危険・よく突かれる弱点・ハードニング手順』をまとめた実践的な防御ガイド。
対応フレームワーク
PHP
WordPressは世界最大シェア=統計的に最大の標的。事故の入口は本体のバグより『プラグイン/テーマの脆弱性・放置更新・弱い/使い回しの管理者・露出した管理画面(wp-admin/xmlrpc/REST列挙)』。守り=本体とプラグインの更新を自動化・使わないプラグイン/テーマは削除・管理者に強いパスワード+2FA・管理画面の露出とログイン試行を絞る・改ざん検知とオフラインバックアップ。
LaravelLaravelは既定値が比較的安全な一方、事故のほとんどは運用面から起きる。三大落とし穴=(1).envや秘密ファイルが公開ディレクトリ(public)からURLで取得できる、(2)本番でAPP_DEBUG=trueのまま=エラー画面に環境変数・接続情報が露出、(3)認可漏れ(ログイン=認証はあるが所有者スコープの認可が無い/Mass Assignmentで想定外フィールド上書き)。守り=秘密をpublicの外+権限600・本番はdebug off+設定キャッシュ・Policy/Gateで認可・$fillableを明示。
JavaScript / Node
Next.jsは既定が安全寄りだが、事故は『サーバーとクライアントの境界』で起きる。三大=(1)環境変数の露出(NEXT_PUBLIC_ の誤用やサーバー専用の秘密をクライアントへ渡す)(2)Server Actions / Route Handlers の認可漏れ(認証はあるが所有者スコープが無い)(3)依存パッケージの既知CVE(フレームワーク本体のRCEを含む・実稼働版で判定し即パッチ)。守り=秘密はサーバー限定・境界を意識・Server Actionsで認可を毎回確認・依存CVEを機械監視。
ExpressExpressは最小主義=既定ではセキュリティ機能をほぼ持たない。ゆえに守りは開発者が『自分で足す』。要点=(1)セキュリティヘッダ(helmet相当)(2)入力の検証とサニタイズ(3)認証だけでなく所有者スコープの認可(4)レート制限(総当り・DoS対策)(5)依存パッケージ(npm)のCVE監視+即パッチ。加えて外部URL取得はSSRF対策、秘密はenvでコード非混入。最小の自由と引き換えに、防御の責任も自分にある。