Belajar k6 - Keamanan Testing & Best Practice

#Pendahuluan

Di episode 11 kalian kini memegang token, sesi, dan API key di dalam script. Kemampuan itu datang bersama tanggung jawab baru: sebuah load test pada dasarnya adalah trafik nyata yang sangat padat. Salah eksekusi, dan tes yang dimaksudkan untuk mengukur performa bisa memicu alarm keamanan, membanjiri rate limiter, memblokir IP kantor, atau bahkan merusak data lingkungan produksi.

Bayangkan sebuah latihan pemadaman kebakaran di gedung yang benar-benar berpenghuni. Kalian butuh latihan yang realistis, tetapi tidak boleh sampai memadamkan api palsu dengan air yang justru membuat semua orang basah kuyup. Episode ini tentang melakukan latihan itu dengan aman: bagaimana menguji tanpa menghancurkan aturan keamanan aplikasi, bagaimana melindungi kredensial yang kalian gunakan, dan bagaimana memastikan lingkungan produksi tidak menjadi korban.

#Pembahasan Utama

#Load Test Itu Trafik Nyata: Menghormati Aturan Keamanan

Setiap request yang dikirim k6 adalah request sungguhan. Di mata aplikasi, WAF, dan rate limiter, tidak ada perbedaan antara request k6 dan request pengguna. Hal pertama yang harus kalian lakukan sebelum menjalankan tes: komunikasikan dengan pemilik lingkungan. Kapan window pengujian? Berapa beban maksimal yang disepakati? Apakah ada alarm yang bisa dimatikan sementara? Sebuah load test yang dipersiapkan dengan baik adalah pekerjaan kolaborasi dengan tim infra, bukan aksi solo.

#Throttling: Kendalikan Laju, Jangan Menyerang

Salah satu kesalahan terbesar pemula adalah meluncurkan ribuan VU seketika ke endpoint yang sama. Itu bukan beban yang realistis — itu lebih mirip serangan DDoS, dan akan diprediksi oleh WAF sebagai serangan. Solusinya adalah ramp-up yang disengaja:

export const options = {
    stages: [
        { duration: "1m", target: 10 },
        { duration: "3m", target: 50 },
        { duration: "3m", target: 100 },
        { duration: "2m", target: 100 },
        { duration: "1m", target: 0 },
    ],
    thresholds: {
        http_req_failed: ["rate<0.01"],
    },
};

Stages ini menaikkan beban dari 10 ke 100 VU secara bertahap, menahannya, lalu menurunkannya. Ada tiga alasan kenapa ini bukan sekadar sopan santun, tapi teknik yang benar:

• Realistis. Pengguna tidak muncul serentak; mereka datang bertahap. Ramp-up menghasilkan kurva beban yang bisa dibandingkan dengan trafik produksi.
• Terukur. Kalian bisa mengamati di titik berapa latensi mulai memburuk, karena kenaikannya terpantau, bukan ledakan.
• Aman. Sistem rate limiting dan auto-scaling diberi waktu untuk bereaksi secara alami, bukan kewalahan seketika.

#Header Spoofing dan Proteksi Rate Limit: Jangan Berbohong

Ada godaan yang harus kalian lawan: memalsukan header seperti X-Forwarded-For atau mengubah User-Agent secara acak untuk menipu rate limiter agar mengira banyak klien berbeda. Ini salah dengan cara yang berbahaya:

• Kalian sedang menguji perilaku yang tidak pernah terjadi di produksi — rate limiter sungguhan tidak akan membiarkan pola ini. Hasilnya menyesatkan.
• Server bisa mencatat alamat kalian dan memblokir IP kantor atau mesin CI secara permanen.
• Bagi WAF, pola spoofing terlihat lebih mencurigakan daripada trafik k6 biasa.

Jika kalian benar-benar butuh mensimulasikan banyak klien dari banyak alamat IP — misalnya untuk menguji load balancer — k6 menyediakan localIPs untuk memakai banyak alamat IP lokal yang nyata. Dan untuk skala global, distribusi beban dibahas di episode mendatang. Kesimpulannya: ujilah perilaku yang nyata, dengan identitas yang jujur.

#Menangani Secret: __ENV, Bukan Hardcode

Ini aturan paling penting di episode ini, dan melanggar berarti bocornya kredensial produksi ke dalam repository. Menaruh password, token, atau API key di dalam file script adalah undangan untuk kejadian yang paling memalukan di dunia engineering: secret yang ter-commit ke git.

Perbandingan langsung:

const TOKEN = "sk_live_9f8d7c6b5a4e3d2c1b0a"; 
const TOKEN = __ENV.TOKEN; 
 
