Pipeline CI untuk Tahan Scraper Tanpa Mengganggu Developer

Pipeline CI untuk tahan scraper tanpa mengganggu developer harus dirancang sebagai kontrol delivery, bukan sekadar aturan di edge atau WAF. Masalah utamanya bukan hanya menghentikan traffic otomatis, tetapi memastikan sistem dapat membedakan scraper jahat, crawler yang sah, browser manusia, synthetic monitor, preview deploy, serta tool internal tim seperti CI runner, QA automation, dan integrasi API.

Ini menjadi penting karena proteksi anti-bot yang terlalu agresif sering memutus jalur kerja yang sebenarnya dibutuhkan tim sendiri. Dalam konteks diskusi seputar Anubis, pelajarannya jelas: ukuran keberhasilan bukan sekadar berapa banyak bot yang tertahan, melainkan apakah proteksi itu tetap kompatibel dengan traffic yang memang harus lewat. Jika pipeline CI/CD tidak ikut menguji hal ini, tim baru sadar ada masalah setelah deploy: smoke test gagal, preview tidak bisa dibuka, monitor turun, atau webhook internal mulai 403.

Mengapa anti-scraper sering merusak DX

Anti-scraper modern biasanya bekerja dengan kombinasi sinyal: JavaScript challenge, cookie, fingerprint browser, reputasi IP, rate limit, pola header, hingga perilaku sesi. Teknik ini efektif untuk banyak scraper sederhana, tetapi juga mudah berbenturan dengan tool engineering yang tidak terlihat seperti browser manusia.

Contoh traffic yang sering ikut terdampak:

CI smoke test yang memakai HTTP client biasa tanpa eksekusi JavaScript.
QA automation yang berjalan dari IP cloud runner yang reputasinya buruk atau sering berubah.
Synthetic monitoring yang mengakses endpoint dari banyak region dengan pola periodik.
Preview environment yang dilindungi challenge padahal reviewer butuh akses cepat.
Internal API consumer yang memakai service account, bukan browser.
Crawler baik seperti mesin pencari atau integrasi partner yang memang diizinkan.

Karena itu, implementasi proteksi tidak boleh diperlakukan sebagai konfigurasi statis. Ia perlu masuk ke pipeline CI/CD dengan test case yang mewakili kelas traffic nyata.

Prinsip desain: klasifikasi traffic dulu, baru blokir

Kesalahan umum adalah memulai dari pertanyaan, “bagaimana memblokir bot?” Padahal pertanyaan yang lebih aman untuk sistem produksi adalah, “traffic apa saja yang harus tetap lolos, dan bagaimana membuktikannya di pipeline?”

Kelas traffic yang sebaiknya didefinisikan eksplisit

Browser manusia: user normal dengan challenge atau kontrol minimum yang masih dapat diterima.
Crawler baik: search engine, partner, atau bot yang disetujui dengan jalur akses yang jelas.
Traffic internal non-browser: CI, health checker, synthetic monitor, webhook, service-to-service client.
Tool otomatis tim: Playwright/Cypress, release checker, observability probe, data validation script.
Scraper/abuse: pola request tidak sesuai policy, identitas tidak valid, atau melebihi limit.

Dari klasifikasi ini, buat keputusan per kelas:

Apakah harus diizinkan tanpa challenge?
Apakah cukup dengan token, mTLS, signed header, atau allowlist IP?
Apakah hanya boleh mengakses path tertentu?
Apakah challenge boleh muncul pada preview tetapi tidak pada endpoint health?
Apakah akses internal harus lewat domain terpisah?

Catatan: proteksi yang baik biasanya tidak bergantung pada satu sinyal. IP allowlist saja rapuh, tetapi challenge browser saja juga memutus automation. Kombinasi identitas + path scope + logging biasanya lebih aman dan lebih mudah dioperasikan.

Arsitektur pipeline CI/CD untuk bot protection

Tujuan pipeline bukan menilai apakah vendor anti-bot “cerdas”, tetapi memverifikasi bahwa rule yang diterapkan sesuai kontrak traffic aplikasi Anda. Cara praktisnya adalah memperlakukan bot protection seperti kebijakan akses yang punya test, observability, dan rollback sendiri.

Komponen minimum yang perlu ada

