ウェブサイトビルダーが API キーを預かっているとき：STUDIO の不正アクセス

公開 2026-10-19

2026 年 10 月 16 日、日本で広く使われているノーコードのウェブサイトビルダー STUDIO（studio.design）が、不正アクセスに関するお知らせを公表しました（10 月 18 日更新）。第三者が STUDIO の機能の脆弱性を突き、同社のクラウド環境にアクセスしたというものです。現時点で確認されているアクセス期間は 2026 年 9 月 30 日から 10 月 1 日（日本時間）です。STUDIO は 10 月 13 日に事態を把握し、13〜14 日に侵入経路を塞ぎました。データが実際に持ち出されたかは確認されていませんが、STUDIO は持ち出されたものとして対応を進めており、個人情報保護委員会にも報告しています。

ITmedia の報道によると、STUDIO のユーザは 90 万人を超えます。多くの人はこれをパスワードの漏えいと受け止めるでしょう。しかし多くのサイトにとって、より大きな問題は API キーです。

漏えいした可能性があるもの

• アカウント情報：ユーザ名、メールアドレス、ハッシュ化されたパスワード。
• デザインエディタと CMS のコンテンツ、フォームの送信内容、Live Preview の URL。
• API 連携（Data Connect、API Connect ベータ）に登録した外部サービスの API キーとトークン。
• Google スプレッドシート連携の認証情報、カスタムプロキシのキー、reCAPTCHA v3 の設定、Webhook 通知先の URL。
• パスワード保護ページのパスワード（ハッシュ化済み）。

暗号化して保存されていたものもありますが、復号に必要な鍵にもアクセスされていたため、読み取られた可能性があると STUDIO は説明しています。STUDIO は 10 月 14 日に Google スプレッドシート連携のキーを更新し、17 日にフォーム送信内容と API キーの暗号鍵を入れ替えました。決済情報は対象に含まれていません。

パスワードの漏えいより深刻な理由

ほかのサービスからコンテンツを取り込むウェブサイトビルダーは、そのサービスのキーを預かる必要があります。STUDIO のサイトが Data Connect を通じて microCMS から記事を読み込んだり、OpenAI を呼び出したり、Google と連携したりしていれば、それぞれのサービスのキーが STUDIO の中にあったことになります。そのコピーを持つ人は、STUDIO を経由せずに、そのサービスへ直接キーを使えます。

STUDIO のパスワードを変えても、これらのキーには何の効果もありません。キーは 1 つずつ、それぞれのベンダー側でローテーションする必要があります。ベンダーで新しいキーを発行し、STUDIO に貼り付け、古いキーを無効にします。しかも古いキーが STUDIO の中だけにあることはまれです。同じ値が .env ファイルやサーバ、誰かのノートパソコン上のスクリプトにも入っていることがよくあります。古いキーを無効にする前にそのすべてを新しいキーに替えておかないと、別のところが動かなくなります。

今やるべきこと

STUDIO は利用者に次の対応を求めています。多くのサイトでは、3 つ目が作業の中心になります。

1. メールアドレスでサインインしている場合は、STUDIO のパスワードを変更し、同じパスワードを使っているほかのサービスでも変更します。
2. Live Preview の URL を削除し、発行し直します。
3. STUDIO に保存した外部サービスの API キーとトークンをすべてローテーションします。ベンダーで新しいキーを発行して STUDIO に貼り付け、同じキーを使うほかの場所もすべて更新してから、古いキーを無効にします。各ベンダーのログと請求を 9 月 30 日までさかのぼり、身に覚えのない利用がないか確認します。
4. パスワード保護ページのパスワードを変更します。
5. Google スプレッドシート：同期を停止（Stop Sync）し、Google アカウントの連携アプリから STUDIO を削除してから、連携を設定し直します。
6. カスタムプロキシ：新しいプロキシキーに切り替え、10 月 16 日のメールから 30 日以内に STUDIO へ連絡します。
7. Webhook 通知先の URL を変更します。
8. STUDIO のパスワードを尋ねる連絡は、フィッシングとして扱います。

FrontierStack にできること

FrontierStack が STUDIO の中を変更することはできません。しかし次のアップデートからは、どのサイトが影響を受けるかを示し、対応が忘れられないようにします。