const params = {
    headers: {
        Authorization: `Bearer ${TOKEN}`,
    },
};

Baris merah adalah bencana yang menunggu terjadi. Baris hijau adalah cara yang benar: nilai datang dari luar script. K6 menyediakan dua mekanisme yang saling melengkapi:

• k6 run -e TOKEN=... script.js — flag -e menyuntikkan nilai ke dalam __ENV yang bisa dibaca script. Ini cara paling umum dan eksplisit.
• --include-system-env-vars — meneruskan environment variable sistem ke __ENV. Perhatikan: k6 run mengaktifkannya secara default, yang berarti seluruh environment shell kalian (mungkin berisi banyak secret) ikut terbaca. Di CI, matikan dengan --include-system-env-vars=false agar tidak ada secret lingkungan yang bocor ke script atau log.

Cara praktisnya:

k6 run -e TOKEN=sk_test_abc123 -e TEST_USER=budi script.js

k6 run --include-system-env-vars=false -e TOKEN="$K6_TOKEN" script.js

Di CI, nilai secret datang dari secret store pipeline (GitHub Actions secrets, GitLab CI variables), dipetakan ke -e saat menjalankan k6. Script kalian tetap bersih, dan nilai berbahaya tidak pernah menyentuh repository.

#Isolasi Lingkungan Uji: Staging, Bukan Produksi

Kebiasaan paling sehat dalam performance testing adalah membatasi diri pada lingkungan yang memang untuk diuji: staging, atau lingkungan yang menyatu-mirip produksi. Alasan yang jelas, plus alasan yang tidak selalu terpikir:

• Data. Akun uji memakai data sintetis, bukan akun pengguna asli. Database staging bisa diisi ulang tanpa konsekuensi hukum atau etika.
• Dampak. Peningkatan latensi atau error saat tes tidak dirasakan pengguna nyata. Tim bisa bebas eksperimen.
• Kesetaraan. Lingkungan yang menyatu-mirip produksi (similar spec, konfigurasi sebanding) memberi angka yang bisa dipercaya — menguji di mesin sekecil apapun hanya membuktikan bahwa tes bisa berjalan.

Jika tes di lingkungan khusus tidak memungkinkan (misal ingin mengukur produksi), batasi dengan jendela waktu, beban yang disepakati, dan akun uji yang terisolasi — lalu pastikan setiap orang yang terlibat menandatangani rencana itu. Ingat juga: __ENV.BASE_URL (pola dari episode 7 dan 11) membuat script yang sama bisa diarahkan ke staging atau produksi tanpa mengubah satu baris pun — gunakan itu, jangan buat dua script yang berbeda.

#Checklist Keamanan Testing

• Kredensial hanya lewat __ENV, diisi saat runtime lewat -e atau secret store CI. Tidak ada secret di script.
• --include-system-env-vars=false di CI agar environment sistem tidak bocor ke script.
• Tidak ada console.log atau log.info yang mencetak nilai token.
• Beban dinaikkan bertahap (stages), laju request dalam batas yang disepakati.
• Tidak ada spoofing header untuk melewati rate limiter.
• Target pengujian adalah staging atau lingkungan uji, dengan data sintetis.
• Rencana tes (waktu, beban, lingkungan) dikomunikasikan dan disetujui pemilik sistem.

#Penutup

Pada episode 12 ini kalian telah menjadikan keamanan bagian dari proses: memahami bahwa load test adalah trafik nyata yang harus menghormati aturan keamanan, menaikkan beban bertahap dengan stages agar tidak menyerang, menolak header spoofing karena hasilnya menyesatkan dan berbahaya, menyuntikkan secret lewat -e dan __ENV alih-alih hardcode, mematikan --include-system-env-vars di CI, serta mengisolasi pengujian di lingkungan staging.

Inti yang harus kalian bawa:

• Tes yang tidak menghormati rate limit adalah serangan, bukan pengukuran.
• Kredensial nyata tidak pernah masuk ke script, commit, atau log.
• -e KEY=value adalah pintu masuk secret; __ENV adalah pintu baca.
• Uji di lingkungan yang menyatu-mirip produksi, dengan data yang aman.

Sekarang tes kalian aman dan jujur. Pertanyaan berikutnya adalah: bagaimana membaca hasilnya dengan benar? Di episode 13 kita akan membahas Analisis Performansi dan Optimasi Scripting — memaknai metrik seperti VU, latensi, p95 dan p99, memangkas overhead JavaScript agar mesin tes tidak berbohong, dan menyusun threshold yang menargetkan SLA atau SLO. Sampai jumpa di episode 13!