Tombolnya sudah dihapus. Menu tidak lagi terlihat. Feature flag telah diubah menjadi off. Bagi tim produk, fitur tersebut mungkin dianggap selesai. Namun, bagi penyerang, pertanyaannya berbeda: apakah fungsi di belakangnya masih dapat dipanggil?

Fitur yang menghilang dari antarmuka belum tentu benar-benar keluar dari sistem. Kode, endpoint API, akun layanan, konfigurasi, dan hak akses yang mendukungnya dapat tetap aktif di lingkungan produksi.

Kondisi tersebut membuat fitur yang dianggap tidak digunakan masih menjadi bagian dari attack surface aplikasi. Risikonya bahkan dapat meningkat ketika fitur itu tidak lagi dipantau, diperbarui, atau dimasukkan dalam pengujian keamanan.

Status Nonaktif Tidak Sama dengan Penghapusan

Feature flag memberikan fleksibilitas kepada tim pengembang untuk mengendalikan perilaku aplikasi tanpa melakukan deployment ulang. Mekanisme ini berguna untuk peluncuran bertahap, eksperimen, pengujian terbatas, rollback, maupun penghentian sementara.

Masalah muncul ketika perubahan status feature flag dianggap sebagai akhir dari siklus hidup fitur.

Dalam banyak implementasi, feature flag hanya menentukan apakah suatu fungsi akan ditampilkan atau digunakan dalam alur normal. Kode dan infrastruktur di belakangnya tetap tersedia.

Beberapa komponen yang mungkin tertinggal antara lain:

• endpoint API yang masih merespons;
• route lama yang tetap terdaftar;
• service backend yang masih berjalan;
• permission database yang belum dicabut;
• API key dan akun layanan yang tetap aktif;
• konfigurasi lama pada sebagian microservice;
• penyimpanan data yang belum ditutup;
• integrasi pihak ketiga yang masih terhubung.

Secara visual, fitur memang telah menghilang. Secara teknis, kemampuannya masih dapat ditemukan dan dipanggil.

Penyerang Tidak Membutuhkan Tombol untuk Mengakses Fungsi

Pengguna biasa berinteraksi dengan aplikasi melalui menu, tombol, dan formulir. Penyerang tidak memiliki batasan tersebut.

Mereka dapat mengirim request secara langsung menggunakan pola endpoint yang pernah diketahui. Informasi mengenai fungsi lama juga dapat ditemukan melalui dokumentasi API, file JavaScript, aplikasi versi terdahulu, riwayat request, source map, atau konfigurasi yang terekspos.

Bayangkan sebuah aplikasi pernah menyediakan fitur ekspor data pelanggan. Fitur tersebut kemudian dihentikan dan tombol ekspor dihapus. Namun, endpoint yang menjalankan proses ekspor masih tersedia.

Apabila endpoint itu tidak lagi diperiksa atau menggunakan mekanisme otorisasi lama, pengguna dapat mencoba memanggilnya secara langsung. Fitur yang dianggap telah mati akhirnya berubah menjadi jalur alternatif untuk mengakses data.

Inilah alasan attack surface tidak dapat dinilai hanya dari apa yang terlihat pada antarmuka.

Feature Flag Bukan Kontrol Otorisasi

Feature flag dan kontrol otorisasi sama-sama dapat membatasi suatu fungsi, tetapi tujuan keduanya berbeda.

Feature flag mengatur apakah kemampuan tertentu akan diluncurkan, ditampilkan, atau tersedia bagi kelompok pengguna tertentu. Otorisasi menentukan apakah identitas tertentu memiliki hak untuk melakukan tindakan atau mengakses data.

Perbedaan ini sangat penting. Feature flag tidak seharusnya digunakan sebagai satu-satunya penghalang untuk fungsi sensitif.

Risiko dapat muncul ketika aplikasi hanya menyembunyikan menu, tetapi tidak melakukan pemeriksaan izin pada endpoint. Masalah serupa terjadi apabila nilai flag dievaluasi pada sisi klien dan server mempercayai nilai tersebut tanpa verifikasi.

