Kunci situs

Keamanan

Lihat sebagai Markdown

Halaman Keamanan sebuah kunci situs menentukan seberapa sulit tantangannya dan permintaan mana yang boleh mencapainya. Nilai bakunya adalah jalan tengah yang masuk akal; halaman ini soal kapan beranjak darinya, dan ke arah mana.

Mulai di sini

Kebanyakan situs sebaiknya membiarkan nilai baku. Jangkau tombol-tombol di bawah saat kamu punya alasan:

  • Kamu sedang dalam penyalahgunaan aktif, atau formulirnya bernilai tinggi (pendaftaran, pembayaran, reset kata sandi): naikkan perlindungan. Naikkan Kesulitan, naikkan Tingkat obfuskasi, dan nyalakan Blokir peramban otomatis. Kamu menukar sedikit komputasi pengunjung dan sebagian CPU server demi tembok yang jauh lebih tinggi.
  • Kecepatan dan konversi paling penting, dan risikonya rendah (kotak buletin di halaman marketing): jaga perlindungan tetap ringan. Biarkan Kesulitan rendah dan Tantangan per permintaan di 1 agar tantangan terasa seringan bulu di ponsel murah.

Sisa halaman ini adalah tiap tombol dan ke arah mana memutarnya.

Wajibkan sebuah game

Kontrol terkuat di sini adalah mewajibkan pengunjung memainkan sebuah game untuk lolos, bukan sekadar menuntaskan pemeriksaan latar yang diam. Nyalakan Wajibkan game untuk verifikasi, di sini pada halaman Keamanan, dan setiap pengunjung harus menuntaskan salah satu game yang terdaftar di key ini. Server memilih game mana yang didapat tiap pengunjung, jadi ia tak bisa dilewati atau ditukar.

Kamu mendaftarkan game yang boleh dipakai sebuah key, dan di situ pula gerbang menjelaskan dirinya secara penuh, di halaman Game dan gerbang game key tersebut. Kamu tak bisa menyalakan gerbang sampai setidaknya satu game terdaftar. Membiarkannya mati adalah pilihan yang kurang aman: key bisa dilolosi tanpa memainkan game.

Mode pratinjau

Selagi kamu masih membangun integrasimu, mode pratinjau menyetujui otomatis tiap verifikasi pada key ini, jadi kamu bisa menyambungkan widget dan backend /siteverify-mu tanpa menyelesaikan tantangan sungguhan tiap kali. Widget dan game apa pun yang diwajibkan tetap tampil persis seperti yang dilihat pengunjung; hanya putusan yang dipaksa lolos, dan tiap sesi ditandai sebagai pratinjau. Ia mematikan proteksi bot untuk key, jadi matikan lagi sebelum kamu tayang. Rincian lengkap di Mode pratinjau.

Pemakaian ulang verifikasi

Pemakaian ulang verifikasi membuat satu penyelesaian tetap berlaku selama jendela singkat, jadi pengunjung yang mengulang login yang gagal atau mengisi formulir kedua tak perlu bermain lagi. Fitur ini mati secara baku. Selama menyala, setiap pemuatan widget berikutnya melewati game dan tetap mengembalikan token sekali pakai yang baru, yang diperiksa backend-mu dengan /siteverify seperti biasa. Sebuah izin lolos terikat pada key yang menerbitkannya dan tak pernah meloloskan key lain.

  • Jendela pemakaian ulang (detik) menyetel berapa lama satu penyelesaian terus melewati game: 5 menit secara baku, dibatasi antara 1 dan 30 menit. Jendela ini satu-satunya batas pemakaian ulang, jadi jaga tetap singkat di formulir bernilai tinggi.
  • Ingat lintas muat ulang (cookie) menentukan di mana widget menyimpan izin lolos. Saat mati (nilai bakunya), izin itu tinggal di memori halaman saat ini dan hilang saat dimuat ulang. Saat menyala, widget menyimpannya di cookie sehingga ia bertahan melewati muat ulang dan berlaku di tab lain.

Setiap pengaturan bisa disetel sebagai nilai baku di halaman Keamanan tim, yang diwarisi setiap key dan bisa ditimpanya. Lewat management API dan alat MCP, namanya reuse, reuse_window_ms, dan reuse_persist.

Widget tidak memasang cookie apa pun secara baku. Ia hanya memasang satu cookie saat Pemakaian ulang verifikasi dan Ingat lintas muat ulang (cookie) sama-sama menyala untuk key itu. Jika kamu menyalakan keduanya, cantumkan cookie ini di kebijakan cookie-mu sendiri:

PropertiNilai
Nama__cptr
PihakPihak pertama (first-party): widget menulisnya di peramban pengunjung pada domain situsmu sendiri
AtributSameSite=Strict, Path=/, dan Secure di halaman HTTPS
Masa berlakuMax-Age sama dengan jendela pemakaian ulang (1 sampai 30 menit, 5 secara baku)
IsiHanya izin lolos yang ditandatangani: ID internal kunci situs, game yang dimainkan (jika ada), serta waktu terbit dan kedaluwarsanya. Tanpa pengenal pengunjung.
TujuanMembiarkan pengunjung yang sudah lolos verifikasi melewati game sampai jendela berakhir

Dengan Ingat lintas muat ulang (cookie) mati, pemakaian ulang tidak memasang cookie dan tidak menulis apa pun ke perangkat pengunjung.

Proof of work: Kesulitan dan Tantangan per permintaan

