Model Keamanan

Halaman ini menjawab satu pertanyaan jujur: apa yang sebenarnya Shield lakukan, dan apa yang tidak. Keamanan yang baik dimulai dari mengetahui batas Anda.

Apa yang tidak dilakukan Shield

Bukan pengganti validasi input

Shield bisa memblokir payload union select yang melewati body, tapi aplikasi Anda harus tetap memvalidasi dan meng-escape seluruh input. Filter SQL, validasi form, serta proteksi CSRF adalah milik Anda — bukan pekerjaan Shield.

Bukan pengganti CSP atau escaping

Header Content-Security-Policy dan X-Content-Type-Options tetap harus dikirim oleh aplikasi Anda. Shield menambahkan lapisan deteksi, bukan menggantikan praktik XSS yang benar.

Bukan pengganti autentikasi dan otorisasi

Shield tidak tahu siapa pengguna Anda. Keamanan session, gate, dan izin adalah tanggung jawab Anda (apakah memakai codeigniter4/shield, package lain, atau buatan sendiri).

Bukan pengganti patch

Shield tidak berguna terhadap serangan yang menimpa CVE yang sudah diketahui pada komponen Anda. Selalu perbarui CodeIgniter dan dependensi.

Bukan WAF di layer CDN

Shield berjalan di dalam aplikasi. Traffic sudah sampai ke server Anda sebelum Shield melihatnya. Untuk memblokir banjir bandwidth atau serangan DDoS di level jaringan, tetap gunakan Cloudflare / WAF hosting.

Batasan teknis yang perlu Anda tahu

Batas	Nilai	Konfigurasi
Body yang diperiksa	64 KB	bodyInspectionMaxBytes
Panjang URI yang diproses	2048 karakter	maxUriLength
Kedalaman decode URI	2	decodeDepth
Jendela perilaku	60 detik	behaviorWindowSeconds
Basis penghitung	per IP	—

• Body dibatasi 64 KB. Payload lebih besar dipotong untuk diperiksa.
• URI dipotong setelah 2048 karakter.
• decodeDepth maksimum praktis 3 — Shield mendecode URI berulang kali tetapi berhenti agar pola tetap bisa dibaca.
• Rate limit dihitung per IP. Dengan proxyIPs yang salah, semua pengguna “menjadi” satu IP.

Data yang disimpan

security_ip_bans

Satu baris per ban: IP, status (active/released/expired), reason, rule terakhir yang memicu, skor risiko, jumlah offense, waktu ban dibuat dan berakhir, serta metadata riwayat release/extension.

security_events

Satu baris per peristiwa: IP, host, URL (disamarkan), metode HTTP, rule yang memicu, severity, keputusan, dan skor. Baris ini yang dibersihkan oleh shield:prune berdasarkan retentionDays.

Privasi

Parameter yang disamarkan

Nilai parameter query yang masuk daftar sensitiveQueryParameters (token, password, key, secret, code, auth, dan lain-lain) disamarkan sebelum URL disimpan ke database:

/login?password=ADA_SANITIZED_20260101_120000_ABC12DEF

Data yang tetap terekam

Shield menyimpan: IP, host, URL, metode, User-Agent, dan ringkasan keputusan. Semua itu sengaja direkam agar Anda bisa menyelidiki insiden. Kalau regulasi Anda melarang menyimpan IP, sesuaikan loggingLevel atau atur pembersihan retentionDays lebih pendek.

Batasan infrastruktur

404 tanpa route

Dengan registrasi tanpa gate (bawaan paket), shield.firewall berada di globals['before'] yang berjalan setelah router. Request ke path yang tidak cocok route (mis. /.env, /etc/passwd) berhenti di PageNotFoundException sebelum filter berjalan, sehingga tidak tercatat dan tidak diblokir.

Untuk menutupinya di dalam aplikasi, pasang ShieldGateFilter di required['before'] dan hapus shield.firewall dari globals['before']. Pola ini dipakai sebagai default di Instalasi; penjelasan lengkapnya ada di Registrasi & Urutan Filter. Kalau memilih registrasi tanpa gate, path tanpa route harus ditangani WAF di depan (Cloudflare, ModSecurity) atau aturan mod_rewrite di server.

Query string tidak diperiksa

Adapter firewall memakai rawUri = path saja (tanpa query). Semua rule berbasis query (mis. payload.sqli.union, payload.query.traversal) tidak akan pernah match. Probe seperti GET /?file=../../../etc/passwd tetap 200 selama path dan body bersih. Untuk menutupinya, gunakan WAF di depan atau override buildContext() di sisi aplikasi.

Cookie trusted hardcoded secure: true

ChallengeController::verify() memanggil setCookie(..., secure: true, ...) tanpa memperhatikan protokol koneksi. Ini memicu SecurityException bila diakses via HTTP murni (bukan HTTPS/localhost). Di development, gunakan https://localhost atau tambahkan after-filter yang menyalin cookie Secure menjadi non-secure hanya saat !$request->isSecure().

Kalau database mati

Ban sesaat tetap ditegakkan lewat cache. Kalau tidak tersimpan juga, failMode menentukan sikap:

failMode	Perilaku
open (default)	Lookup ban dilewati dan infrastructureDegraded diset. Request belum tentu lolos: signature dan sinyal perilaku lain tetap dinilai. Exception yang lolos ke filter diteruskan.
closed	Lookup ban yang gagal menghasilkan blok dengan responseCode (default 404) dan skor 99. Exception yang lolos ke filter menghasilkan 503.

Petunjuk lengkapnya ada di Konfigurasi.

Kalau cache mati

Penghitung perilaku dilewati (semua counter = 0). Pencocokan signature tetap berjalan. Lookup ban aktif juga gagal karena cache dibaca lebih dulu, sehingga sikapnya kembali ditentukan failMode di atas.

Kalau DNS mati

Verifikasi crawler gagal → semua klaim bot dianggap tidak terverifikasi dan mendapat unverifiedClaimSignal. Situs tetap hidup, tapi Googlebot asli bisa terkena dampak sinyal itu. shield:health membantu mendeteksi kondisi ini.

Keterbatasan yang perlu Anda ketahui

• URI tanpa route (404) hanya diperiksa jika Shield dipasang di required['before']. Dengan registrasi tanpa gate (globals['before']), CodeIgniter melempar PageNotFoundException sebelum filter berjalan. Instalasi default memasang gate ini; lihat Registrasi & Urutan Filter untuk detailnya.
• Kunjungan normal ke halaman publik bisa menaikkan counter perilaku. SecurityFirewallFilter::before() menaikkan counter sebelum memutuskan. Pola gate dapat mengembalikan counter untuk GET/HEAD yang diizinkan; lihat halaman yang sama.
• Request ke route yang ada tapi menghasilkan 404 dari controller tetap terhitung oleh filter after dan berkontribusi pada penghitung not_found.

Yang tetap menjadi tanggung jawab Anda

1. Memasang Shield di setiap aplikasi yang bisa diakses publik.
2. Mengatur proxyIPs agar IP asli benar.
3. Membaca shield:report dan menyesuaikan ambang.
4. Menjadwalkan shield:prune agar data tidak menggunung.
5. Melakukan hardening dasar lain: matikan display_errors di produksi, pisahkan app/ dan public/, dan jangan pernah menaruh file sensitif di folder yang bisa diakses web.