Banyak perusahaan merasa proses rilis aplikasi sudah terkendali karena setiap perubahan kode harus melewati repository, review developer, pipeline CI/CD, staging, hingga approval production. Dalam konteks backend dan aplikasi internal, asumsi ini memang cukup masuk akal.

Namun pada aplikasi web modern, kendali tersebut tidak selalu utuh. Ada bagian kode yang dapat berubah tanpa commit dari tim internal, tanpa pull request, tanpa deployment baru, dan tanpa persetujuan dari tim engineering perusahaan.

Bagian itu adalah JavaScript pihak ketiga.

Script analytics, tag manager, iklan, live chat, heatmap, customer support widget, A/B testing, hingga komponen pendukung pembayaran sering dimuat langsung dari domain vendor eksternal. Selama browser pengguna mengambil script tersebut dari pihak ketiga, maka kode yang berjalan di sisi pengguna dapat berubah mengikuti pembaruan vendor.

Di sinilah risiko keamanan frontend mulai muncul.

Rilis Internal Tidak Selalu Menentukan Kode yang Berjalan di Browser

Dalam praktik pengembangan aplikasi, rilis sering dipahami sebagai momen resmi ketika aplikasi berubah. Ada versi baru, ada catatan perubahan, ada jadwal deployment, dan ada pihak yang bertanggung jawab.

Masalahnya, JavaScript pihak ketiga tidak selalu mengikuti ritme tersebut.

Ketika sebuah halaman web memuat script dari vendor eksternal, perusahaan hanya mengendalikan keputusan untuk memasang script tersebut. Setelah itu, isi script dapat berubah di luar pipeline internal perusahaan. Perubahan ini bisa terjadi karena vendor memperbarui fitur, mengubah metode pelacakan, menambahkan integrasi, memperbaiki bug, atau mengalami insiden keamanan.

Bagi pengguna, semua perubahan tersebut tetap terlihat sebagai bagian dari website perusahaan. Mereka tidak membedakan mana kode internal dan mana kode vendor. Jika data bocor dari halaman perusahaan, reputasi perusahaan tetap menjadi pihak pertama yang dipertanyakan.

Inilah sebabnya risiko JavaScript pihak ketiga tidak boleh dianggap sebagai urusan teknis kecil di frontend.

JavaScript Pihak Ketiga Memperluas Batas Kepercayaan Perusahaan

Setiap script yang dimuat di browser pelanggan membawa konsekuensi kepercayaan. Jika script tersebut memiliki akses ke halaman, form, tombol, event input, atau struktur Document Object Model, maka script tersebut dapat membaca dan memengaruhi pengalaman pengguna.

Pada halaman biasa, risikonya mungkin terbatas pada performa atau pelacakan berlebihan. Namun pada halaman login, pendaftaran, pembayaran, checkout, dashboard pelanggan, atau halaman yang memuat data pribadi, risikonya jauh lebih besar.

JavaScript pihak ketiga dapat menjadi bagian dari rantai pasok perangkat lunak. Perusahaan tidak hanya bergantung pada kode internal, tetapi juga pada keamanan vendor, infrastruktur vendor, proses update vendor, dan tata kelola vendor.

Rujukan dari OWASP, CISA, NIST, dan berbagai laporan keamanan aplikasi modern menunjukkan bahwa risiko supply chain tidak lagi hanya terjadi pada dependensi backend atau package open source. Risiko juga dapat muncul dari kode yang dijalankan langsung di sisi pengguna.

Jika kontrol hanya berfokus pada server, repository, dan pipeline internal, maka sebagian risiko client-side akan luput dari pemeriksaan.

Fitur Bisnis yang Sederhana Dapat Membawa Akses yang Luas

Banyak script pihak ketiga dipasang untuk alasan bisnis yang sah. Tim marketing membutuhkan analytics. Tim customer service membutuhkan live chat. Tim produk membutuhkan heatmap. Tim growth membutuhkan A/B testing. Tim pembayaran membutuhkan integrasi pendukung transaksi.

Secara bisnis, semua terlihat masuk akal.

Namun dari sudut pandang keamanan aplikasi web, setiap penambahan script berarti penambahan permukaan risiko. Script yang awalnya hanya digunakan untuk membaca perilaku pengguna dapat berjalan pada halaman yang sama dengan data sensitif.

Risiko meningkat ketika perusahaan tidak memiliki inventaris yang jelas. Misalnya, siapa pemilik script tersebut, halaman mana yang memuatnya, data apa yang dapat tersentuh, dan apakah script masih benar-benar dibutuhkan.

Dalam banyak kasus, script yang dipasang untuk kebutuhan kampanye sementara dapat bertahan bertahun-tahun. Vendor berubah, konfigurasi berubah, tim internal berganti, tetapi script tetap aktif di production.

Masalahnya bukan hanya “ada script eksternal”. Masalah yang lebih besar adalah hilangnya visibilitas atas kode yang berjalan di hadapan pengguna.

Web Skimming Menunjukkan Bahwa Serangan Tidak Selalu Perlu Menembus Server

