【ITニュース解説】How to Secure Your Headless WordPress & WPGraphQL API

WordPressをWebサイトの裏側にあるコンテンツ管理システム（CMS）としてのみ利用し、ユーザーが見る表側の画面（フロントエンド）はNext.jsやAstroといった現代的な技術で自由に構築する「ヘッドレスCMS」という手法が注目されている。この構成では、裏側のWordPressと表側のフロントエンドは、APIと呼ばれる仕組みを通じてデータをやり取りする。特に、WPGraphQLというプラグインを利用すると、GraphQLという効率的な通信規格で必要なデータだけを的確に取得できるため、サイトの表示速度向上にもつながる。しかし、この便利で柔軟なアーキテクチャは、同時に新たなセキュリティ上の課題も生み出す。特に、GraphQLの通信窓口である「GraphQLエンドポイント」を誰でもアクセスできる状態で放置することは、非常に危険である。

GraphQLエンドポイントを無防備に公開しておくことには、主に三つの大きなリスクが存在する。一つ目は、データベース構造の漏洩である。悪意のある第三者は、公開されたエンドポイントに対して「イントロスペクション」という問い合わせを行うことで、サイトがどのようなデータ構造を持っているのか、例えばカスタム投稿タイプやカスタムフィールドといった内部情報まで、そのすべてを詳細に知ることができてしまう。これは、システムの設計図を誰でも閲覧できる状態で公開しているのと同じである。二つ目は、サーバーへの過剰な負荷攻撃、いわゆるDoS攻撃のリスクである。GraphQLは非常に柔軟なデータ取得が可能である反面、意図的に複雑で処理に時間のかかるリクエストを大量に送りつけることで、サーバーのリソースを使い果たさせることが可能になる。これにより、サイトの応答が著しく遅くなったり、最悪の場合にはサーバーがダウンしたりする事態に繋がりかねない。三つ目は、非公開コンテンツへの不正アクセスの可能性である。WordPressの権限設定が完璧でない場合、本来は管理者しか見ることができない下書き状態の記事や、特定のユーザー向けに公開している情報が、GraphQLを通じて外部からアクセスされてしまう危険性がある。

これらのリスクからシステムを守るためには、複数の防御策を組み合わせる「多層防御」という考え方が重要となる。まず行うべき最も基本的な対策は、認証の導入である。WPGraphQLプラグインには、認証されたユーザーからのリクエストのみを受け付ける設定が標準で備わっている。これを有効にすることで、WordPressにログインしていない匿名のユーザーからのアクセスをすべてブロックできる。これが第一の防御壁となる。次に、フロントエンドアプリケーションが正規のユーザーとしてWordPressと通信するために、「アプリケーションパスワード」という機能を利用する。これは、WordPressのユーザープロファイル画面で生成できる、特定のアプリケーション専用のパスワードである。メインのログインパスワードを直接使うのではなく、専用のパスワードを発行することで、万が一そのパスワードが漏洩した際の影響範囲を限定することができる。

アプリケーションパスワードを生成したら、それをフロントエンドのプログラムに安全に組み込む必要がある。ここで絶対に避けるべきなのが、パスワードなどの機密情報をソースコード内に直接書き込む「ハードコーディング」である。コードがバージョン管理システムなどで公開された場合、機密情報も一緒に漏洩してしまうからだ。この問題を避けるためには、「環境変数」という仕組みを利用するのが一般的である。プロジェクト内に.envといった名前のファイルを作成し、そこにパスワードなどの機密情報を記述する。そして、プログラムからはその変数を読み込んで利用する。この設定ファイルは、.gitignoreに追記してバージョン管理の対象から除外しておくことが必須である。プログラムからは、この環境変数に保存されたユーザー名とアプリケーションパスワードを使い、APIリクエストを送信する際に「Authorization」ヘッダーに認証情報を付与することで、正規のアプリケーションであることをWordPressに証明する。

基本的な認証に加えて、さらにセキュリティを強固にするための高度な対策も存在する。一つは、フロントエンドとバックエンドの間だけで通用する秘密の文字列を「カスタムヘッダー」として設定する方法である。APIリクエストにこの特別なヘッダー情報が含まれていない場合、サーバー側でリクエストを拒否するように設定すれば、GraphQLエンドポイントのURLを知っているだけではアクセスできなくなり、正規のフロントエンドからの通信であることをより確実に検証できる。また、サーバーのファイアウォールやホスティングサービスの機能を利用して、フロントエンドアプリケーションが動作しているサーバーのIPアドレスからのみGraphQLエンドポイントへのアクセスを許可する、というIPアドレス制限も非常に効果的な防御策である。さらに、ヘッドレス構成ではWordPressの従来の「REST API」を使用しない場合も多い。もし不要であれば、このREST APIを無効化することで、そこを標的としたユーザー情報の列挙攻撃などを未然に防ぐことができる。このように、複数のセキュリティ対策を層のように重ねて実装することで、ヘッドレスWordPressの柔軟性とパフォーマンスを最大限に活かしつつ、外部の脅威からシステムを安全に保護することが可能となる。