Q.StudioのフォームのWebhook通知やreCAPTCHAは、移行先でどう設定し直せばよいですか？

「問い合わせが来たらSlackに飛ぶようにしていたけれど、あのURLも危ないのか」と迷う方もいるでしょう。Studioに登録されていたWebhook通知先のURLは、流出した可能性のある情報に含まれています。第三者が実際に取得した事実は確認されていません。それでもStudioは、取得されたものとみなして対応を進めています。この経緯はStudioのセキュリティ通知でも公表されています。

ただ、Studioのプロジェクト設定にあるWebhook通知の設定は、サイトの公開・更新・非公開と、サイトへのコメント追加を知らせる機能です。フォームの回答を送る機能ではありません。

自分のサイトでどちらを使っていたかによって、見直す場所が変わります。Studioの設定欄にURLを入れていたなら、流出した可能性がある対象として扱ってください。スクリプト側でSlackに送っていた場合は、Apps ScriptにURLが書かれています。移行のときに、こちらもあわせて差し替えると安心感が違いますね。

移行先のWebサイトでフォームのWebhook通知を動かすには、どのような順序で設定を進めればよいでしょうか。SlackへのWebhook通知は、指定のURLに対してメッセージを含むJSONデータをHTTP POSTで送信する仕組みです。移行先のフォームやスクリプトが、この形式で送れるかも確かめます。

Slackの場合の流れは次のとおりです。

1. Slackアプリの設定でIncoming Webhooksを有効にする
2. 「Add New Webhook to Workspace」から通知先チャンネルを選んで認可する（非公開チャンネルなら、先にそのチャンネルへ参加しておく）
3. 発行されたURLを移行先のフォームや送信処理に設定する
4. 実際にフォームを送信し、チャンネルに通知が届くか見る
5. 届いたのを見てから、古いURLを無効にする
6. Studio公式例のApps Scriptを使っていたなら、script.google.comの「My Triggers」で対象のトリガーを開き、「Delete trigger」で削除する

順番では5番目を守ってください。Slack Incoming Webhooksの仕様上、無効になったURLへ送るとエラーになることがあります。古いURLを先に消すと、テストの段階で通知が来ません。Apps Scriptのトリガー削除はURLの無効化とは別の操作なので、どちらか一方だけで終わらせないようにしましょう。

通知先がMicrosoft Teamsなら、手順が変わります。Workflowsで通知用のフローを作り、そこで生成されたURLへ外部からHTTP POSTを送ります。Slackの画面操作をそのまま当てはめても進められません。

Studioに登録していたreCAPTCHA v3の認証情報は、別の制作基盤へ移る際にわざわざ差し替えるべきなのか迷うところです。reCAPTCHA v3の設定情報も、流出した可能性のある情報に含まれています。そのうえでStudioは、いまのところ一律の差し替えは求めていません。心配な人が予防として切り替えるのは問題ありません。

一方で、次のどちらかに当てはまるなら新しいキーへ切り替えます。フォームが送信できなくなった場合と、reCAPTCHAの管理画面で心当たりのない利用の増加が見られる場合です。シークレットキーだけでは、フォームの回答を見たり、GoogleアカウントやreCAPTCHAの管理画面に入ったりすることはできません。とはいえ、フォームの回答そのものが流出した可能性とは別に考えてください。

移行先でreCAPTCHAを引き続き利用する場合は、キーの利用範囲に目を向けましょう。reCAPTCHAの保護範囲は指定したドメインとそのサブドメインに制限されるため、reCAPTCHAの管理画面で新しい公開ドメインやテスト環境のURLを許可リストに含める必要があります。既存キーの設定は管理画面で変更できるので、移行のためだけに新しく発行しなければならないわけではありません。

キーを交換する際は、Google側で新キーを発行してサイトに反映し、正常に送信できるかテストした後に古いキーを削除します。古いキーを先に消すと、フォームが止まってしまいます。同じキーを複数のWebサイトで使い回している場合は、他サイト側の設定値も合わせて更新してください。

reCAPTCHAだけに任せるより、別の対策と組み合わせたほうが守りは厚くなります。Cloudflareのフォーム保護は、人間かどうかの判定に、同じIPアドレスからの送信回数の制限を重ねる構成です。上限は、ふだんの問い合わせより多めの回数にします。こうすれば、普通に送る人を締め出しません。もっとも、使えるルールの数や期間はプランで異なります。

Netlifyのフォームには、ハニーポットという仕組みがあります。ハニーポットとは、画面上では一般の訪問者に見えない隠し項目を用意し、機械的な巡回ボットがそこに値を入力して送信してきた場合に拒否する仕組みです。人間には入力できない欄を利用するため、利用者の利便性を損なわずに迷惑投稿を弾けます。

また、reCAPTCHA v3はフロントエンドにスクリプトを読み込ませるだけでなく、フォーム送信を受け取るバックエンド側でトークンをGoogleのAPIに照会して検証しなければ判定が機能しません。しきい値は0.5程度から始め、実際のアクセスを見て決めるのが無難でしょう。

ちなみに、Studio標準のreCAPTCHA v3連携は有料プランで使え、v2には対応していません。設定はプロジェクト内のフォームすべてにかかり、フォームごとには変えられません。移行先で問い合わせフォームと資料請求フォームを分けて調整したいなら、ここは移行後のほうが自由がききますね。