보안

사이트 키의 보안 페이지는 챌린지가 얼마나 어려운지, 그리고 어떤 요청이 그것에 닿도록 허용되는지를 정합니다. 기본값은 합리적인 중간입니다; 이 페이지는 언제 그것에서 벗어날지, 그리고 어느 쪽으로 갈지에 관한 것입니다.

여기서 시작하세요

대부분의 사이트는 기본값을 그대로 두어야 합니다. 이유가 있을 때 아래 손잡이로 손을 뻗으세요:

• 활발한 남용을 받고 있거나, 폼이 고가치일 때(가입, 결제, 비밀번호 재설정): 보호를 올리세요. 난이도를 올리고, 난독화 수준을 올리고, 자동화 브라우저 차단을 켜세요. 약간의 방문자 연산과 얼마간의 서버 CPU를 훨씬 더 높은 벽과 맞바꿉니다.
• 속도와 전환이 가장 중요하고, 위험이 낮을 때(마케팅 페이지의 뉴스레터 박스): 보호를 가볍게 두세요. 난이도를 낮게, 요청당 챌린지를 1로 두어, 저렴한 폰에서도 챌린지가 깃털처럼 가볍게.

이 페이지의 나머지는 각 손잡이와 그것을 어느 쪽으로 돌릴지입니다.

게임 요구하기

여기서 가장 강한 제어는, 조용한 백그라운드 확인을 통과하는 것만이 아니라, 방문자가 통과하려면 게임을 하도록 요구하는 것입니다. 여기 보안 페이지에서 검증에 게임 요구를 켜면, 모든 방문자가 이 키에 등록된 게임 중 하나를 풀어야 합니다. 서버가 각 방문자가 어떤 게임을 받을지 고르니, 건너뛰거나 바꿀 수 없습니다.

키가 쓸 수 있는 게임을 등록하며, 게이트가 자신을 온전히 설명하는 곳도 거기, 키의 게임과 게임 게이트 페이지입니다. 게임이 최소 하나 등록되기 전에는 게이트를 켤 수 없습니다. 그것을 꺼 두는 것이 덜 안전한 선택입니다: 키는 게임을 하지 않고도 통과될 수 있습니다.

Proof of work: 난이도와 요청당 챌린지

Proof of work는 브라우저가 작은 퍼즐을 풀게 해 대규모 남용이 비싸지게 합니다(proof of work를 보세요).

• 난이도(1에서 8)는 각 퍼즐이 얼마나 어려운지를 정합니다. 높을수록 공격자에게 더 비싸지만, 방문자의 기기에도 더 비싸며, 저사양 폰은 범위의 위쪽에서 그것을 느낍니다. 기본값에서 시작하고, 실제로 남용이 보일 때만 올리세요.
• 요청당 챌린지(1에서 500)는 여러 풀이를 한 번에 요청해 비용을 곱합니다. 더 쌓을 구체적 이유가 없다면 1로 두세요.

브라우저는 이 퍼즐을 Web Worker에서 푸니, 당신의 페이지 Content-Security-Policy는 워커를 위해 blob:을 허용해야 합니다(worker-src blob:); 이것은 필수입니다. script-src에서 'wasm-unsafe-eval'을 허용하면 풀이기가 추가로 빠른 WebAssembly로 돌지만, 그것은 선택입니다: 그것 없이는 풀이기가 같은 Worker 안에서 더 느린 순수 JavaScript 구현으로 물러나며 검증은 여전히 동작합니다. 전체 호스트 페이지 정책은 게임 샌드박싱을 보세요.

계측: 난독화 수준과 자동화 브라우저 차단

계측은 방문자의 브라우저에서 작은 프로그램을 돌려, 스크립트가 아니라 진짜 브라우저가 챌린지를 풀었는지 확인합니다(계측을 보세요). 기본으로 켜져 있으며, 진짜 브라우저를 자동화된 것과 구별하는 유일한 계층입니다.

• 계측은 키별로 끌 수 있습니다. 거의 모든 사이트에서 켜 두세요. 당신의 위젯을 임베드하는 페이지가 'unsafe-eval'을 허용할 수 없는 Content-Security-Policy를 돌릴 때만 끄세요(계측 프로그램이 그것을 필요로 합니다, 아래 참고). 그것을 끄면 키는 더 이상 자동화 브라우저를 탐지할 수 없으며, proof of work와 모든 필수 게임은 여전히 돌지만, 아래 두 설정은 적용을 멈춥니다.
• 난독화 수준(1에서 10)은 브라우저 내 프로그램이 역공학하기 얼마나 어려운지입니다. 높을수록 강하지만 서버 CPU를 더 씁니다. 기본값이 대부분의 사이트에 맞습니다; 표적 공격자의 잦은 표적이라면 올리세요.
• 자동화 브라우저 차단은 탐지된 헤드리스와 WebDriver 클라이언트를 단호히 거부합니다. 정당한 자동화가 당신의 폼에 결코 닿지 않는다면 켜세요. 정당한 봇(당신 자신의 모니터링, 파트너 연동, 접근성 도구)을 기대한다면 꺼 두세요, 그것들도 차단할 것이기 때문입니다.

Content-Security-Policy

계측 프로그램은 방문자의 브라우저에서 eval을 돌리니, 당신의 위젯을 임베드하는 페이지는 그 script-src에서 'unsafe-eval'을 허용해야 합니다. 이것은 하나의 단단한 CSP 요건이며 대체가 없습니다: 'unsafe-eval'이 차단되면, 검증이 시간 초과되고 브라우저 콘솔에 [cap] Instrumentation failed가 보입니다. 두 선택이 있습니다: 위젯을 호스팅하는 페이지에서 'unsafe-eval'을 허용하거나, 계측을 꺼서(위) 그 요건을 없애거나. 호스트 페이지의 CSP가 필요로 하는 것의 전체 목록은 게임 샌드박싱에 있습니다.

필수 헤더

모든 요청이 특정 헤더를 지니도록 요구할 수 있습니다. 대부분의 사이트는 이것이 필요 없습니다; 당신 자신의 클라이언트가 늘 게이트로 삼을 수 있는 헤더를 보낼 때, 값싼 추가 필터로 유용합니다.

당신이 요구할 수 없는 것은, 요청이 검증에 닿기 전에 Caputchin이 프라이버시를 위해 제거하는 헤더입니다. 그것들은 방문자를 식별하며, Caputchin의 자세는 방문자별 데이터를 수집하지 않는 것이라, 플랫폼 경계에서 그것들을 떨굽니다:

이들 중 하나를 요구하면 그것이 결코 도착하지 않으니 모든 요청을 차단하게 되므로, 플랫폼은 당신이 키를 망가뜨리게 두는 대신 그 구성을 거부합니다.

속도 제한과 CORS 오리진

• 초당 최대 요청은 키가 얼마나 빠르게 요청을 받을지 상한을 둡니다. 진짜로 트래픽이 높다면 올리고; 두들겨 맞는 키를 조이려면 낮추세요.
• CORS 오리진은 당신의 오리진 허용 목록으로, 퍼즐이 돌기도 전에 서버 측에서 강제됩니다. localhost에서 테스트하는 동안에는 비워 두세요; 라이브로 가기 전에, 당신 자신의 사이트만 키를 쓸 수 있도록 진짜 오리진을 더하세요.

함께 보기

• 게임을 등록하고 검증에 하나를 요구하려면 게임과 게임 게이트.
• 키의 나머지는 사이트 키.
• 당신의 설정이 맞는 트래픽을 멈추는지 보려면 통계와 세션.