Pengguna yang dapat memanipulasi request mungkin mengubah parameter flag, memanggil endpoint secara langsung, atau menjalankan kembali request yang direkam ketika fitur masih aktif.

Karena itu, setiap endpoint harus tetap menerapkan autentikasi dan otorisasi pada sisi server. Pemeriksaan perlu mencakup identitas pengguna, peran, kepemilikan data, tenant, serta konteks tindakan yang dilakukan.

Fitur yang disembunyikan tetap harus aman apabila berhasil ditemukan.

Dormant Endpoint Dapat Tetap Menjadi Jalur Serangan

Dormant endpoint merupakan endpoint yang tidak lagi digunakan dalam alur aplikasi sehari-hari, tetapi masih tersedia di dalam sistem.

Endpoint semacam ini dapat berasal dari:

• API versi lama;
• fitur yang telah dihentikan;
• integrasi dengan vendor sebelumnya;
• kebutuhan migrasi data;
• fungsi administrator lama;
• endpoint debugging;
• aplikasi seluler versi terdahulu;
• proyek percobaan yang dibatalkan;
• route internal yang pernah dibuka sementara.

Keberadaannya sering terlupakan karena endpoint tersebut tidak lagi muncul dalam dokumentasi utama. Tim yang dahulu mengelolanya mungkin telah berpindah, sedangkan tim baru tidak mengetahui alasan endpoint itu dibuat.

Akibatnya, dormant endpoint dapat terus berjalan tanpa pemilik yang jelas. Endpoint tidak diperbarui, tidak dipantau, dan tidak dimasukkan dalam scope pengujian keamanan.

OWASP menyoroti kondisi semacam ini dalam risiko improper inventory management. API lama, endpoint debugging, serta versi yang tidak terdokumentasi dapat memperluas attack surface karena keberadaannya tidak lagi dikelola secara konsisten.

OWASP juga menggunakan istilah shadow function untuk menggambarkan fungsi tersembunyi atau terlupakan yang masih aktif. Fungsi tersebut dapat berupa operasi administratif, utility pengujian, atau endpoint internal yang berada di luar pengawasan keamanan normal.

Endpoint Lama Membawa Asumsi Keamanan Lama

Dormant endpoint tidak sekadar menambah jumlah jalur yang dapat diserang. Komponen tersebut juga dapat mempertahankan standar keamanan dari masa ketika sistem memiliki arsitektur berbeda.

Endpoint lama mungkin:

• menggunakan metode autentikasi terdahulu;
• belum menerapkan pemeriksaan otorisasi terbaru;
• berada di luar API gateway;
• tidak memiliki rate limiting;
• tidak masuk dalam sistem monitoring;
• menggunakan dependensi yang tidak lagi diperbarui;
• mengembalikan data lebih banyak daripada versi baru;
• tidak mengikuti kebijakan logging terbaru.

Ketika organisasi memodernisasi aplikasi, endpoint baru biasanya memperoleh perlindungan yang lebih baik. Namun, penyerang tidak berkewajiban menggunakan jalur terbaru.

Apabila API versi lama masih tersedia, jalur dengan kontrol paling lemah itulah yang kemungkinan akan dipilih.

Studi akademis mengenai penghentian REST API juga menunjukkan bahwa proses deprecation dan penghapusan tidak selalu berjalan dengan baik. Ketergantungan antar sistem sering membuat endpoint lama tetap dipertahankan lebih lama daripada rencana awal.

Perbedaan Status Antarservice Menciptakan Risiko Baru

Risiko feature flag semakin sulit dikendalikan dalam arsitektur microservices.

Satu fitur dapat bergantung pada beberapa service yang memiliki konfigurasi, jadwal deployment, dan mekanisme evaluasi flag berbeda. Service pertama mungkin sudah membaca flag sebagai nonaktif, sedangkan service kedua masih menjalankan konfigurasi lama.

Akibatnya, frontend menunjukkan bahwa fitur telah mati, tetapi sebagian proses di backend masih berjalan. Dalam kondisi lain, penghentian fitur justru menonaktifkan validasi tanpa menghentikan transaksi utama.

Perbedaan semacam ini dapat muncul ketika terjadi:

