Portal pelanggan yang lebih cepat hampir selalu dipandang sebagai perbaikan. Waktu muat berkurang, permintaan ke server utama menurun, dan pengalaman pengguna menjadi lebih baik. Karena itu, penggunaan Content Delivery Network (CDN), reverse proxy, dan mekanisme cache semakin umum dalam arsitektur aplikasi modern.

Namun, performa bukan satu-satunya hal yang berubah ketika strategi cache diperluas.

Pada portal yang menampilkan data berbeda untuk setiap pengguna, keputusan tentang halaman mana yang boleh disimpan di cache secara tidak langsung juga menjadi keputusan mengenai batas akses data. Kesalahan kecil pada konfigurasi dapat membuat respons yang awalnya hanya tersedia setelah login justru tersimpan pada shared cache dan berpotensi diberikan kepada pengguna lain.

Pada titik tersebut, optimasi performa telah berubah menjadi persoalan keamanan aplikasi.

Cache Menjadi Persoalan Keamanan Ketika Respons Sudah Mengenal Pengguna

Menyimpan logo, stylesheet, JavaScript, gambar produk, atau aset publik lainnya di cache relatif mudah dipahami. Kontennya memang ditujukan untuk banyak pengguna sehingga menggunakan kembali respons yang sama biasanya tidak menimbulkan persoalan akses.

Situasinya berbeda pada portal pelanggan.

Setelah pengguna login, aplikasi dapat menampilkan nama, alamat, riwayat transaksi, invoice, dokumen, status layanan, detail organisasi, konfigurasi akun, atau informasi lain yang hanya boleh dilihat oleh pemilik akun tersebut.

Respons semacam ini tidak lagi sekadar halaman web. Respons tersebut membawa konteks identitas dan hak akses.

Karena itu, begitu konten berbeda berdasarkan siapa yang sedang menggunakan aplikasi, strategi cache perlu diperlakukan sebagai bagian dari desain keamanan.

Pertanyaan yang perlu diajukan bukan hanya, “Apakah halaman ini bisa dibuat lebih cepat?”, tetapi juga, “Jika respons ini disimpan, siapa yang dapat menerimanya kembali?”

Perbedaan kedua pertanyaan tersebut terlihat sederhana, tetapi konsekuensinya sangat besar.

Memerlukan Login Tidak Otomatis Membuat Sebuah Respons Aman dari Cache

Salah satu asumsi yang cukup berbahaya adalah menganggap semua halaman di balik login otomatis terlindungi dari mekanisme caching.

Pada arsitektur modern, permintaan pengguna tidak selalu langsung mencapai aplikasi.

Alurnya dapat melewati beberapa komponen:

Pengguna → CDN → WAF → reverse proxy → load balancer → aplikasi

Setiap komponen dapat memiliki aturan pemrosesan dan caching sendiri.

Aplikasi mungkin sudah melakukan autentikasi dengan benar. Pengguna harus memasukkan kredensial, memiliki session yang valid, dan melewati pemeriksaan authorization sebelum menerima halaman tertentu.

Namun, mekanisme tersebut tidak otomatis menjamin bahwa respons yang dihasilkan tidak disimpan oleh layer lain di depannya.

Jika respons personal masuk ke shared cache karena aturan yang terlalu luas, request berikutnya dapat memperoleh salinan respons tersebut dari cache tanpa melalui jalur aplikasi dengan cara yang sama seperti request pertama.

Artinya, keamanan tidak cukup dinilai hanya dari apakah endpoint membutuhkan login.

Tim juga perlu mengetahui bagaimana respons dari endpoint tersebut diperlakukan setelah meninggalkan aplikasi.

Ketika CDN dan Aplikasi Memahami URL dengan Cara yang Berbeda

Salah satu risiko yang berkaitan erat dengan kondisi ini dikenal sebagai web cache deception.

Masalahnya muncul ketika aplikasi dan sistem cache memiliki interpretasi berbeda terhadap sebuah URL.

Bayangkan aplikasi memiliki halaman:

/account/profile

Halaman tersebut bersifat dinamis dan hanya dapat dilihat oleh pengguna yang sudah login.

Kemudian terdapat request dengan pola seperti:

/account/profile/image.css

Pada konfigurasi tertentu, aplikasi mungkin tetap mengarahkan request tersebut ke handler halaman profil karena routing menganggap bagian tambahan pada URL tidak penting.

CDN dapat memiliki pandangan berbeda.

