私はWordPressエージェンシーを運営しています。Seahawk Mediaは12,000以上のWordPressサイトをデプロイし、現在ケアプラン上で数千のサイトを保守しています。ですから、Next.js、Astro、またはNuxtで構築されたHeadlessサイトが、適切に運用されたWordPressサイトさえも物質的により安全であると言う時、それは安易な立場から書かれた議論ではありません。それはWordPressセキュリティモデルの内部で12年を費やし、現在毎週両方のアーキテクチャをデプロイしている者からの実務的な観察です。
この投稿に対する正直なフレーミング：WordPressセキュリティは管理可能です。マネージドホスト、前面のCloudflare、すべてのログインに2FA、プラグインの厳選、そして実際に注視している者がいれば、WordPressは問題ありません。プラットフォーム自体は安全でないわけではありません。ただし、そのままの状態を保つには積極的な管理が必要です。Headlessサイトはその管理を必要としません。攻撃面は構造的に異なり、その構造的な違いが議論全体です。
WordPressの攻撃面は実際にはどのように見えるのか？
リクエスト時の標準的なWordPressサイトはPHPプロセスを実行し、MySQLデータベースに接続し、プラグインコードを実行し、テーマコードを実行し、/wp-adminを公開し、/wp-login.phpを公開し、/wp-jsonのREST APIを公開し、/xmlrpc.php（多くのインストールでデフォルトで今も有効）のXML-RPCを公開し、メディアハンドラー経由でファイルアップロードを受け入れ、データベースにユーザー入力を保存します。これらの表面の各々は過去5年間で大きなCVEの原因となっています。
Seahawk Mediaで対応した最も高額なWordPressインシデントは、4つの根本原因のいずれかに遡ります：時間内にパッチされなかった既知のプラグイン脆弱性、弱い管理者パスワードに対して成功したブルートフォース攻撃（/wp-login.php宛て）、任意のファイルアップロードバグを含む廃止されたテーマ、またはメンテナーアカウント自体がハイジャックされた人気プラグインの侵害されたサプライチェーン。これらのいずれもが理論的ではありません。Yuzo Related Posts XSS、File Manager RCE、Elementor Pro権限昇格、および人気のあるフォームビルダープラグインの繰り返される脆弱性は、過去数年間の具体的な例であり、数百万のサイトに影響を与えました。
これらのすべてに対抗することはできます。私たちは毎日それを実行しています。ただし、積極的に防御する必要があります。WordPress インストールが安全になり、継続的な運用上の注意なしに安全なままである時点はありません。
ヘッドレスの攻撃対象面は実際にはどのような様子ですか?
リクエスト時に提供される静的レンダリングされた Next.js または Astro サイトは、CDN から事前構築された HTML、CSS、JavaScript ファイルを提供します。PHP プロセスはありません。データベース接続はありません。管理パネルはありません。プラグインディレクトリはありません。公開側のサイト上にファイルアップロードエンドポイントはありません。ブルートフォース攻撃を受ける /wp-login.php はありません。XML-RPC はありません。ページロードのたびにユーザー入力をデータベースに書き込むコメントフォームもありません。
コンテンツが作成される CMS(Sanity、Contentful、Supabase、Strapi、またはヘッドレス WordPress インストールのいずれであっても)は、認証された API アクセスの背後にある別のオリジンに存在します。攻撃者が CDN で提供される静的サイトを完全に侵害しても、データベースは取得できません。データレイヤーには、公開サイト上のどこにも保存されていない API 認証情報が必要です。
コンテンツチームが新しいコンテンツを公開する際、ビルドパイプラインは CMS からプルし、新しい静的ファイルをビルドし、CDN にデプロイします。ビルドは分離された環境で実行され、ライブサーバー上では実行されません。出力は新しい静的ファイルのセットです。侵害される可能性のある永続的なランタイムはありません。
2 つのアーキテクチャ間の視覚的なギャップはおおよそ以下のようなものです:
右側では、そのスタックのすべてのレイヤーは、リクエスト時のエクスプロイトが着地する場所です。左側では、リクエスト時のパスは事前レンダリングされたファイルの単一のエッジキャッシュヒットです。その構造的な違いがこの投稿全体です。
ヘッドレスモデルは構造的にどのような攻撃を排除しますか?
リクエスト時の SQL インジェクションは消えました。訪問者がページを読み込む際にデータベースクエリは発生しません。データはすでにビルド時に HTML にフェッチおよびレンダリングされていました。
リクエスト時のプラグインおよびテーマのリモートコード実行は消えました。公開側のサイト上に PHP 実行サーフェスは存在しません。ビルド時の依存関係は、以下で対処する別の質問です。
ブルートフォース認証攻撃はなくなります。公開URLに露出した管理パネルはありません。CMS認証エンドポイントは別のオリジンにあり、通常はOAuthやマジックリンク認証を使用するため、標準的なWordPressインストールで1日に3万回ブルートフォースされるユーザー名とパスワードフォームではありません。
ファイルアップロード脆弱性はなくなります。公開サイトにはアップロードエンドポイントがありません。メディアはCMS UIからCMSストレージレイヤーにアップロードされ、アセットはCDNに到達する前にサンドボックス化されたパイプラインで検証および処理されます。
ユーザー投稿コンテンツ経由のクロスサイトスクリプティングは大幅に軽減されます。コメントフォーム、問い合わせフォーム、またはユーザー投稿がランタイムデータベースに書き込まれて次のページロード時に別の訪問者に表示されるものはありません。ヘッドレスサイトのフォームは別のAPI（Netlify関数、Supabaseエッジ関数、Formspreeなどのサードパーティサービス）にポストされます。これらは独自の認証および検証レイヤーを持っています。
サーバーサイドリクエストフォージェリ、ローカルファイルインクルージョン、およびサーバーサイドランタイムに依存するOWASP Top 10の大部分のエントリは、静的レンダリングされたサイトには単に適用されません。攻撃パターンはユーザー入力に応じてコードを実行するサーバーを必要とします。そのようなサーバーは存在しません。
npmパッケージに対するサプライチェーン攻撃はどうですか？
これが正当な反論であり、真摯に検討する価値があります。Next.jsまたはAstroプロジェクトは数百のnpm依存関係を持って出荷されます。人気のあるパッケージが侵害された場合（2018年のevent-streamインシデント、2021年のua-parser-jsの侵害、2024年のPolyfill.io供給チェーン攻撃）、悪意のあるコードはビルド出力に入り込み、訪問者に提供される可能性があります。
3つの理由により、実際にはWordPress同等物よりも意味のあるリスクが小さくなります。まず、悪意のあるコードはビルドとデプロイの次の実行時にのみ実行されます。WordPressプラグインの侵害は、プラグインの自動更新から数分以内にライブ訪問者に悪意のある動作を出荷できます。次に、npmパッケージの侵害は通常、自動スキャナー、dependabot、セキュリティ研究コミュニティによって数時間以内に検出されます。これは、多くの本番ツールが同じパッケージに依存しているためです。第3に、セキュリティ意識の高いヘッドレスセットアップは依存関係のバージョンをピン留めしてロックファイルを使用するため、明示的に更新を選択するまで悪意のあるリリースを取得しません。
ヘッドレスで私がまだ推奨することは、依存関係をピン留めし、すべてのビルドでnpm auditを実行し、主要なパッケージのGitHubセキュリティアドバイザリにサブスクライブし、予定外のデプロイをセキュリティレビュートリガーとして扱うことです。
典型的なWordPressハックは実際にどのように発生しますか？
Seahawkで過去24カ月間に対応したインシデントを見ると、大まかな分布は次のとおりです。約40%は既知でパッチされたCVEを持つ古いプラグインまでさかのぼります。約25%は侵害された管理アカウントまでさかのぼり、ほぼ常に2FA認証なしの弱いパスワードです。約15%は古いWordPressコアまたはPHPバージョンまでさかのぼります。約10%はカスタムテーマの脆弱性までさかのぼります。残りの10%はそれ以外のすべてです。ホスティングアカウント侵害、DNS乗っ取り、悪意のある開発者アクセス、プラグイン保守者に対する供給チェーン攻撃です。
ヘッドレスサイトでは、こうした根本原因の多くが単純に存在しないことに気づいてください。パッチを当てるべきプラグインはない。公開サイト上に管理者アカウントはない。PHPがないため、PHPのバージョンは関係がない。カスタムテーマはライブサーバー上ではなく、ビルドパイプラインで動作する。
つまり、ヘッドレスは破られないということですか？
いいえ。残りの攻撃ベクトルは実在する価値があり、名前を付ける価値があります。コンテンツエディタのCMS認証情報をフィッシングすることはまだ機能します。CMS自体に脆弱性が存在する可能性があります（Sanity、Contentful、Strapi、PayloadはすべてCVEを発表しました）。VercelまたはNetlifyのホスティングアカウント侵害により、攻撃者は鍵を手に入れます。DNSハイジャックはサイトの構築方法に関わらずトラフィックをリダイレクトします。Gitリポジトリへの悪意あるコミットは、攻撃者が望むものをリビルドしてデプロイします。
変わるのは攻撃のコスト曲線です。毎日すべてのWordPressインストールを狙う、機会を狙った自動化されたスキャン型の攻撃は、スキャンの対象となるフィンガープリントがなく、機能する定型手法がないため、ヘッドレスサイトを狙ったものではありません。ヘッドレスサイトに対して成功する攻撃は、目標を絞った意図的なものであり、認証情報の盗難またはサプライチェーンアクセスのいずれかが必要です。これらは実在する脅威です。これらはまた、よく運営されたWordPressインストールが機会を狙った攻撃に加えて直面する脅威でもあり、その代わりではありません。
WordPressはなぜ大多数のビジネスにとって依然として十分に安全ですか？
それを安全に保つための運用規律が十分に理解され、広く実践されているからです。コアアップデート、サーバーの堅牢化、データベース分離を処理するマネージドホストを使用してください。オリジンの前にCloudflareまたは同等のWAFを配置してください。すべての管理者ログインに対して2FAを有効にしてください。管理者アカウントをできるだけ少数の人に制限し、四半期ごとに監査してください。厳選されたプラグインを実行し、評判の高い著者からの10個以下の保守されたプラグインを使用してください。毎週すべてをアップデートしてください。毎日バックアップを取得し、少なくとも四半期に1回復元をテストしてください。毎日実行されるマルウェアスキャナを使用してください。
このレジメンを一貫して適用すると、WordPressは平均的なビジネスの平均的なヘッドレスサイトと同じくらい安全になります。問題は一貫性です。ハッキングされるWordPressサイトは、このレジメンを持つサイトではありません。それらはエージェンシーが2年前に契約解除され、プラグインアップデートが停止し、管理者アカウントのパスワードが2019年に設定され、誰もホストコントロールパネルに数ヶ月間ログインしていないサイトです。ヘッドレスサイトはこの種のネグレクトに寛容です。WordPressサイトはそうではありません。
セキュリティのデルタは2026年のエージェンシークライアントにとって何を意味しますか？
クライアント会話のための私の作業フレーム：WordPressは、コンテンツ速度、プラグインエコシステムの活用、または非技術的なエディターの経験が主な要件であり、クライアントが継続的なセキュリティメンテナンスに資金を提供する意思がある場合に正しい選択肢です。ヘッドレスは、クライアントが「セットアンドフォーゲット」のセキュリティ体勢を望む場合、チームがビルドパイプラインを実行する技術的成熟度を持っている場合、およびコンテンツモデルが構造化CMSが理にかなっているほど十分に定義されている場合に正しい選択肢です。
実際には、次のことを意味します：マーケティングサイト、ブローシュアサイト、ドキュメンテーションサイト、およびダウンタイムが高額な高値物件ページはヘッドレスとしてより良いパフォーマンスを発揮する傾向があります。プラグインエコシステムの依存性が高いサイト（メンバーシップ、地域別税要件を持つニッチなe-commerce、複雑なLMS、BuddyPress風のコミュニティ）は、プラグインの活用がセキュリティのオーバーヘッドを上回るため、WordPressとしてより良いパフォーマンスを発揮する傾向があります。
セキュリティの判断は、どのアーキテクチャが絶対的な意味でより安全かということではなく、クライアントが現実的に資金を投じるセキュリティメンテナンスにどのアーキテクチャがマッチするかということです。
セキュリティが唯一の基準だとしたら、私は何を構築するか？
CI上でコンテンツ変更のたびにビルドされた静的レンダリングのAstroまたはNext.jsサイト、VercelまたはNetlifyにデプロイのみのAPIトークンでデプロイ、SupabaseまたはSanityからRLSまたはドキュメントレベルのパーミッションの背後にあるコンテンツソース、レート制限を備えた個別のエッジファンクションにポストされたフォーム、ホスティングプロバイダーの環境に置かれたすべてのシークレット（コミットされない）、DNSSEC有効化されたCloudflareでのドメインDNS、チェーン内のすべてのアカウント（CMS、ホスティング、DNS、git、パッケージレジストリ）で必須の2要素認証、そしてあらゆる依存関係の変更をフラグする設定のdependabot。このセットアップは、標的化された国家規模の操作以外の何かにによってクラックされることはほぼ不可能に近いものですが、それは平均的なマーケティングサイトの脅威モデルではありません。
まとめ
WordPressは管理可能です。ヘッドレスは許容できます。正直な違いは、ヘッドレスサイトなら6か月間放置して戻ってきてもまだセキュアであることを確認できるということです。WordPressではそうはいきません。2026年にアーキテクチャを決定する企業にとって、セキュリティの議論は「どちらがより安全か」というより「どのセキュリティ姿勢が私の実際の運用規律にマッチするか」ということです。「我々はこのサイトに密接な注意を払わない」というのが答えであれば、ヘッドレスが実質的なマージンでより安全な選択肢です。
私たちはWordPress以外のものより圧倒的にWordPressをシップしています。ほとんどのクライアントがWordPressが独自に提供するものを必要としているからです。しかし、会話が「それが動き続けるようにしたいだけで、そのことについて考えたくない」という点から始まるクライアントについては、私はヘッドレスを最初に勧めて、その理由を説明するようになってきています。
関連する読み物
Headless WordPress in 2026: the complete practical guide
WordPress vs Next.js in 2026: my honest comparison
WordPress Maintenance Is Mostly About Care