• STUDIO で作ったサイトを見つけます。ドメインヘルスが各トップページの generator タグを読み取るため、STUDIO で作ったサイトにはホストとして STUDIO が表示されます。Wix、Webflow、Framer も同じように識別します。そのビルダーで最近侵害があった場合、ドメインに「侵害されたビルダー」と表示されます。
• チェックリストを目の前に置きます。サイトペインのバナーに影響を受けるドメインが並び、ベンダーの対応手順がチェックリストとして表示されます。進捗は保存されます。対応済みにするまで、セキュリティのアラートは消えません。
• iPhone にも届きます。アラートは FrontierStack のプッシュリレーを通じて、ペアリングした iPhone に専用の「ベンダー侵害」通知として届きます。通知に内容は含まれず、ドメイン名やキー名が Mac の外に出ることはありません。
• 「影響を受けているか」に答えます。AI 管理者にはベンダー侵害を調べる読み取り専用のツールがあり、どのサイトが該当するかを尋ねられます。
• KeyRotate に引き継ぎます。KeyRotate でキーを確認…を選ぶと、その侵害を開いた状態で KeyRotate が起動します。
• アプリのアップデートを待ちません。新しい侵害情報は Enfour が署名したアドバイザリとして届き、アプリに組み込まれた鍵で検証されます。

FrontierStack には STUDIO 専用のペインもあります。STUDIO の公開ステータスページ（Hosted Websites、Editor、Dashboard、Live Preview、Store）を認証情報なしで監視し、障害が起きるとアラートを出します。詳しくは STUDIO を Mac で をご覧ください。

KeyRotate にできること

KeyRotate は API キーを保管し、それぞれのキーをどのファイルやサーバが使っているかを把握しています。次の KeyRotate のアップデートでは、今回の侵害で浮かび上がった部分、つまり手作業でウェブサービスに貼り付けたキーにも対応します。

• キーを貼り付けた先を記録します。キーごとに、貼り付けたウェブサービスを登録できます。対象は STUDIO、Wix、Webflow、Framer、Bubble、Zapier、Make、n8n Cloud、Vercel、Netlify、Retool です。ローテーションの後は、新しいキーをそこへ貼り付けるよう KeyRotate が知らせます。
• まだ危険なキーがわかります。これらのサービスが侵害されると、侵害が封じ込められた後に値を置き換えていないキーに「ベンダーの侵害で漏えい」と表示され、要注意の先頭に並びます。侵害の後でキーを KeyRotate に追加しても、置き換えたことにはなりません。
• まとめてローテーションします。概要のカードで、STUDIO に保存したキーを選びます。続いて漏えいしたキーをローテーション…を選ぶと、Touch ID 1 回で、ベンダーの API が新しいキーを発行できるものはすべて新しいキーを作り、それを使うファイル（.env ファイル、設定ファイル、サーバ）を更新対象として示します。この方法で発行できないキーには、ベンダーのコンソールへのリンクが表示されます。
• 古いキーはそのまま残します。STUDIO は新しいキーを貼り付けるまで古いキーを使い続けるため、KeyRotate が古いキーを自動で無効にすることはありません。サイトが新しいキーで動くのを確かめてから、ご自身で無効にしてください。
• 終わるまで知らせ続けます。漏えいしたキーが残っている間は、3 日ごとに通知が届きます。ntfy や Gotify の自前のサーバを使っていれば、そちらにも送ります。STUDIO のそのほかの手順は、同じカードにチェックリストとして表示されます。

できないこともあります。どちらのアプリも STUDIO にキーを書き込むことはできず、その作業はご自身で行う必要があります。KeyRotate は、チェックを入れるまでどのキーが STUDIO にあったかを知りません。また、すべてのベンダーの API が新しいキーを発行できるわけではないため、ベンダーのコンソールでの作業が残る場合もあります。KeyRotate の機能もご覧ください。

ここから学べること

キーを貼り付けたサービスは、そのキーが漏れうる場所になります。次の侵害の被害を小さくするために、3 つの習慣をおすすめします。

• キーをどこに貼り付けたかを一覧にしておく。持っているキーだけでなく、どのサイトビルダー、自動化ツール、ホスティングのダッシュボードがコピーを持っているかを記録します。どれかが侵害されたとき、ローテーションすべきキーの一覧がすでに手元にあります。
• 権限を絞ったキーを使う。1 つの CMS を読むだけのキーや、利用上限を設定した 1 つの API だけを呼べるキーなら、コピーされても価値はずっと低くなります。ウェブサイトビルダーには、社内業務で使うキーではなく、そのサイト専用に作ったキーを渡します。
• 定期的にローテーションする。数か月ごとに置き換えるキーは、漏れても使える期間が短くなります。普段から慣れているローテーションなら、急を要するときにも素早く進められます。

関連記事（英語）：STUDIO のユーザがほかより大きな被害を受けた理由（Matthew Ketchum、LinkedIn）、今回の侵害のまとめ（Substack）。