Source of truth rule: definisi rule edge/WAF/reverse proxy dalam bentuk yang bisa direview.
Policy test: serangkaian request yang memverifikasi status code, header, challenge, dan jalur bypass.
Allowlist health check: validasi bahwa identitas internal masih bisa lewat setelah perubahan.
Synthetic verification: probe dari lingkungan yang meniru traffic produksi.
Preview environment check: memastikan reviewer dan QA tidak terkunci.
Emergency bypass: jalur aman untuk tim internal saat proteksi salah konfigurasi.
Structured logging: log yang menjelaskan request diblokir oleh rule mana.
Fast rollback: kemampuan membatalkan rule tanpa menunggu redeploy aplikasi.

Alur delivery yang disarankan

Perubahan rule anti-bot dibuat melalui pull request.
Pipeline menjalankan policy lint dan test terhadap konfigurasi.
Deploy ke preview/staging dengan rule yang sama atau semirip mungkin dengan produksi.
Jalankan smoke test untuk browser nyata, HTTP client internal, monitor, dan partner flow penting.
Promote ke produksi dengan canary atau rollout bertahap.
Pantau metrik block rate, false positive, error synthetic, serta lonjakan 401/403/429.
Jika anomali melewati ambang, rollback rule secara otomatis atau semi-otomatis.

Contoh kontrak perilaku yang harus diuji di CI

Sebelum menulis test, definisikan kontrak yang jelas. Tanpa kontrak, Anda hanya menebak-nebak apakah challenge itu “normal”.

Contoh kontrak akses

GET / dari browser biasa boleh menerima challenge atau halaman normal sesuai policy.
GET /healthz dari internal monitor harus 200 tanpa challenge.
GET /api/internal/report harus menolak user biasa dan hanya menerima token service internal.
GET /robots.txt atau endpoint publik tertentu tetap dapat diakses jika memang dibutuhkan.
GET /preview/<id> harus bisa diakses oleh reviewer dengan mekanisme auth yang tidak bergantung pada fingerprint rapuh.
Request dari runner CI resmi dengan kredensial valid tidak boleh diblokir oleh anti-bot generik.

Kontrak ini lalu diterjemahkan ke test otomatis. Yang diuji bukan hanya status code, tetapi juga apakah challenge muncul di tempat yang salah, apakah header bypass ada, dan apakah cookie/session berjalan konsisten.

Implementasi praktis: rule, bypass, dan verifikasi

1) Pisahkan path publik, internal, dan machine-to-machine

Jangan memaksa semua traffic melewati mekanisme yang sama. Endpoint machine-to-machine lebih stabil jika memakai kredensial eksplisit daripada challenge browser.

Contoh pendekatan:

Publik web: boleh memakai challenge, rate limit, atau behavioral analysis.
Internal status/health: lindungi dengan jaringan privat, token, atau allowlist sempit.
API internal: gunakan service identity, signed token, atau mTLS jika tersedia.
Preview: gunakan auth sederhana yang ramah reviewer, misalnya access token sementara atau basic auth melalui gateway internal.

2) Gunakan bypass internal yang eksplisit dan terbatas

Bypass bukan berarti melemahkan keamanan. Yang berbahaya adalah bypass global yang tidak diaudit. Bypass yang baik bersifat sempit: hanya untuk path tertentu, hanya untuk identitas tertentu, dan terekam di log.

Contoh policy abstrak:

if request.path in ["/healthz", "/readyz"] and request.has_valid_internal_token:
  allow
elif request.path starts_with "/api/internal/" and request.mtls_verified:
  allow
elif request.header["X-CI-Bypass"] is valid and request.source in approved_runners:
  allow_limited
elif request.is_public_web:
  apply_bot_protection
else:
  default_deny

Contoh di atas sengaja generik. Implementasinya bisa berbeda tergantung edge yang dipakai, tetapi idenya sama: identitas internal diverifikasi dengan mekanisme yang lebih deterministik daripada fingerprint browser.

3) Validasi allowlist sebagai health check, bukan asumsi

Banyak tim mengandalkan allowlist IP untuk CI runner, monitor, atau partner. Masalahnya, sumber IP dapat berubah, salah sinkron, atau tidak lengkap. Karena itu, allowlist perlu dicek di pipeline dan juga pasca-deploy.

Minimal, sediakan test yang:

Menjalankan request dari environment runner yang sama dengan produksi CI.
Memastikan endpoint internal kunci tetap 200.
Mendeteksi jika request jatuh ke challenge atau status 403/429.
Mencatat identitas yang dipakai: IP asal, token, header bypass, atau sertifikat klien.

4) Synthetic monitoring harus diuji melawan proteksi nyata

Jangan hanya memonitor uptime aplikasi; monitor juga jalur yang melewati proteksi. Kalau synthetic probe selalu memakai bypass superuser, Anda tidak benar-benar tahu pengalaman user publik atau reviewer preview.

