WAF Cerdas Bukan WAF Galak, Challenge yang Mahal Saja

Homepage melambat, login bikin frustasi, search internal sering timeout, lalu Googlebot ikut seret. Akar masalahnya sering bukan trafik tinggi, melainkan proteksi yang salah sasaran. Kalau semua request kamu challenge, manusia capek, crawler bingung, origin tetap kerja keras.

Serving strategies yang sehat justru kebalikannya. Bukan semua traffic ditahan, tetapi hanya path mahal yang diberi challenge, rate limit, atau pemeriksaan tambahan. Hasilnya, UX tetap enak, crawlability aman, dan resource server dipakai buat request yang memang penting.

Apa itu serving strategies yang selektif?

Serving strategies adalah cara kamu membedakan perlakuan per URL, per metode request, per reputasi client, dan per biaya komputasi. Jadi, bukan semua request diperlakukan sama. Ini penting, karena biaya melayani / jelas beda dengan /wp-login.php, /search?q=..., atau endpoint API yang memicu query database berat.

Masalah muncul saat tim security menyamaratakan semua traffic. Akibatnya, homepage, halaman artikel, feed, bahkan asset statis ikut kena JavaScript challenge, CAPTCHA, atau rate limiting agresif. Memang bot turun sedikit, tetapi conversion, crawl budget, dan latency sering ikut turun banyak.

Kenapa overprotection bikin rugi?

1. Manusia kena friksi yang seharusnya nggak perlu

User datang untuk baca, login, beli, atau pakai API. Kalau halaman publik ikut dipagari challenge, banyak yang mental di tengah jalan. Apalagi di mobile, jaringan lambat, atau browser enterprise yang ketat.

2. Crawler ikut melambat

Search engine butuh akses stabil, ringan, dan konsisten. Jika bot legit terus diminta solve challenge atau kena 403 acak, crawling bisa berkurang. Google sendiri menyarankan status code yang jelas dan akses yang dapat dirayapi untuk konten publik, lihat Google Search Central.

3. Origin tetap boros

Ini yang sering luput. Banyak challenge dipasang setelah request sudah menyentuh layer yang mahal, misalnya cache miss, WAF kompleks, atau query app. Jadi, proteksi terasa galak, tetapi biaya origin tetap tinggi.

Prinsip utamanya, challenge biaya, bukan popularitas

Strategi matang melihat cost per request, bukan sekadar volume traffic. Homepage bisa menerima 100 ribu hit dan tetap murah kalau full cache. Sebaliknya, endpoint search dengan 1.000 hit bisa jauh lebih mahal karena memicu query, sorting, dan render dinamis.

Karena itu, path yang layak diproteksi ketat biasanya seperti ini:

• Login, auth callback, reset password.
• Search, terutama yang query-nya bebas.
• Cart, checkout, coupon validation.
• API dengan lookup DB, AI call, PDF render, export, scraping target.
• Form yang rawan spam atau abuse.

Sebaliknya, path yang biasanya sebaiknya ringan dulu:

• Homepage dan landing page publik.
• Artikel blog yang full cache.
• File statis, image, CSS, JS.
• Halaman dokumentasi publik yang dibaca crawler dan user.

Framework praktis, klasifikasi 4 lapisan path

Kalau kamu butuh aturan cepat, pakai framework ini.

Lapisan 1, Cheap and Public

Contoh, homepage, artikel, category, file cache. Fokusnya ke cache hit tinggi, bot allowlist seperlunya, dan observability. Jangan challenge default di sini.

Lapisan 2, Public but Abuse-Prone

Contoh, form komentar, newsletter, search ringan. Gunakan rate limit lembut, anomaly scoring, honeypot, atau proof-of-work ringan. Jadi, user asli masih mulus.

Lapisan 3, Expensive and Sensitive

Contoh, login, password reset, search berat, endpoint report, GraphQL rumit. Di sini challenge masuk akal. Tambah device reputation, per-IP quota, burst control, dan pembatasan method.

