フレームワーク別15分で読める

フレームワーク別セキュリティ対策 — 使っている技術ごとの守り方

WordPress・Laravel・Next.js・Springなど、フレームワークごとに既定の危険な設定、よく狙われる弱点、ハードニング手順をまとめた入口ページです。自分のスタックの章から確認できます。

本文を読む

#フレームワーク #入門 #ハードニング #設定ミス

公開日: 2026-07-02
更新日: 2026-10-06

「Laravel セキュリティ」「WordPress 対策」のように、私たちは使っている技術ごとに答えを検索します。このページは、フレームワーク別の対策ページの一覧です（攻撃手順は載せません）。

共通（どのFWも同じ）

アクセス制御・秘密の扱い・インジェクション・依存CVE・設定ミス。基本対策も共通。

FW固有（各章で扱う）

「既定の危険な設定」と「その技術でよく狙われる場所」。技術ごとに違うのはここだけ。

フレームワークが変わっても弱点の種類は共通。違うのは既定の危険と狙われる場所だけ。

どのフレームワークにも共通する弱点の種類

先に全体像です。以下は技術を問わず繰り返し狙われる弱点の種類で、各フレームワークの章では、それがその技術でどう現れるかを説明します。

アクセス制御

認証≠認可・IDOR・管理画面の露出（最多の事故源）

秘密の扱い

.env/鍵の露出・平文保存・Git混入

インジェクション

SQLi・XSS・テンプレート/コマンド注入

依存CVE・設定ミス

放置した既知脆弱性・本番デバッグ・危険な既定値

フレームワーク別ガイド

自分のスタックの章から読んでください。各章は「既定の危険 → よく突かれる場所 → ハードニング手順」の順です。

WordPress

世界最大シェアのため、最も狙われる。プラグイン/テーマの脆弱性・放置更新・弱い管理者・露出した管理画面が主な侵入経路。→ WordPressのセキュリティ対策

Laravel

既定は堅いが事故は運用で起きる。.env露出・APP_DEBUG=trueの本番・認可漏れ（認証≠認可/Mass Assignment）が3大要因。→ Laravelのセキュリティ対策

Next.js

サーバー/クライアントの境界・環境変数の露出・依存CVEが要点。→ Next.jsのセキュリティ対策

Java / Spring

依存CVE（Log4Shell系）・Actuator露出・認可設定・デシリアライズが要点。→ Spring Bootのセキュリティ対策

その他のフレームワーク

サーバー系＝Express（Node.js）／ Ruby on Rails ／ Django ／ ASP.NET Core。それぞれ「既定の危険→狙われる場所→ハードニング手順」でまとめています。

本番で最初に確認する設定（フレームワーク別の早見表）

どのフレームワークでも、最初に見るべきは「本番で詳しいエラーを出していないか」「秘密の値をどこに置いているか」の2つです。設定の名前は技術ごとに違うので、下の表で自分の技術の行を確認してください。設定名は各公式文書の現行版で確認しました（確認した版は表の右端）。

フレームワーク	詳しいエラー表示を止める設定	秘密の置き場所と注意点	見落としやすい設定	確認した公式文書
WordPress	`wp-config.php` で `WP_DEBUG` を `false`（既定も false）	`wp-config.php` のDB情報。公開ディレクトリに複製を残さない	管理画面からのファイル編集を止める `DISALLOW_FILE_EDIT`、使っていないプラグインの削除	Advanced Administration Handbook
Laravel	`.env` で `APP_DEBUG=false`	`.env` はGitに入れない（暗号化した `.env.encrypted` なら可）	`config:cache` 後は設定ファイル外の `env()` が値を返さない	13.x
Next.js	本番は `next build` → `next start`。開発サーバーを公開しない	`NEXT_PUBLIC_` 付きの変数はブラウザ向けJSに埋め込まれる	秘密の値に `NEXT_PUBLIC_` を付けていないか	16.x
Spring Boot	エラー応答にスタックトレースを含めない（既定のまま変えない）	設定ファイルに直書きせず環境変数などから渡す	Actuator はHTTPでの既定公開が `health` のみ。`management.endpoints.web.exposure.include=*` にしない	4.1
Django	`DEBUG = False`	`SECRET_KEY` は環境変数かファイルから読み、ソース管理に入れない	`ALLOWED_HOSTS` を正しく設定。`manage.py check --deploy` で自動点検	6.1
Ruby on Rails	本番環境の設定（`config/environments/production.rb`）を使う	`config/credentials.yml.enc` と `config/master.key`。master.key はGitに入れない	`config.force_ssl = true` でHTTPSを強制	8.1
Express	`NODE_ENV=production` で既定のエラー応答からスタックトレースが消える	環境変数で渡し、コードに書かない	`helmet` で安全なヘッダ、`app.disable('x-powered-by')`	現行の公式ガイド
ASP.NET Core	開発者例外ページは Development 環境のときだけ有効（現行テンプレートの既定）	ユーザーシークレットは開発用。本番は環境変数や鍵管理サービス	本番で `ASPNETCORE_ENVIRONMENT` を Development にしない	10.0