Karena URL berakhir dengan .css, mekanisme cache mungkin menilainya sebagai aset statis yang aman disimpan.

Akhirnya terjadi dua interpretasi terhadap request yang sama:

Aplikasi melihat halaman profil pelanggan.

Cache melihat file statis.

Jika respons halaman profil kemudian disimpan sebagai objek cache, informasi personal dapat berada di tempat yang semestinya digunakan untuk mendistribusikan konten kepada banyak pengguna.

Penelitian keamanan yang dipresentasikan pada USENIX Security menunjukkan bahwa masalah seperti ini bukan sekadar skenario teoritis. Pengujian terhadap situs nyata menemukan kerentanan web cache deception yang dapat mengekspos informasi pengguna dan, pada kondisi tertentu, bahkan informasi yang berkaitan dengan autentikasi atau authorization.

Hal ini menunjukkan satu prinsip penting: cache bukan teknologi yang dapat dipasang kemudian diasumsikan aman tanpa memahami bagaimana aplikasi melakukan routing dan mengelola identitas pengguna.

Masalah Sering Muncul dari Konfigurasi yang Secara Terpisah Terlihat Benar

Kerentanan cache menarik karena penyebabnya tidak selalu berupa satu konfigurasi yang terlihat jelas salah.

Developer dapat berpikir:

Endpoint ini aman karena hanya dapat digunakan setelah login.

Tim infrastruktur dapat berpikir:

File dengan ekstensi tertentu aman disimpan di CDN.

Tim DevOps dapat berpikir:

Semakin banyak request yang dapat dijawab dari edge, semakin rendah beban origin.

Semua asumsi tersebut dapat masuk akal jika dilihat secara terpisah.

Masalah baru terlihat ketika seluruh komponen bekerja bersama.

Aplikasi memahami routing berdasarkan pola tertentu. CDN menentukan objek cache berdasarkan aturan lain. Reverse proxy melakukan normalisasi URL. Session dikelola melalui cookie. Cache key hanya memperhitungkan bagian tertentu dari request.

Tidak ada satu komponen pun yang harus benar-benar “rusak” agar kebocoran terjadi.

Cukup ada perbedaan asumsi di antara beberapa layer.

Inilah alasan keamanan aplikasi modern tidak dapat hanya dinilai dari source code. Perilaku sistem setelah aplikasi ditempatkan di belakang CDN, WAF, proxy, serta berbagai layanan infrastruktur juga perlu diuji.

Cache Key Dapat Menentukan Apakah Dua Pengguna Dianggap Sama

Salah satu bagian terpenting dari mekanisme caching adalah cache key.

Cache membutuhkan identitas untuk menentukan apakah sebuah request baru dapat menggunakan respons yang sebelumnya sudah disimpan.

URL biasanya menjadi bagian penting dari cache key. Namun, implementasi dapat pula mempertimbangkan query parameter, header, cookie, host, perangkat, atau atribut lainnya.

Permasalahan muncul ketika informasi yang digunakan aplikasi untuk membedakan pengguna tidak diperhitungkan dengan tepat oleh sistem cache.

Bayangkan dua pengguna meminta resource dengan URL yang sama.

Dari perspektif aplikasi, keduanya berbeda karena memiliki session yang berbeda. Karena itu, respons yang diberikan seharusnya juga berbeda.

Namun, jika shared cache hanya melihat URL dan menganggap kedua request tersebut identik, respons milik pengguna pertama berpotensi digunakan ketika pengguna kedua melakukan request.

Pada aplikasi multi-tenant, konsekuensinya dapat lebih serius. Kesalahan desain cache key dapat menyebabkan data sebuah organisasi tersedia dalam konteks organisasi lain.

Karena itu, desain cache key bukan sekadar keputusan optimasi performa. Dalam aplikasi yang memiliki authentication, authorization, atau tenant isolation, cache key juga merupakan bagian dari model keamanan.

“Cache Everything” Perlu Diperlakukan sebagai Perubahan Arsitektur Keamanan

Dalam proses optimasi, organisasi terkadang memperluas aturan cache untuk mengurangi beban origin server.

Perubahan tersebut dapat berupa peningkatan Edge Cache TTL, aturan wildcard yang lebih luas, pengabaian query tertentu, perubahan cache key, hingga kebijakan untuk menyimpan lebih banyak halaman di CDN.

Tujuannya masuk akal.

Masalah muncul jika perubahan tersebut hanya dinilai melalui metrik performa.

Misalnya, setelah konfigurasi baru diterapkan:

