Gabungkan validasi server, token antibot terverifikasi, dan pembatasan permintaan yang wajar. Spam tidak dapat ditangani hanya dengan menyembunyikan alamat endpoint atau menonaktifkan tombol kirim. Permintaan berulang dengan kunci sama dapat mengambil hasil sebelumnya tanpa membuat entri baru. Menampilkan widget tanpa memeriksa token belum cukup.
Gunakan perlindungan berlapis
Spam tidak dapat ditangani hanya dengan menyembunyikan alamat endpoint atau menonaktifkan tombol kirim. Endpoint dapat dipanggil langsung. Server harus memvalidasi bentuk data, panjang nilai, ukuran keseluruhan, origin yang diizinkan, dan jenis konten. Bidang jebakan dapat membantu menyaring bot sederhana, tetapi harus tidak mengganggu pengguna keyboard atau pembaca layar.
Turnstile menambahkan sinyal pemeriksaan, bukan menggantikan validasi data. Token dari browser perlu dikirim ke verifikasi server resmi. Periksa keberhasilan, hostname, dan action sesuai konfigurasi. Kunci publik boleh berada di halaman; secret hanya boleh tersedia di lingkungan server. Mode test resmi perlu dibatasi ke pengembangan lokal dan tidak terbawa sebagai konfigurasi produksi.
Kendalikan pengulangan tanpa kehilangan permintaan sah
Batasi frekuensi permintaan secara terukur. Gunakan pengenal yang diminimalkan, misalnya hash dengan kunci, dan jangan mencatat alamat IP mentah tanpa kebutuhan serta kebijakan yang jelas. Batas terlalu ketat dapat merugikan beberapa pengguna pada jaringan bersama, sehingga pesan kesalahan harus menjelaskan kapan mencoba lagi tanpa membocorkan rincian pertahanan.
Idempotensi menyelesaikan masalah berbeda: satu pengiriman yang diulang karena jaringan lambat sebaiknya menghasilkan satu catatan. Simpan kunci permintaan bersama sidik muatan dan lakukan operasi secara aman terhadap permintaan bersamaan. Kunci sama dengan isi berbeda harus ditolak. Jangan memakai pemeriksaan “cari lalu simpan” yang dapat berlomba tanpa perlindungan database.
Rancang kegagalan yang jujur
Jika token kedaluwarsa, beri cara mengulang pemeriksaan sambil mempertahankan isian. Jika database tidak tersedia, jangan tampilkan sukses atau membuat nomor referensi palsu. Pesan publik cukup menjelaskan tindakan yang dapat dilakukan; log internal tidak boleh memuat seluruh nama, email, deskripsi proyek, atau token.
Uji jalur yang ditolak dan diterima menggunakan data sintetis. Pemeriksaan penting mencakup token salah, ukuran berlebihan, origin salah, percobaan bersamaan, serta kegagalan penyimpanan. Lindungi akses admin dan ekspor karena keamanan formulir tidak berhenti setelah data diterima. Tentukan masa simpan dan pembersihan yang disetujui pemilik sebelum mengaktifkan pengumpulan publik.
Daftar periksa praktis
- Validasi bidang
- Verifikasi Turnstile
- Cegah duplikasi
Contoh konkret: Permintaan berulang dengan kunci sama dapat mengambil hasil sebelumnya tanpa membuat entri baru.
Batas yang perlu jelas: Menampilkan widget tanpa memeriksa token belum cukup.
Langkah berikutnya
Ceritakan proyek Anda kepada Orvunweb