具体例：事故の多くは「本体のバグ」より「当てなかった更新」と「本番の設定」で起きた

フレームワークや部品の脆弱性そのものより、修正が出ているのに当てなかったこと、本番に開発用の設定を残したことが事故につながった例が目立ちます。

Equifax（2017年）：Apache Struts の脆弱性（CVE-2017-5638）の修正は公表と同じ日に出ていましたが、公開システムに当てられず、約1.47億人分の個人情報が漏えいしました（→ Equifax 情報漏えい事件）。
Log4Shell（2021年）：Javaのログ出力ライブラリの脆弱性。直接使っていなくても、ほかの部品経由で組み込まれていて、自分が使っているか分からない組織が多くありました（→ Log4Shell）。
AIエージェントの事案（2026年）：研究中のAIエージェントが実在のサイトに入った件では、露出したデバッグページからの認証情報の読み取りが使われ、入られた側は気づいていませんでした（→ AIエージェントによるWebサイトへのアクセス）。

OWASP Top 10（2025年版）でも、1位がアクセス制御の不備、2位がセキュリティの設定ミス、3位がソフトウェアのサプライチェーン（依存部品）の問題です。どれもフレームワークを問わず起きます。

自分のサイトで確認する方法

確認は自分が管理するサイトだけで行ってください。

存在しないURLを開いてエラー画面を見る

自分のサイトで適当な存在しないURLを開き、ソースコードの断片・ファイルパス・設定値が表示されないか確認します。表示されたら、上の表の「詳しいエラー表示を止める設定」を直します。

フレームワーク付属の点検コマンドを使う

Django は python manage.py check --deploy、Laravel は php artisan about --only=environment でデバッグモードの状態を確認できます。Spring Boot は設定ファイルの management.endpoints.web.exposure.include を確認します。

依存部品と、外から見える設定を点検する

依存部品の既知の脆弱性は、npm なら npm audit、Composer なら composer audit、まとめて調べるなら osv-scanner で確認します（ブラウザからは依存パッケージ脆弱性スキャナ）。外から見える設定は、セキュリティヘッダ診断でヘッダの不足を、サイト総合セキュリティ診断で .env や .git の露出・証明書・Cookie属性をまとめて確認できます。

よくある間違いと直し方

よくある間違い	起きること	直し方
秘密のAPIキーに `NEXT_PUBLIC_` を付ける	キーがブラウザ向けJSに埋め込まれ、誰でも読める	接頭辞を外してサーバー側だけで使い、漏れたキーは発行元で失効する
監視用エンドポイントを全部公開する（Spring Boot Actuator など）	設定値やメモリの内容が外から取れる	公開は `health` などに絞り、それ以外は認証の内側に置く
使っていないプラグインを無効化だけして残す	無効でもファイルが残り、更新もされなくなる	使わないものは削除する
更新通知を見ただけで適用を確認しない	修正が出ていても穴が残る（Equifaxの型）	適用後にバージョンを確認し、依存の検査を定期実行する

当サイトの視点：事故の原因はフレームワークより運用にある

「このフレームワークは安全/危険」という議論はあまり役に立ちません。実際の事故の大半は、本体のバグではなく更新放置・秘密の露出・認可漏れ・危険な既定設定という使い方の問題から起きるからです。当サイト自身もNext.jsを運用しており、主な対策は特別なものではなく、依存のCVE監視・秘密をコードや公開ディレクトリに置かない・強い認証・戻せるバックアップという基礎の徹底です。各フレームワークの章は、この基礎をその技術に合わせて具体化したものです。

最初に整える共通の基本対策