• peluncuran bertahap;
• perubahan konfigurasi;
• deployment yang tidak serempak;
• rollback ke versi sebelumnya;
• gangguan pada layanan feature flag;
• caching nilai flag;
• pemulihan setelah insiden.

Penelitian mengenai salah konfigurasi feature flag pada lingkungan microservices menunjukkan bahwa risikonya dapat berkaitan dengan bypass kontrol keamanan, hak akses berlebihan, pengelolaan token yang lemah, dan keberadaan shadow flag.

Hal tersebut menunjukkan bahwa feature flag bukan hanya persoalan operasional. Ketika flag memengaruhi autentikasi, otorisasi, logging, pencegahan fraud, pembayaran, atau akses data, perubahan statusnya juga menjadi perubahan keamanan.

Fitur Lama Sering Kehilangan Pengawasan Lebih Dahulu

Ketika suatu fitur tidak lagi digunakan, perhatian organisasi biasanya ikut berkurang.

Pembaruan keamanan diprioritaskan untuk komponen aktif. Dokumentasi lama tidak diperbarui. Dashboard berhenti menampilkan traffic endpoint tersebut. Alert dinonaktifkan karena dianggap tidak relevan.

Pada saat yang sama, endpoint dan komponen pendukungnya belum tentu sudah dihapus.

Kondisi ini berbahaya karena berkurangnya aktivitas pengguna tidak menghilangkan kemampuan penyerang untuk menemukan fungsi tersebut. Endpoint yang jarang digunakan bahkan dapat menjadi sasaran menarik karena aktivitas mencurigakan berpotensi tidak segera terdeteksi.

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

Tim internal umumnya mengetahui bahwa suatu fitur sudah tidak digunakan. Namun, belum selalu ada kepastian apakah seluruh endpoint, permission, akun layanan, kredensial, dan integrasi pendukungnya sudah benar-benar dihentikan.

Inventaris API Harus Mencakup Aset yang Tidak Lagi Digunakan

API inventory tidak seharusnya hanya mencatat endpoint yang saat ini digunakan aplikasi utama.

Inventaris yang baik juga perlu mencakup API lama, endpoint deprecated, fungsi internal, serta route yang sedang dalam proses penghentian. Setiap endpoint setidaknya harus memiliki informasi mengenai:

• fungsi dan tujuan;
• pemilik teknis;
• pemilik bisnis;
• versi API;
• lingkungan deployment;
• metode autentikasi;
• model otorisasi;
• jenis data yang diproses;
• integrasi yang bergantung padanya;
• status aktif atau deprecated;
• tanggal evaluasi terakhir;
• rencana penghapusan.

Inventaris tersebut perlu dibandingkan dengan kondisi deployment yang sebenarnya. Dokumentasi dapat menyatakan bahwa sebuah API telah dihentikan, tetapi pemeriksaan teknis mungkin menunjukkan bahwa endpoint masih memberikan respons.

Selisih antara dokumentasi dan kondisi aktual merupakan tanda bahwa attack surface aplikasi belum dikelola secara menyeluruh.

Menonaktifkan Fitur Harus Diikuti Proses Decommissioning

Mengubah feature flag menjadi off seharusnya menjadi awal proses penghentian, bukan langkah terakhir.

Proses decommissioning perlu memetakan seluruh komponen yang berkaitan dengan fitur. Pemetaan tidak hanya mencakup kode, tetapi juga endpoint, service, database, message queue, akun layanan, secret, permission, penyimpanan data, serta integrasi eksternal.

Setelah seluruh ketergantungan diketahui, penghentian dapat dilakukan secara bertahap:

1. Menonaktifkan akses melalui antarmuka dan sisi server.
2. Memantau apakah endpoint masih menerima request.
3. Mengidentifikasi aplikasi atau integrasi yang masih bergantung pada fitur.
4. Menolak request dengan respons yang konsisten.
5. Mencabut kredensial dan hak akses yang tidak diperlukan.
6. Menghapus route, konfigurasi, serta kode setelah masa observasi.
7. Memperbarui dokumentasi dan inventaris API.
8. Melakukan pengujian keamanan setelah penghapusan.

