サイトをヘッドレス構成に作り替えたあと、こう説明されることがあります。「表側は静的なファイルを配信するだけなので、WordPressの脆弱性を突かれる心配はありません」。前半は正しい説明です。ただ、この説明を聞いた側は「WordPressは無くなった」と受け取ります。
実際には、コンテンツを書くための WordPress は動き続けています。動き続けているものは、更新も監視も必要です。GH Media 自体、Astro で静的に書き出したページを配信しつつ、記事の本体は別に立てた WordPress から GraphQL で取り出す構成で動いています。表側が静的になっても、裏側は消えません。
ヘッドレスにすると、攻撃を受ける面は減ります。ただし減り方に偏りがあり、減った分と同じ場所を見ていると、残った入口を見落とします。
何が消えて、何が残り、何が増えるのか
先に全体像を押さえます。
| ヘッドレス化で | 理由 | |
|---|---|---|
| 公開ページでのコード実行 | ほぼ消える | 配信するのは生成済みのファイルで、リクエストごとの処理がない |
| 公開ページ経由の管理画面への到達 | 消える | 同じドメインに管理画面が乗っていない |
| 管理画面そのもの | 残る | 記事を書く場所として動き続ける |
| コンテンツAPI | 増える | 外から呼べる取得口が新たにできる |
| ビルドの仕組み | 増える | 資格情報を持った自動処理が加わる |
上2行が「安全になった」と説明される部分です。下3行は説明に出てこないことが多い部分で、ここが引き渡し後に放置されます。
入口1: 管理画面は、場所が変わっただけ
ヘッドレス化でよくある構成は、cms.example.com のような別のホスト名でCMSを動かし、公開サイトは別のドメインで配信する形です。分離されたので公開サイトからは到達できません。しかしインターネットからは到達できます。
見落としがちなのは、分離したことで関心も分離してしまう点です。公開サイトは監視され、表示崩れがあれば誰かが気づきます。裏側のCMSは、記事を書く数人しか開きません。更新が止まっていても、誰も気づかない場所になります。
ここで確認すべきことは3つです。
- アクセス元を絞れているか。 執筆者が限られているなら、IPアドレスや認証の前段で絞るのが最も効きます。ヘッドレスCMSのサービスでも、管理画面やAPIへのアクセスをIPアドレスで制限できるものがあります
- 更新が続いているか。 本体とプラグインの更新が止まっていないか。表に出ていないことは、更新しなくてよい理由になりません
- 多要素認証が入っているか。 執筆者のアカウントは、パスワードだけで守られていないか
自社で運用する形のCMSを使う場合、この3つは制作会社ではなく運用側の仕事になりがちです。どちらの仕事かを引き渡しの時点で決めていないと、誰の仕事でもなくなります。
入口2: コンテンツAPIは、権限の粒度で決まる
ヘッドレス化で新しく増えるのが、コンテンツを取り出すためのAPIです。ここで実際に起きる事故は、複雑な攻撃ではなく単純な取り扱いの問題に集中します。
APIセキュリティの解説でも、認証キーやトークンの漏えい、そして認可の確認が足りず本来見えないものが見えてしまうケースが多く報告されるとされています。ヘッドレス構成では、この2つがそのまま当てはまります。
- キーが公開側に混ざる。 フロントエンドのコードにキーを埋め込むと、ブラウザから読めます。ビルド時にだけ使うキーと、実行時にブラウザから使うキーを分けていない構成で起きます
- キーの権限が広すぎる。 読み取りだけで済むのに、書き込みもできるキーを使っている。漏れたときの被害が、読まれるだけで済むか、書き換えられるかを分けるのがここです
- 下書きが取れてしまう。 公開済みだけを返す指定になっておらず、未公開の記事がAPIから取得できる。プレビュー用の経路を本番と同じキーで作ると起きやすい形です
3つ目は実務でいちばん多く、かつ気づかれにくい問題です。公開前の発表資料やプレスリリースが、公開日より前に取得できる状態は、技術的な侵害がなくても情報が出てしまいます。ヘッドレスCMSのサービスでは、APIキーごとにアクセスできるリソースを定義して、漏えい時の影響範囲を絞れるようになっています。使える機能があるなら、既定のキーを使い回さないでください。
入口3: ビルドは、資格情報を持った自動処理
静的サイトは誰かが手で書き出すわけではなく、CMSの更新を受けて自動で生成されます。この仕組みは、CMSのキーと配信先の権限を両方持っています。
確認したい点は次のとおりです。
- ビルドを起動できるのは誰か。 更新を知らせる通知の受け口が、誰でも叩ける状態になっていないか
- 資格情報がどこに置かれているか。 リポジトリの中に平文で入っていないか。ビルド環境の秘密情報として管理されているか
- ログに何が出ているか。 ビルドのログにキーや取得したコンテンツが出力されていないか。ログは公開されている場所に残ることがあります
この領域は、Jamstack 構成の利点として語られる部分の裏側にあたります。構成そのものの考え方はJamstackが新しい標準になる理由で、WordPressをヘッドレスに寄せる手順はWordPressのヘッドレス移行で扱っています。移行の段階では、この3つの入口を誰が見るかまで決めておくと、あとから揉めません。
引き渡しのときに確認する
ヘッドレス構成の引き渡しでは、次の項目を文書で残してください。口頭だと、担当者が変わった時点で消えます。
- CMSの本体とプラグインの更新は、誰がいつ行うか
- CMSの管理画面にアクセスできる範囲は、どう絞られているか
- 使っているAPIキーの一覧と、それぞれの権限
- 未公開コンテンツがAPIから取得できないことの確認結果
- ビルドの資格情報の置き場所と、起動できる人の範囲
この5項目は、構成が正しくてもドキュメントがないと運用で崩れます。Webサイト全般のセキュリティの土台についてはWebサイトセキュリティの基本を、ヘッドレスCMSとフロントエンドの組み合わせ方の実例はAstroとmicroCMSでの構築を合わせて確認してください。
次にやること
自社サイトがヘッドレス構成なら、CMSの管理画面のURLを、社内ネットワークの外から開いてみてください。ログイン画面が出るなら、アクセス元を絞る設定は入っていません。それ自体が即座に問題とは限りませんが、更新と認証の状態を確認する合図です。
もう1つ。公開予定日がまだ来ていない記事を1本用意して、公開側で使っているのと同じ方法でAPIから取得してみてください。取れてしまうなら、そこが先に直す場所です。
ヘッドレス構成の設計と引き渡し、既存サイトの構成の棚卸しについては、グリームハブの開発・AI・自動化のご相談で承っています。使っているCMSと配信の組み方によって確認の順番が変わるため、お問い合わせからご相談ください。