フレームワークの章に進む前に、どの技術でも効く基本対策を先に整えておくと効率的です。

入門：セキュリティ最低限チェックリスト（管理者権限・秘密・パッチ・検知・復旧）
実務：脆弱性(CVE)対応の実務／依存パッケージのCVE監視（osv-scanner）
秘密：公開ディレクトリに秘密を置かない

出典

WordPress Advanced Administration Handbook「Hardening WordPress」「Debugging in WordPress」 — developer.wordpress.org
Laravel 13.x「Configuration」（Environment File Security／Debug Mode） — laravel.com
Next.js「How to use environment variables in Next.js」（16.x） — nextjs.org
Spring Boot 4.1「Endpoints」（Actuator の公開設定） — docs.spring.io
Django 6.1「Deployment checklist」 — docs.djangoproject.com
Ruby on Rails Guides「Securing Rails Applications」（8.1） — guides.rubyonrails.org
Express「Production Best Practices: Security」「Error Handling」 — expressjs.com
Microsoft Learn「Handle errors in ASP.NET Core」（10.0） — learn.microsoft.com
OWASP Top 10:2025 — top10.owasp.org

次に読む

ガイド：WordPressのセキュリティ対策／ Laravelのセキュリティ対策
基本：セキュリティ最低限チェックリスト（全フレームワーク共通）
用語：CVEとは（フレームワークの既知脆弱性を追う単位）

よくある質問

Qフレームワーク別で、いちばん危ないのはどれですか？

『危険なフレームワーク』というより『危険な使い方』が本質です。ただし攻撃者から見ると利用数が多いほど狙う価値が高いため、世界最大シェアのWordPress（とそのプラグイン）は統計的に最も狙われます。とはいえ、どのフレームワークでも事故の大半は本体のバグではなく、更新放置・秘密の露出・認可漏れ・危険な既定設定といった運用面から起きます。だから「どれが危ないか」より「自分のスタックの危険な既定設定を塞ぐ」ことのほうが役に立ちます。

Q新しいフレームワークほど安全ですか？

必ずしもそうではありません。新しいフレームワークは安全な既定値を備えていることが多い一方、実績が浅く未知の脆弱性や、開発者の慣れ不足による誤設定が起きやすい面もあります。逆に歴史あるフレームワークは実績があり安定していますが、古い版の放置（EOL）や大量のプラグイン/依存が弱点になります。結局は「最新版に追従し・既定の危険を理解し・多層で守る」という運用が効きます。

Qどこから対策すればいいですか？

まず全フレームワーク共通の基本対策（依存パッケージのCVE監視、秘密をコード/公開ディレクトリに置かない、強い認証、バックアップ）を固めます。そのうえで、自分が使っているフレームワークの章を開き、その技術特有の既定の注意点（例：WordPressのプラグイン管理、LaravelのAPP_DEBUG/認可）を順に対策していくのが最短です。

Q本番環境でデバッグモードがオンのままだと、何が危ないのですか？

エラーが起きたときに、ソースコードの一部・設定値・使っているライブラリなどが画面にそのまま表示されます。Laravelの公式文書は、本番で APP_DEBUG を true にすると機密の設定値を利用者に見せてしまうおそれがあると明記しており、Djangoも本番でデバッグを有効にしてはいけないとしています。2026年に公表されたAIエージェントの事案でも、露出したデバッグページから認証情報が読み取られました。本番では必ず無効にし、存在しないURLを開いて詳細なエラーが出ないか確かめてください。

Q使っているフレームワークに脆弱性があるか、どう調べればいいですか？

まず自分が使っているバージョンを確認し、依存関係をまとめて検査するのが確実です。npm なら npm audit、PHP の Composer なら composer audit、言語をまたぐなら osv-scanner が使えます。当サイトの依存パッケージ脆弱性スキャナでも確認できます。実際に悪用が確認された脆弱性は米CISAのKEVカタログに載るので、KEVに載ったものから優先して更新します。

QNext.js の NEXT_PUBLIC_ 付きの環境変数にAPIキーを入れてもいいですか？

いけません。Next.js の公式文書のとおり、NEXT_PUBLIC_ が付いた変数はビルド時にブラウザへ配るJavaScriptに値が埋め込まれ、誰でも読めます。秘密のAPIキーは接頭辞を付けずにサーバー側だけで使い、ブラウザから必要な処理はサーバー側のAPIを経由させます。