Schema Validation untuk Static Site: Perlukah?
Anda benar sekali! Ini adalah pertanyaan yang sangat valid dan menunjukkan pemahaman yang baik tentang arsitektur web. Fitur Schema Validation yang dibahas sebelumnya dirancang untuk API backend yang dinamis. Lantas, bagaimana kaitannya dengan Static Site (Situs Statis) yang hanya menyajikan HTML, CSS, dan JavaScript?
Jawabannya sederhana: Untuk situs statis murni, fitur ini hampir tidak ada gunanya. Mari kita telaah alasannya dan lihat pengecualiannya.
1. Mengapa Schema Validation Tidak Relevan?
Schema Validation bertugas memeriksa struktur data yang dikirimkan oleh klien ke server. Pada situs statis, data yang dikirimkan klien sangat terbatas dan sederhana:
Permintaan yang Dominan adalah GET
Situs statis (yang dihasilkan oleh generator seperti Jekyll, Hugo, atau 11ty) sebagian besar hanya melayani permintaan GET atau HEAD.
- GET Request: Meminta file. Permintaan ini tidak membawa body (payload) data yang kompleks.
- Tujuan Schema Validation: Memeriksa body (payload) dari permintaan POST, PUT, atau PATCH.
Karena Static Site tidak menerima body data yang rumit, tidak ada skema yang perlu divalidasi oleh Cloudflare.
Tidak Ada Logika Backend yang Berbahaya
Ancaman utama yang dilindungi oleh Schema Validation adalah Invalid API Requests yang dapat menyebabkan crash server atau bug logika di backend (misalnya, PHP, Node.js, atau database).
Karena situs statis murni tidak memiliki logika backend yang dieksekusi di server (hanya menyajikan file), ancaman malicious payload melalui API tidak ada.
| Aspek | Situs Dinamis (API) | Situs Statis Murni |
|---|---|---|
| Data Input | Menerima data kompleks (JSON/XML). | Hanya menerima URL/Header sederhana (Tidak ada *payload). |
| Ancaman | Serangan Injeksi, Payload Aneh. | Serangan DDoS/Lalu Lintas (Bandwidth). |
| Relevansi Schema Validation | Sangat Krusial | Tidak Relevan |
2. Pengecualian: Kapan Static Site Butuh Validasi?
Di era modern, jarang sekali situs front-end benar-benar 100% statis. Sebagian besar mengandalkan arsitektur JAMstack yang menggunakan Serverless Functions atau FaaS (Function as a Service) untuk menangani interaksi dinamis.
Contoh Kasus: Anda memiliki Static Site tetapi menambahkan formulir kontak yang mengirimkan data ke Cloudflare Worker atau AWS Lambda melalui metode POST. Worker ini adalah mini-API Anda.
Pada skenario ini, Schema Validation menjadi relevan lagi!
- Target Perlindungan: Bukan lagi Static Site itu sendiri, melainkan endpoint API dari Serverless Function yang menangani formulir kontak atau pencarian Anda.
- Kegunaannya: Anda dapat mendefinisikan skema untuk formulir tersebut. Misalnya, kolom email harus berjenis string dan kolom pesan tidak boleh melebihi 500 karakter. Jika spammer mengirim data acak dengan string 10.000 karakter, Cloudflare akan memblokirnya di lapisan Edge sebelum Worker Anda harus mengonsumsi CPU dan durasi eksekusi yang mahal.
Gambar: Cloudflare menjalankan pemeriksaan Schema sebelum permintaan mencapai origin server.
Kesimpulan Akhir
Jika situs Anda hanya berisi file statis dan tidak ada endpoint POST atau API yang tersembunyi yang ditangani oleh Cloudflare Workers atau sejenisnya, Anda dapat membiarkan Schema Validation nonaktif dan fokus pada pengaturan keamanan lain seperti WAF Rules yang melindungi dari serangan cross-site scripting (XSS) pada parameter URL (meskipun jarang terjadi pada Static Site).
Namun, jika Anda mulai menambahkan fitur dinamis melalui FaaS, segera aktifkan Schema Validation untuk melindungi endpoint kecil tersebut. Perlindungan API perlu selalu diprioritaskan! ✨
Kolom Diskusi
Apakah Anda menjalankan Static Site murni atau sudah menggunakan Serverless Functions? Bagaimana Anda melindungi formulir kontak Anda?