Pola yang aman:

Satu probe meniru browser/user path.
Satu probe meniru internal monitor dengan identitas resmi.
Satu probe menguji negative case, misalnya memastikan endpoint sensitif tetap ditolak tanpa identitas.

5) Preview environment perlu policy khusus

Preview sering terabaikan. Padahal di sinilah friksi developer paling cepat terasa. Jika semua preview diproteksi challenge agresif, reviewer produk, QA, atau integrasi visual regression bisa terhenti.

Beberapa opsi yang lebih ramah DX:

Domain preview di belakang gateway auth internal.
Token sementara yang ditambahkan otomatis ke URL reviewer.
Basic auth khusus preview, dengan audit log dan rotasi.
Pemisahan rule preview dari rule produksi publik.

Trade-off-nya: preview memang sedikit lebih longgar daripada produksi publik, tetapi itu dapat diterima selama tidak memuat data produksi sensitif dan masa hidup akses dibatasi.

Contoh test di pipeline CI

Berikut contoh sederhana menggunakan shell agar idenya mudah dipindahkan ke sistem CI mana pun. Fokusnya adalah memverifikasi kontrak, bukan framework.

set -euo pipefail

BASE_URL="https://preview.example.test"
INTERNAL_TOKEN="$INTERNAL_TOKEN"
CI_BYPASS="$CI_BYPASS"

assert_status() {
  local expected="$1"
  local url="$2"
  shift 2
  local actual
  actual=$(curl -sS -o /tmp/body.txt -w "%{http_code}" "$@" "$url")
  if [ "$actual" != "$expected" ]; then
    echo "Expected $expected but got $actual for $url"
    cat /tmp/body.txt
    exit 1
  fi
}

# Endpoint publik boleh 200 atau challenge yang memang diharapkan.
# Di sini tim perlu menyesuaikan kontraknya.
assert_status 200 "$BASE_URL/"

# Health endpoint internal harus lolos dengan token internal.
assert_status 200 "$BASE_URL/healthz" \
  -H "Authorization: Bearer $INTERNAL_TOKEN"

# API internal tanpa identitas harus ditolak.
assert_status 403 "$BASE_URL/api/internal/report"

# CI bypass hanya untuk path tertentu.
assert_status 200 "$BASE_URL/preview/smoke" \
  -H "X-CI-Bypass: $CI_BYPASS"

# Jangan biarkan bypass membuka semua hal.
assert_status 403 "$BASE_URL/admin/export" \
  -H "X-CI-Bypass: $CI_BYPASS"

Poin penting dari contoh ini:

Test positif memastikan jalur yang harus hidup memang hidup.
Test negatif memastikan bypass tidak terlalu luas.
Kontrak per-path mencegah rule generik merusak endpoint sensitif atau internal.

Logging dan observability yang dibutuhkan

Kalau request diblokir tetapi alasan blokir tidak terlihat, debugging akan lambat dan rollback cenderung panik. Karena itu, log bot protection harus cukup kaya untuk menjawab: siapa diblokir, di path mana, oleh rule mana, dan apakah ini traffic internal yang seharusnya lolos?

Field log yang berguna

request_id atau trace id
path, method, host
decision: allow, challenge, block, rate_limit
rule_id atau nama policy
identity class: public_browser, internal_monitor, ci_runner, partner_bot, unknown
auth context: token valid/tidak, mTLS verified/tidak
source metadata: IP, ASN, region, jika memang tersedia
response status

Dengan struktur ini, Anda bisa membuat query operasional seperti:

Berapa banyak request dari ci_runner yang berubah dari allow menjadi block setelah deploy rule?
Apakah 403 naik pada path preview tetapi traffic publik tetap stabil?
Rule mana yang paling sering memicu false positive?

Metrik yang layak dipantau

Block rate per path group dan identity class
Challenge solve rate untuk traffic browser manusia, jika relevan
False positive rate dari synthetic/internal checks
403/429 rate pasca deploy rule
Smoke test success rate pada preview dan produksi
Mean time to recovery saat rule salah konfigurasi
Deploy interruption rate akibat proteksi anti-bot

Metrik ini penting karena “lebih banyak blokir” bukan tujuan utama. Tujuannya adalah menekan abuse sambil menjaga jalur operasional tetap sehat.

Strategi rollback yang aman

Bot protection harus punya jalur rollback yang lebih cepat daripada rollback aplikasi. Jika perubahan rule disimpan di edge, CDN, WAF, atau gateway, tim harus bisa menonaktifkan atau menurunkan agresivitasnya tanpa menunggu image build baru.