Salah satu risiko paling serius dari JavaScript pihak ketiga adalah web skimming. Dalam skenario ini, penyerang tidak selalu harus membobol server utama perusahaan. Mereka dapat menyusup melalui script, vendor, konfigurasi tag, atau jalur supply chain lain yang akhirnya berjalan di browser pengguna.

Jika script berbahaya aktif pada halaman pembayaran atau halaman yang memuat data sensitif, penyerang dapat mencoba membaca input pengguna sebelum data tersebut masuk ke sistem backend.

Kasus-kasus terkait Magecart dan serangan client-side supply chain menjadi contoh bahwa browser pengguna adalah titik penting dalam keamanan aplikasi. Serangan seperti ini sering sulit terlihat oleh kontrol tradisional karena aktivitasnya terjadi di sisi klien.

Firewall, hardening server, dan pemantauan infrastruktur tetap penting. Namun kontrol tersebut belum tentu mengetahui bahwa sebuah script di browser sedang mengambil data dari form, memodifikasi halaman, atau mengirim informasi ke endpoint lain.

Di sinilah pendekatan keamanan frontend perlu diperkuat.

CI/CD yang Bersih Belum Tentu Menjamin Frontend yang Aman

Banyak organisasi mulai menerapkan Secure SDLC, code review, scanning dependensi, dan pipeline CI/CD yang lebih ketat. Ini langkah yang baik. Namun pendekatan tersebut belum cukup jika aplikasi masih memuat script pihak ketiga tanpa kontrol yang jelas.

Pipeline internal dapat menunjukkan bahwa build bersih. Repository dapat menunjukkan tidak ada perubahan berbahaya. Deployment dapat berjalan sesuai prosedur. Namun ketika halaman production memuat kode eksternal dari vendor, browser pengguna tetap dapat menjalankan kode yang tidak pernah diperiksa oleh pipeline internal.

Dengan kata lain, keamanan aplikasi web tidak hanya ditentukan oleh apa yang ada di repository. Keamanan juga ditentukan oleh apa yang benar-benar dimuat dan dijalankan di browser pengguna saat aplikasi digunakan.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Masalahnya sering bukan karena perusahaan mengabaikan keamanan. Banyak perusahaan sudah memiliki proses pengembangan yang rapi. Namun fokus pengujian masih terlalu berat ke server, API, autentikasi, dan konfigurasi infrastruktur. Sementara itu, risiko dari third-party script di frontend belum selalu masuk dalam cakupan pemeriksaan yang memadai.

CSP dan SRI Membantu, tetapi Tidak Bisa Diperlakukan sebagai Formalitas

Content Security Policy dapat membantu membatasi sumber script yang boleh dijalankan oleh browser. Dengan CSP, perusahaan dapat mengurangi risiko script dari domain yang tidak diizinkan. Ini merupakan kontrol penting untuk keamanan frontend.

Subresource Integrity juga dapat membantu memastikan file eksternal tidak berubah dari nilai hash yang diharapkan. Jika isi script berubah, browser dapat menolak menjalankannya.

Namun penerapan keduanya tidak selalu sederhana.

Banyak script pihak ketiga memang dirancang untuk sering berubah. Vendor analytics, tag manager, chat widget, dan platform marketing sering memperbarui script secara dinamis. Akibatnya, penggunaan SRI tidak selalu praktis untuk semua jenis script.

CSP juga membutuhkan pemetaan yang rapi. Jika terlalu longgar, perlindungannya menjadi lemah. Jika terlalu ketat tanpa pengujian, fitur bisnis dapat terganggu.

Karena itu, CSP dan SRI sebaiknya dilihat sebagai bagian dari tata kelola keamanan client-side. Keduanya perlu didukung oleh inventaris script, pemantauan perubahan, review vendor, dan pengujian berkala.

Inventaris JavaScript Lebih Penting daripada Sekadar Mengetahui Nama Vendor

Banyak perusahaan merasa sudah cukup aman karena mengetahui vendor apa saja yang digunakan. Padahal, mengetahui nama vendor tidak sama dengan memahami risiko script yang berjalan.

Inventaris JavaScript pihak ketiga perlu menjawab beberapa hal penting:

• Script apa saja yang dimuat di website?
• Script dimuat dari domain mana?
• Script berjalan di halaman apa saja?
• Apakah script berjalan di halaman login, pembayaran, atau halaman data pelanggan?
• Data apa yang mungkin dapat dibaca oleh script tersebut?
• Siapa pemilik bisnis dari script tersebut?
• Apakah script masih aktif digunakan?
• Bagaimana perubahan script dipantau?
• Apakah vendor memiliki standar keamanan yang memadai?

Tanpa inventaris seperti ini, perusahaan akan sulit membedakan script yang masih diperlukan dan script yang sudah menjadi beban risiko.

Dalam konteks tata kelola keamanan digital, pertanyaan paling penting bukan hanya “apakah script ini berguna?”, tetapi juga “apakah manfaat script ini sebanding dengan akses yang diberikan?”

Halaman Sensitif Tidak Seharusnya Dipenuhi Script Pemasaran