• latency turun;
• origin request berkurang;
• penggunaan resource server menurun;
• halaman terasa lebih cepat.

Secara operasional, proyek tersebut terlihat berhasil.

Namun keberhasilan itu belum lengkap jika tim belum memastikan bahwa halaman personal, API response, dokumen pelanggan, atau informasi berbasis session tidak ikut masuk ke shared cache.

Perubahan kebijakan caching sebaiknya diperlakukan seperti perubahan konfigurasi authorization: perlu ditinjau, diuji, dan diverifikasi sebelum digunakan secara luas.

Cache-Control yang Keliru Dapat Membuat Respons Privat Menjadi Terlalu Luas

HTTP sebenarnya menyediakan mekanisme untuk memberi tahu cache bagaimana sebuah respons harus diperlakukan.

Salah satu directive penting adalah:

Cache-Control: private

Directive ini menunjukkan bahwa sebuah respons hanya boleh disimpan oleh private cache, seperti cache pada browser pengguna, dan tidak ditujukan untuk shared cache.

Untuk respons yang sama sekali tidak seharusnya disimpan, terdapat:

Cache-Control: no-store

Perbedaan directive ini penting terutama untuk halaman setelah login atau respons yang mengandung data personal.

Kesalahpahaman juga sering terjadi pada:

Cache-Control: no-cache

Namanya memang terdengar seperti perintah untuk tidak menyimpan respons. Namun, no-cache pada dasarnya berkaitan dengan keharusan melakukan validasi sebelum respons digunakan kembali, bukan larangan mutlak untuk menyimpannya.

Perbedaan kecil dalam terminologi HTTP dapat memiliki konsekuensi besar jika diterapkan pada sistem yang melayani data sensitif.

Lebih jauh lagi, header dari origin bukan satu-satunya faktor. Kebijakan pada CDN atau reverse proxy juga dapat memengaruhi bagaimana respons diperlakukan.

Karena itu, pemeriksaan keamanan perlu melihat konfigurasi secara end-to-end, bukan hanya satu header pada aplikasi.

Kebocoran Tidak Harus Membuka Seluruh Akun untuk Menjadi Serius

Dalam diskusi keamanan, perhatian sering langsung tertuju pada account takeover.

Padahal kebocoran informasi dari cache tidak harus memberikan kendali penuh terhadap akun untuk menghasilkan dampak serius.

Data yang terekspos dapat berupa:

• nama dan informasi pelanggan;
• email;
• alamat;
• informasi langganan;
• invoice;
• histori transaksi;
• informasi perusahaan;
• konfigurasi akun;
• dokumen internal;
• status permintaan atau layanan;
• informasi identitas;
• data lain yang hanya tersedia setelah login.

Dalam beberapa aplikasi, satu halaman dashboard saja sudah dapat memberikan gambaran cukup besar mengenai aktivitas pelanggan.

Jika informasi tersebut dapat diakses oleh pihak yang seharusnya tidak berwenang, batas kerahasiaan sudah gagal meskipun password pengguna tidak pernah diketahui.

Dari perspektif keamanan informasi, masalahnya bukan sekadar apakah akun berhasil diambil alih. Pertanyaannya adalah apakah data yang seharusnya hanya tersedia setelah authorization tetap berada dalam batas yang ditentukan.

Security Testing Perlu Memeriksa Jalur dari CDN hingga Aplikasi

Pengujian aplikasi sering berfokus pada endpoint di origin.

Pendekatan tersebut tetap penting, tetapi belum tentu menggambarkan bagaimana aplikasi sebenarnya diakses pengguna.

Pada lingkungan produksi, request dapat melewati CDN, Web Application Firewall, API gateway, reverse proxy, load balancer, hingga akhirnya tiba di aplikasi.

Setiap layer dapat mengubah perilaku request maupun response.

Karena itu, pengujian keamanan perlu mengevaluasi bagaimana keseluruhan rantai tersebut berinteraksi.

Beberapa hal yang perlu diperiksa antara lain perilaku cache terhadap halaman setelah login, penanganan URL yang tidak biasa, normalisasi path, cache key, header HTTP, response personalized, serta perbedaan antara perilaku origin dan edge.

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

Permasalahan yang ditemukan tidak selalu berupa kelemahan pada source code. Dalam sejumlah kasus, risiko justru muncul dari kombinasi konfigurasi infrastruktur, perilaku framework, routing aplikasi, dan kebijakan cache.