Pola rollback yang disarankan

Feature flag policy: aktif/nonaktifkan rule tertentu.
Mode degradasi: dari block menjadi log-only atau challenge-only.
Scoped rollback: matikan rule hanya untuk path/host tertentu.
Time-limited emergency bypass: akses sementara untuk CI/QA saat insiden.

Trade-off penting: mode log-only lebih aman untuk validasi awal, tetapi tidak menghentikan abuse. Cocok untuk canary rule baru sebelum diubah menjadi mode blokir.

Failure mode umum dan cara mencegahnya

1) Mengandalkan user-agent untuk membedakan bot baik dan buruk

User-agent mudah dipalsukan. Pakai sebagai sinyal tambahan, bukan identitas utama.

2) Allowlist IP terlalu luas atau tidak stabil

Ini sering membuka celah atau justru sering rusak saat IP runner berubah. Batasi scope dan kombinasikan dengan token atau mTLS jika memungkinkan.

3) Semua endpoint diperlakukan seperti halaman web publik

API internal, health check, dan preview punya kebutuhan akses yang berbeda. Pisahkan policy berdasarkan tujuan endpoint.

4) Tidak ada test negatif

Banyak tim hanya menguji “request internal bisa masuk”, tetapi tidak menguji apakah bypass membuka endpoint yang seharusnya tetap tertutup.

5) Tidak ada korelasi log dengan deploy rule

Kalau Anda tidak bisa menghubungkan lonjakan 403 dengan perubahan policy tertentu, investigasi akan lambat. Simpan metadata versi rule di log atau event deploy.

6) Synthetic monitor memakai bypass superuser

Akibatnya dashboard hijau, tetapi user dan QA tetap terblokir. Gunakan beberapa profil synthetic dengan level akses berbeda.

Checklist release untuk perubahan bot protection

Apakah kelas traffic sudah didefinisikan: publik, crawler baik, internal, CI, QA, monitor, partner?
Apakah setiap kelas punya mekanisme identitas yang jelas?
Apakah endpoint health dan readiness bebas dari challenge yang tidak perlu?
Apakah preview environment bisa diakses reviewer dan automation sesuai kontrak?
Apakah allowlist atau kredensial bypass sudah diverifikasi dari runner nyata?
Apakah ada test negatif untuk memastikan bypass tidak terlalu luas?
Apakah synthetic monitor mencakup path publik dan internal?
Apakah log memuat decision, rule_id, dan identity class?
Apakah metrik 403/429/block rate dipantau setelah rollout?
Apakah rollback bisa dilakukan tanpa redeploy aplikasi?
Apakah emergency bypass internal tersedia, sempit, diaudit, dan time-limited?
Apakah perubahan dimulai dari canary atau log-only bila risikonya tinggi?

Cara menilai apakah proteksi membantu atau justru menghambat

Proteksi anti-scraper yang sehat tidak hanya menurunkan abuse, tetapi juga menjaga alur engineering tetap lancar. Gunakan pertanyaan berikut sebagai evaluasi:

Apakah deploy tetap sukses tanpa intervensi manual tambahan?
Apakah QA automation dan preview review masih berjalan stabil?
Apakah observability tetap akurat, atau synthetic probe malah sering false alarm?
Apakah API internal dan webhook penting tetap dapat diakses dengan identitas mesin?
Apakah tim support dan on-call bisa menjelaskan alasan blokir dengan cepat dari log?
Apakah false positive turun seiring perbaikan rule, bukan naik diam-diam?

Kalau jawaban untuk poin-poin ini buruk, besar kemungkinan proteksi Anda sedang memindahkan biaya dari abuse ke operasional tim sendiri.

Penutup

Pipeline CI untuk tahan scraper tanpa mengganggu developer pada dasarnya adalah soal disiplin klasifikasi traffic dan verifikasi kontrak akses. Anti-bot yang baik bukan yang memblokir paling banyak, melainkan yang membedakan browser nyata, crawler yang diizinkan, traffic internal, dan automation tim sendiri secara konsisten.

Masukkan rule bot protection ke workflow delivery seperti komponen sistem lain: ada test, preview validation, allowlist health check, synthetic monitoring, logging, dan rollback. Dengan begitu, tim tidak perlu memilih antara perlindungan dari scraper dan DX yang sehat; keduanya bisa dicapai jika proteksi dirancang sebagai bagian dari pipeline, bukan tambahan di menit terakhir.

Quick Search

shopping_cart Keranjang