Proof of work membuat peramban memecahkan teka-teki kecil agar penyalahgunaan dalam skala besar jadi mahal (lihat proof of work).

  • Kesulitan (1 sampai 8) menyetel seberapa sulit tiap teka-teki. Lebih tinggi membebani penyerang lebih banyak, tapi juga membebani perangkat pengunjung lebih banyak, yang dirasakan ponsel kelas bawah di ujung atas rentang. Mulai di nilai baku dan naikkan hanya jika kamu benar-benar melihat penyalahgunaan.
  • Tantangan per permintaan (1 sampai 500) meminta beberapa pemecahan sekaligus, melipatgandakan ongkosnya. Biarkan di 1 kecuali kamu punya alasan spesifik untuk menumpuk lebih banyak.

Peramban memecahkan teka-teki ini di sebuah Web Worker, jadi Content-Security-Policy halamanmu harus mengizinkan blob: untuk worker (worker-src blob:); yang satu ini wajib. Membiarkan pemecah berjalan sebagai WebAssembly cepat butuh dua izin sekaligus: 'wasm-unsafe-eval' di script-src supaya ia bisa mengompilasi modulnya, dan origin tempat kamu memuat skrip widget di connect-src supaya ia bisa mengambilnya. Keduanya opsional: kalau salah satu hilang, pemecah jatuh ke implementasi JavaScript murni yang lebih lambat di dalam Worker yang sama dan verifikasi tetap berfungsi, tanpa suara. Lihat sandboxing game untuk kebijakan halaman-host lengkapnya.

Instrumentasi: Tingkat obfuskasi dan Blokir peramban otomatis

Instrumentasi menjalankan program kecil di peramban pengunjung untuk memeriksa bahwa peramban sungguhan, bukan skrip, yang memecahkan tantangan (lihat instrumentasi). Ia menyala secara baku dan merupakan satu-satunya lapis yang membedakan peramban sungguhan dari yang otomatis.

  • Instrumentasi bisa dimatikan per key. Biarkan menyala untuk hampir setiap situs. Matikan hanya jika halaman yang menyematkan widget-mu menjalankan Content-Security-Policy yang tak bisa mengizinkan 'unsafe-eval' (program instrumentasi membutuhkannya, lihat di bawah). Dengan ia mati, key tak bisa lagi mendeteksi peramban otomatis, meski proof of work dan game wajib mana pun tetap berjalan, dan dua pengaturan di bawah berhenti berlaku.
  • Tingkat obfuskasi (1 sampai 10) adalah seberapa sulit program di-peramban itu untuk dibalik-rekayasa. Lebih tinggi lebih kuat tapi memakai lebih banyak CPU server. Nilai bakunya tepat untuk kebanyakan situs; naikkan jika kamu sasaran tetap penyerang bertarget.
  • Blokir peramban otomatis menolak mentah-mentah klien headless dan WebDriver yang terdeteksi. Nyalakan jika tak ada otomasi sah yang pernah menyentuh formulirmu. Biarkan mati jika kamu mengharapkan bot yang sah (pemantauanmu sendiri, integrasi mitra, alat aksesibilitas), karena ia akan memblokir itu juga.

Content-Security-Policy

Program instrumentasi menjalankan eval di peramban pengunjung, jadi halaman yang menyematkan widget-mu harus mengizinkan 'unsafe-eval' di script-src-nya. Ini satu-satunya syarat CSP yang keras dan tak punya cadangan: jika 'unsafe-eval' diblokir, verifikasi habis waktu dan konsol peramban menunjukkan [cap] Instrumentation failed. Kamu punya dua pilihan: izinkan 'unsafe-eval' di halaman yang menjadi host widget, atau matikan Instrumentasi (di atas) untuk menghapus syaratnya. Daftar lengkap yang dibutuhkan CSP halaman-host ada di sandboxing game.

Header wajib

Kamu bisa mewajibkan setiap permintaan membawa header tertentu. Kebanyakan situs tak membutuhkan ini; berguna saat klienmu sendiri selalu mengirim sebuah header yang bisa kamu gerbangi, sebagai filter ekstra yang murah.

Yang tak bisa kamu wajibkan adalah header yang Caputchin singkirkan demi privasi sebelum permintaan pernah mencapai verifikasi. Header itu mengidentifikasi pengunjung, dan sikap Caputchin adalah tidak mengumpulkan data per-pengunjung, jadi ia membuangnya di batas platform:

Header yang disingkirkanMengapa dibuang
cf-connecting-ipIP pengunjung, disetel Cloudflare. Tak pernah menyeberangi batas, jadi Caputchin tak menyimpannya maupun memeriksanya.
x-forwarded-forIP pengunjung seperti terlihat lewat proksi. Alasan yang sama.
x-real-ipIP pengunjung dari proksi hulu. Alasan yang sama.
user-agentString User-Agent pengunjung, yang mengidentifikasi peramban dan perangkat mereka.
sec-ch-ua* (setiap client hint Sec-CH-UA: sec-ch-ua, sec-ch-ua-platform, sec-ch-ua-mobile, dan selebihnya)Bentuk terstruktur dari User-Agent. Batas privasi yang sama.

Mewajibkan salah satunya akan memblokir setiap permintaan, karena ia tak pernah tiba, jadi platform menolak konfigurasi itu alih-alih membiarkanmu mematikan key.

Batas laju dan asal CORS

  • Maks permintaan per detik membatasi seberapa cepat key akan menerima permintaan. Naikkan jika kamu benar-benar bertrafik tinggi; turunkan untuk mencekik sebuah key yang sedang dihantam.
  • Asal CORS adalah daftar izin origin-mu, ditegakkan di sisi server bahkan sebelum teka-teki berjalan. Biarkan kosong selagi kamu menguji dari localhost; sebelum kamu tayang, tambahkan origin nyatamu agar hanya situsmu sendiri yang bisa memakai key.

Lihat juga