Lapisan 4, High-Risk Automation

Contoh, credential stuffing, token spray, inventory scraping, brute force API. Ini wilayah block keras, tarpit, deny rule, atau challenge berlapis.

Kerangka ini lebih efektif daripada pola malas seperti, pasang CAPTCHA untuk semua orang. Sedikit lebih rumit di awal, tetapi jauh lebih sehat buat uptime dan SEO.

Taktik yang sering lebih efektif daripada CAPTCHA global

• Cache everything untuk konten publik. Challenge yang paling murah adalah request yang tidak pernah menyentuh origin.
• Method-based policy. GET publik longgar, POST sensitif ketat.
• Per-path rate limit. Login 5 per menit beda dengan homepage 500 per menit.
• Token bucket per reputasi. ASN buruk, IP anonim, atau UA aneh dapat jatah lebih kecil.
• Search cost guard. Batasi panjang query, wildcard, pagination dalam, dan sort mahal.
• API shielding. Wajibkan auth, signature, atau usage plan untuk endpoint mahal.

Kalau kamu pakai WordPress, pendekatan ini nyambung dengan isu yang pernah saya bahas di WAF terlalu galak dan dampaknya ke SEO. Intinya sama, proteksi harus presisi.

Yang sering salah dipahami tim ops

Banyak orang mengira, makin banyak challenge berarti makin aman. Nyatanya, challenge yang disebar ke semua path sering hanya memindahkan beban. User asli ikut repot, crawler ikut tersendat, sedangkan attacker pindah ke endpoint yang memang mahal.

Pendekatan yang lebih matang justru begini. Biarkan jalur murah tetap cepat. Kumpulkan sinyal di jalur publik. Lalu, gunakan sinyal itu saat request masuk ke jalur mahal. Cloudflare juga berkali-kali menekankan pentingnya mitigasi berbasis sinyal dan konteks, bukan friksi merata, lihat dokumentasi mereka tentang WAF dan bot management.

Checklist implementasi untuk developer, SRE, dan site owner

• Petakan endpoint berdasarkan biaya CPU, DB, dan cacheability.
• Pisahkan rule untuk GET, POST, dan endpoint auth.
• Whitelist crawler legit untuk konten publik, tetap monitor abuse.
• Tambahkan challenge hanya di path mahal atau pola serangan spesifik.
• Ukur 403, 429, TTFB, cache hit ratio, login success rate, dan crawl stats.
• Audit search internal dan API, karena biasanya paling cepat bikin origin tumbang.

FAQ

Apakah homepage perlu challenge juga?

Biasanya nggak. Kalau homepage full cache dan publik, lebih aman dibuat cepat dan ringan. Challenge baru relevan bila ada pola abuse yang jelas dan belum tertangani di edge.

Bagaimana dengan halaman login?

Login termasuk path mahal dan sensitif. Jadi, cocok untuk rate limit ketat, bot detection, MFA, dan challenge adaptif saat sinyal risiko naik.

Apakah strategi ini membantu SEO?

Iya. Crawler lebih mudah mengakses konten publik, latency turun, dan false positive ke bot legit berkurang. Semua ini mendukung crawl efficiency dan kualitas pengalaman halaman.

Bagaimana tahu sebuah path itu mahal?

Lihat cache miss, query DB, konsumsi CPU, upstream time, dan frekuensi error saat traffic naik. Path mahal hampir selalu terlihat jelas di log dan APM.

Intinya sederhana. Jangan jadikan semua traffic sebagai tersangka. Lindungi jalur yang mahal, kurangi friksi di jalur publik, lalu ukur dampaknya dengan disiplin. Kalau kamu mengelola WordPress, API, atau edge rule di CDN, pola ini sering memberi hasil paling cepat tanpa bikin SEO ikut babak belur.

Kalau kamu pernah lihat homepage aman tetapi login, search, atau API tiba-tiba jadi biang bottleneck, tulis pengalamanmu di komentar. Atau, simpan artikel ini buat bahan audit rule WAF timmu.