セキュリティ

サイトキーの セキュリティ ページは、チャレンジをどれだけ難しくするか、そしてどのリクエストがそこに到達できるかを決めます。既定値は理にかなった中間です。このページは、いつそこから動かすか、そしてどちらの向きへかについてのものです。

ここから始める

ほとんどのサイトは既定値をそのままにしておくべきです。理由があるときに、下のつまみに手を伸ばしてください：

• 積極的な濫用にさらされている、またはフォームの価値が高い（サインアップ、決済、パスワードリセット）：保護を上げます。難易度 を上げ、難読化レベル を上げ、自動化ブラウザをブロック をオンにします。少しの訪問者側の計算といくらかのサーバー CPU と引き換えに、はるかに高い壁を得ます。
• 速度とコンバージョンが最優先で、リスクは低い（マーケティングページのニュースレターの箱）：保護を軽く保ちます。難易度 を低く、リクエストごとのチャレンジ数 を 1 のままにすれば、安価なスマホでもチャレンジは羽のように軽くなります。

このページの残りは、つまみ 1 つずつと、どちらの向きへ回すかです。

ゲームを必須にする

ここで最も強い制御は、静かな背景チェックをクリアするだけでなく、訪問者にゲームを遊ばせて通らせることです。ここセキュリティページで 検証にゲームを必須にする をオンにすると、すべての訪問者は、このキーに登録されたゲームの 1 つをクリアしなければなりません。サーバーがどのゲームを各訪問者に渡すかを選ぶので、飛ばすことも入れ替えることもできません。

キーが使えるゲームはあなたが登録し、ゲートがそれ自身を完全に説明するのも、キーの ゲームとゲームゲート ページのそこです。少なくとも 1 つゲームが登録されるまで、ゲートはオンにできません。オフのままにするのは、より安全でない選択です。キーは、ゲームを遊ばずに通れてしまいます。

proof of work：難易度とリクエストごとのチャレンジ数

proof of work はブラウザに小さなパズルを解かせて、大規模な濫用を高くつくものにします（proof of work を参照）。

• 難易度（1 から 8）は、各パズルがどれだけ難しいかを設定します。高いほど攻撃者により多くのコストをかけますが、訪問者のデバイスにもより多くのコストがかかり、ローエンドのスマホは範囲の上端でそれを感じます。既定で始め、実際に濫用が見えたときだけ上げてください。
• リクエストごとのチャレンジ数（1 から 500）は、一度に複数回の解を求め、コストを倍増させます。もっと積み増す具体的な理由がない限り、1 のままにしてください。

ブラウザはこれらのパズルを Web Worker の中で解くので、あなたのページの Content-Security-Policy は worker に対して blob: を許可しなければなりません（worker-src blob:）。これは必須です。script-src で 'wasm-unsafe-eval' を許可すると、ソルバーを高速な WebAssembly として走らせることもできますが、それは任意です。なしでも、ソルバーは同じ Worker の中の、より遅い純粋な JavaScript の実装にフォールバックし、検証は引き続き動きます。ホストページの完全なポリシーについては ゲームのサンドボックス化 を参照してください。

計測：難読化レベルと自動化ブラウザをブロック

計測は、本物のブラウザが、スクリプトではなく、チャレンジを解いたことを確かめるために、訪問者のブラウザで小さなプログラムを走らせます（計測 を参照）。既定でオンであり、本物のブラウザを自動化されたものと見分ける唯一の層です。

• 計測 はキーごとに オフ にできます。ほぼすべてのサイトでオンのままにしてください。ウィジェットを埋め込むページが 'unsafe-eval' を許可できない Content-Security-Policy を走らせている場合だけ、オフにしてください（計測プログラムにはそれが必要です、下記参照）。オフにすると、キーは自動化ブラウザを検出できなくなりますが、proof of work と必須のゲームは引き続き走り、下の 2 つの設定は適用されなくなります。
• 難読化レベル（1 から 10）は、ブラウザ内のプログラムがどれだけリバースエンジニアリングしにくいかです。高いほど強いですが、サーバー CPU をより多く使います。既定はほとんどのサイトに適切です。頻繁で狙われた攻撃者の標的なら上げてください。
• 自動化ブラウザをブロック は、検出された headless や WebDriver のクライアントをきっぱり拒否します。正当な自動化がフォームに一切触れないなら オン にしてください。正当なボット（あなた自身の監視、パートナー連携、アクセシビリティツール）を見込むなら オフ のままにしてください。それらもブロックしてしまうからです。

Content-Security-Policy

計測プログラムは訪問者のブラウザで eval を走らせるので、ウィジェットを埋め込むページは script-src で 'unsafe-eval' を許可しなければなりません。これは唯一の厳しい CSP 要件で、フォールバックがありません。'unsafe-eval' がブロックされると、検証はタイムアウトし、ブラウザのコンソールに [cap] Instrumentation failed が表示されます。選択肢は 2 つです。ウィジェットをホストするページで 'unsafe-eval' を許可するか、要件を取り除くために 計測 をオフにする（上記）かです。ホストページの CSP に必要なものの完全な一覧は ゲームのサンドボックス化 にあります。

必須ヘッダー

すべてのリクエストが特定のヘッダーを運ぶことを要求できます。ほとんどのサイトはこれを必要としません。あなた自身のクライアントが常に、ゲートに使えるヘッダーを送る場合に、安価な追加フィルターとして役立ちます。

要求 できない のは、リクエストが検証に到達するより前に、Caputchin がプライバシーのために除去するヘッダーです。それらは訪問者を識別し、Caputchin の姿勢は訪問者ごとのデータを集めないことなので、プラットフォーム境界でそれらを落とします：

これらのどれかを要求するとすべてのリクエストをブロックしてしまいます。決して届かないからです。なので、プラットフォームは、あなたがキーを使い物にならなくするのを許すのではなく、その設定を拒否します。

レート制限と CORS オリジン

• 毎秒の最大リクエスト数 は、キーがどれだけ速くリクエストを受け付けるかを上限づけます。本当にトラフィックが多いなら上げ、叩かれているキーを絞るなら下げます。
• CORS オリジン はあなたのオリジン許可リストで、パズルが走るよりも前に、サーバー側で適用されます。localhost からテストしている間は空のままにし、本番に出す前に、あなた自身のサイトだけがキーを使えるよう、本物のオリジンを追加してください。

あわせて読む

• ゲームを登録し、検証に 1 つを必須にするには ゲームとゲームゲート。
• キーの残りについては サイトキー。
• 設定が正しいトラフィックを止めているかを見るには 統計とセッション。