Tidak semua halaman memiliki tingkat risiko yang sama. Halaman artikel, halaman kampanye, dan halaman landing page publik mungkin membutuhkan script analytics atau marketing tertentu. Namun halaman login, checkout, pembayaran, dashboard pelanggan, atau form data pribadi seharusnya diperlakukan jauh lebih ketat.

Perusahaan perlu mempertimbangkan pemisahan yang jelas. Script pemasaran tidak selalu perlu berjalan di halaman transaksi. Heatmap tidak selalu perlu aktif di halaman yang memuat data pribadi. Tag manager tidak seharusnya menjadi pintu bebas untuk menambahkan kode baru tanpa review keamanan.

Pendekatan ini bukan berarti menghambat kebutuhan bisnis. Justru sebaliknya, pendekatan ini membantu bisnis tetap berjalan tanpa memperluas risiko secara tidak terkendali.

Frontend modern membutuhkan keseimbangan antara kebutuhan pertumbuhan bisnis dan tanggung jawab perlindungan data pengguna.

Penetration Testing Perlu Melihat Apa yang Terjadi di Sisi Pengguna

Penetration testing aplikasi web sebaiknya tidak hanya memeriksa endpoint, parameter, autentikasi, session management, dan kontrol akses. Pengujian juga perlu melihat bagaimana aplikasi berperilaku di browser pengguna.

Dalam konteks JavaScript pihak ketiga, penetration testing dapat membantu menilai beberapa risiko penting, seperti:

• Apakah halaman sensitif memuat script eksternal yang tidak diperlukan?
• Apakah script pihak ketiga dapat membaca input pengguna?
• Apakah ada data sensitif yang terekspos ke client-side?
• Apakah CSP diterapkan dengan benar?
• Apakah terdapat domain eksternal yang tidak jelas fungsinya?
• Apakah tag manager dapat menjadi jalur perubahan kode tanpa review?
• Apakah ada potensi kebocoran data melalui event tracking?
• Apakah script lama masih berjalan di production?

Pengujian seperti ini membantu perusahaan melihat aplikasi dari sudut pandang yang lebih realistis. Bukan hanya dari sisi kode internal, tetapi dari sisi pengalaman aktual pengguna saat membuka website.

Cara Mengurangi Risiko JavaScript Pihak Ketiga

Perusahaan dapat mulai mengurangi risiko JavaScript pihak ketiga dengan langkah yang terukur.

Pertama, lakukan inventaris seluruh script eksternal yang berjalan di website. Pastikan setiap script memiliki alasan bisnis, pemilik internal, dan dokumentasi yang jelas.

Kedua, kurangi script yang tidak lagi diperlukan. Script lama yang tidak digunakan dapat menjadi risiko pasif yang tidak terlihat, terutama jika masih aktif di halaman production.

Ketiga, pisahkan script berdasarkan jenis halaman. Halaman publik, halaman login, halaman transaksi, dan dashboard pelanggan sebaiknya memiliki kebijakan script yang berbeda.

Keempat, terapkan Content Security Policy secara bertahap. Mulai dari mode pemantauan, lalu perketat kebijakan setelah pola penggunaan script benar-benar dipahami.

Kelima, gunakan Subresource Integrity jika memungkinkan, terutama untuk script statis yang jarang berubah.

Keenam, evaluasi penggunaan tag manager. Pastikan perubahan tag tidak dapat dilakukan tanpa proses review yang jelas.

Ketujuh, lakukan monitoring perubahan script eksternal. Perusahaan perlu mengetahui ketika script vendor berubah secara signifikan.

Kedelapan, masukkan risiko client-side dalam cakupan penetration testing aplikasi web. Hal ini penting terutama untuk website yang memproses data pribadi, transaksi, atau informasi pelanggan.

Kesimpulan

Ketergantungan pada JavaScript pihak ketiga membuat aplikasi web lebih dinamis dan mendukung banyak kebutuhan bisnis. Namun ketergantungan tersebut juga membawa risiko yang sering tidak terlihat dalam proses rilis internal.

Kode frontend dapat berubah tanpa deployment dari perusahaan. Script eksternal dapat berjalan di browser pengguna. Data sensitif dapat tersentuh di sisi klien. Vendor pihak ketiga dapat menjadi bagian dari rantai risiko yang memengaruhi keamanan website perusahaan.

Karena itu, keamanan frontend perlu diperlakukan sebagai bagian penting dari keamanan aplikasi web. Perusahaan perlu mengetahui script apa yang berjalan, siapa yang mengelolanya, data apa yang dapat tersentuh, dan bagaimana perubahan script dipantau.

Jika perusahaan hanya mengamankan backend dan pipeline rilis, sebagian risiko nyata di browser pengguna dapat tetap terbuka.

Fourtrezz dapat membantu perusahaan melakukan pengujian keamanan aplikasi web, vulnerability assessment, dan penetration testing untuk mengidentifikasi risiko pada sisi frontend, backend, API, mobile application, jaringan, serta server. Melalui pendekatan pengujian yang terarah, perusahaan dapat memahami celah keamanan yang benar-benar relevan dengan lingkungan production dan kebutuhan bisnisnya.

Hubungi Fourtrezz:
Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]