Tahapan ini membantu organisasi menghindari dua risiko sekaligus: gangguan operasional akibat ketergantungan tersembunyi dan exposure keamanan akibat fungsi lama yang tetap aktif.

Feature Flag Memerlukan Pemilik dan Tanggal Kedaluwarsa

Banyak feature flag dibuat untuk kebutuhan sementara. Namun, flag tersebut dapat berubah menjadi komponen permanen apabila tidak memiliki pemilik dan batas waktu.

Semakin lama flag dibiarkan, semakin sulit tim memahami alasan pembuatannya. Pada akhirnya, tidak ada yang yakin apakah flag aman untuk dihapus atau masih dibutuhkan oleh proses tertentu.

Setiap feature flag sebaiknya memiliki:

• tujuan yang terdokumentasi;
• pemilik yang bertanggung jawab;
• klasifikasi dampak keamanan;
• tanggal evaluasi;
• batas waktu penggunaan;
• rencana penghapusan;
• audit log setiap perubahan;
• pengaturan akses berdasarkan prinsip least privilege.

Flag yang mengendalikan fungsi sensitif perlu memperoleh pengawasan lebih ketat. Perubahan statusnya juga harus diuji untuk memastikan kontrol keamanan tetap berjalan pada setiap kondisi.

Penetration Testing Perlu Melihat Lebih dari Alur Normal

Pengujian yang hanya mengikuti menu aplikasi dapat melewatkan endpoint dormant dan fungsi tersembunyi.

Penetration testing perlu mempertimbangkan berbagai kondisi feature flag, termasuk ketika flag aktif, nonaktif, atau tidak konsisten antarservice.

Beberapa skenario yang perlu diperiksa meliputi:

• memanggil endpoint tanpa melalui antarmuka;
• menjalankan kembali request dari versi aplikasi lama;
• memanipulasi parameter feature flag;
• membandingkan respons ketika flag aktif dan nonaktif;
• menguji akses menggunakan role berbeda;
• memeriksa akses lintas akun dan lintas tenant;
• mengevaluasi konfigurasi setiap service;
• menguji kondisi partial rollout dan rollback;
• menemukan endpoint yang tidak terdokumentasi;
• memastikan logging tetap berjalan pada semua status.

Pengujian ini tidak hanya bertujuan menemukan endpoint yang terlupakan. Tujuan utamanya adalah memastikan setiap jalur tetap menerapkan kontrol autentikasi, otorisasi, validasi, dan monitoring secara konsisten.

Fitur Benar-Benar Berakhir ketika Tidak Lagi Dapat Dijangkau

Feature flag dapat menghilangkan fitur dari antarmuka dalam waktu singkat. Namun, mekanisme tersebut tidak otomatis menghapus endpoint, permission, data, kredensial, dan ketergantungan yang telah terbentuk di belakangnya.

Selama kemampuan lama masih dapat dijangkau, fitur tersebut tetap menjadi bagian dari attack surface aplikasi.

Organisasi perlu menggabungkan tata kelola feature flag, inventaris API, proses decommissioning, monitoring, dan penetration testing. Dengan pendekatan tersebut, fitur yang dinonaktifkan tidak berubah menjadi jalur tersembunyi yang baru diketahui setelah terjadi insiden.

Evaluasi Attack Surface Aplikasi Bersama Fourtrezz

Fourtrezz membantu perusahaan mengidentifikasi celah keamanan melalui layanan Vulnerability Assessment serta Penetration Testing Blackbox dan Greybox.

Pengujian dapat dilakukan terhadap web application, desktop application, aplikasi Android dan iOS, API, jaringan, serta server. Proses penetration testing membantu menemukan endpoint tersembunyi, kelemahan otorisasi, konfigurasi yang tidak konsisten, dan jalur serangan yang tidak terlihat dalam penggunaan normal.

Hasil pengujian disertai laporan terperinci, rekomendasi perbaikan, konsultasi, dan pengujian ulang sesuai ruang lingkup layanan. Hubungi Fourtrezz untuk mendiskusikan kebutuhan dan menentukan scope pengujian yang sesuai dengan sistem perusahaan Anda.

Hubungi Fourtrezz:

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