Hal tersebut menjadi alasan penetration testing tidak seharusnya hanya mencari SQL Injection, Cross-Site Scripting, atau kerentanan aplikasi yang sudah umum dikenal.

Pengujian juga perlu memahami arsitektur aplikasi sebagaimana sistem tersebut benar-benar digunakan.

Enam Pemeriksaan Sebelum Memperluas Strategi Cache

Organisasi tidak perlu menghindari cache. Cache tetap menjadi komponen penting untuk menjaga performa dan skalabilitas aplikasi.

Yang perlu dilakukan adalah memastikan optimasi tersebut mempunyai batas yang jelas.

1. Pisahkan Konten Publik dan Konten Personal

Identifikasi respons mana yang benar-benar dapat diberikan kepada semua pengguna dan mana yang bergantung pada session, identitas, tenant, atau hak akses.

Jangan menyamakan keduanya hanya karena berasal dari domain yang sama.

2. Tinjau Aturan Cache pada CDN

Periksa pola wildcard, file extension, path, query parameter, dan aturan lain yang menentukan apakah sebuah respons boleh masuk ke shared cache.

Aturan yang terlalu luas dapat menangkap endpoint yang sebelumnya tidak pernah dimaksudkan untuk di-cache.

3. Evaluasi Cache-Control

Pastikan halaman personal memiliki kebijakan caching yang sesuai.

Perhatikan perbedaan antara private, no-store, dan no-cache agar implementasinya sesuai dengan tujuan keamanan.

4. Periksa Desain Cache Key

Pastikan request yang berbeda dari perspektif authentication, authorization, atau tenant tidak secara tidak sengaja menggunakan cache entry yang sama.

5. Uji Perilaku Routing yang Tidak Normal

Dynamic route sebaiknya tidak diam-diam menerima tambahan path atau suffix yang membuat respons personal terlihat seperti aset statis.

Perilaku semacam ini perlu diperiksa dari sisi aplikasi maupun CDN.

6. Lakukan Pengujian Melalui Jalur yang Benar-Benar Digunakan Pengguna

Pengujian langsung terhadap origin dapat melewatkan risiko yang hanya muncul setelah request melewati CDN atau reverse proxy.

Karena itu, environment pengujian perlu cukup merepresentasikan arsitektur nyata.

Performa Seharusnya Mengurangi Beban Server, Bukan Mengurangi Batas Keamanan

Cache bekerja sangat baik ketika sistem memahami dengan jelas konten mana yang boleh digunakan kembali dan siapa yang boleh menerimanya.

Masalah muncul ketika batas tersebut menjadi kabur.

Keberhasilan optimasi cache karena itu tidak seharusnya hanya diukur dari latency yang lebih rendah, hit ratio yang meningkat, atau jumlah request ke origin yang menurun.

Pada portal pelanggan, indikator keberhasilan lain sama pentingnya: apakah batas akses data tetap sama sebelum dan setelah optimasi diterapkan?

Pertanyaan tersebut seharusnya menjadi bagian dari proses development, deployment, infrastructure review, dan security testing.

Karena ketika aplikasi sudah mengenal identitas pengguna, keputusan caching bukan lagi sekadar keputusan performa.

Ia juga merupakan keputusan keamanan.

Pastikan Konfigurasi Cache Tidak Membuka Celah pada Aplikasi Anda

Kerentanan pada mekanisme cache sering tidak terlihat dalam penggunaan normal karena aplikasi tetap tampak bekerja seperti biasa. Login berhasil, halaman muncul dengan benar, dan performa bahkan meningkat.

Risiko baru terlihat ketika interaksi antara CDN, routing, session, cache key, serta konfigurasi aplikasi diuji dari perspektif keamanan.

Fourtrezz membantu perusahaan melakukan Vulnerability Assessment dan Penetration Testing untuk mengidentifikasi kerentanan pada aplikasi dan infrastruktur sebelum dimanfaatkan oleh pihak yang tidak berwenang.

Pengujian dapat dilakukan terhadap web application, API, aplikasi mobile, jaringan, dan server, termasuk melalui pendekatan penetration testing greybox maupun blackbox sesuai kebutuhan pengujian.

Jika perusahaan Anda sedang mengembangkan portal pelanggan, memperbarui arsitektur aplikasi, menggunakan CDN, atau ingin memastikan konfigurasi aplikasi tetap aman setelah perubahan infrastruktur, tim Fourtrezz dapat membantu melakukan evaluasi keamanan secara menyeluruh.

Hubungi Fourtrezz:

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