Adopsi feature flag telah mengubah cara organisasi mengelola proses rilis perangkat lunak. Jika sebelumnya deployment dan release sering berlangsung sebagai satu rangkaian yang hampir tidak terpisahkan, feature flag memungkinkan keduanya diperlakukan sebagai dua proses berbeda. Kode dapat lebih dahulu ditempatkan di production, sementara akses terhadap fungsi tertentu diatur melalui konfigurasi.

Pendekatan tersebut memberikan keuntungan operasional yang nyata. Tim pengembangan dapat melakukan progressive rollout, eksperimen, canary release, pengujian terbatas, serta rollback tanpa harus selalu melakukan deployment ulang.

Namun terdapat konsekuensi keamanan yang sering kurang mendapat perhatian.

Ketika perilaku aplikasi dapat berubah hanya melalui konfigurasi feature flag, maka perubahan pada attack surface juga dapat terjadi tanpa adanya perubahan kode, build baru, atau deployment tambahan.

Artinya, asumsi bahwa security review cukup dilakukan pada tahap sebelum deployment menjadi semakin sulit dipertahankan.

Persoalan utama bukan terletak pada keberadaan feature flag, melainkan pada meningkatnya jumlah state aplikasi yang dapat muncul di production serta kemungkinan adanya jalur akses yang belum pernah diuji dalam setiap state tersebut.

Feature Flag Mengubah Konsep Versi Aplikasi

Dalam model rilis konvensional, versi perangkat lunak biasanya memiliki batas yang relatif jelas.

Versi baru dikembangkan, diuji, kemudian menggantikan versi sebelumnya.

Feature flag memperumit konsep tersebut karena satu deployment dapat menghasilkan beberapa variasi perilaku secara bersamaan.

Misalnya, sebuah aplikasi memiliki tiga feature flag yang masing-masing dapat berada pada kondisi aktif atau tidak aktif. Secara teoritis, ketiga flag tersebut dapat menghasilkan delapan kombinasi state.

Kompleksitas meningkat ketika feature flag dikombinasikan dengan variabel lain seperti:

• role pengguna;
• jenis akun;
• subscription plan;
• lokasi geografis;
• tenant;
• kelompok eksperimen;
• environment;
• serta konfigurasi integrasi.

Dalam kondisi tersebut, dua pengguna yang mengakses aplikasi yang sama dapat memperoleh perilaku sistem yang berbeda.

Dari perspektif software engineering, kondisi ini memberikan fleksibilitas.

Dari perspektif application security, kondisi ini memperbesar state space yang perlu dipahami.

Security testing terhadap satu konfigurasi belum tentu cukup untuk merepresentasikan seluruh jalur yang mungkin tersedia di production.

Perubahan Feature Flag Dapat Mengubah Attack Surface Tanpa Deployment

Attack surface pada aplikasi umumnya dipahami sebagai kumpulan komponen, fungsi, endpoint, interface, dan mekanisme yang dapat menjadi titik interaksi antara pengguna atau pihak eksternal dengan sistem.

Feature flag dapat mengubah attack surface tersebut secara dinamis.

Sebagai contoh, suatu endpoint mungkin telah tersedia di backend, tetapi belum dapat diakses melalui antarmuka pengguna karena feature flag masih dinonaktifkan.

Ketika flag diaktifkan, tidak ada perubahan binary dan tidak ada deployment baru. Namun pengguna tiba-tiba memperoleh akses terhadap fungsi tambahan.

Dengan demikian, perubahan attack surface tidak selalu identik dengan perubahan source code.

Konfigurasi runtime dapat memainkan peran yang sama pentingnya.

Fenomena ini menjadi relevan terutama dalam arsitektur modern yang mengandalkan feature management platform, remote configuration, dan progressive delivery.

Akibatnya, keamanan aplikasi perlu memonitor bukan hanya perubahan kode, tetapi juga perubahan konfigurasi yang mampu memodifikasi perilaku sistem.

Visibilitas Fitur Tidak Sama dengan Authorization

Salah satu risiko paling penting adalah penggunaan feature flag sebagai mekanisme pembatas akses.

Misalnya, sebuah tombol ekspor data hanya ditampilkan apabila feature flag tertentu aktif.

Pada sisi antarmuka, mekanisme tersebut terlihat efektif.

Namun apabila endpoint backend tetap dapat dipanggil secara langsung, maka penyembunyian tombol tidak memberikan kontrol keamanan yang memadai.

Dalam konteks keamanan aplikasi, terdapat perbedaan mendasar antara feature availability dan authorization.

Feature availability menentukan apakah sebuah fungsi perlu ditampilkan atau disediakan pada konteks tertentu.

Authorization menentukan apakah suatu identitas memiliki hak untuk menjalankan fungsi tersebut.

Keduanya tidak dapat dipertukarkan.

Authorization harus tetap ditegakkan pada sisi server berdasarkan identitas, role, ownership, permission, dan konteks akses yang relevan.

Feature flag dapat digunakan sebagai lapisan tambahan untuk mengatur rollout, tetapi tidak seharusnya menjadi satu-satunya security boundary.

Jika kontrol keamanan hanya diterapkan melalui UI atau konfigurasi client-side, attacker dapat mencoba melewati jalur normal aplikasi dan langsung mengakses endpoint yang mendasarinya.

Feature Flag yang Tidak Aktif Tetap Dapat Menambah Attack Surface

Salah satu asumsi yang perlu dikoreksi adalah bahwa fitur yang dinonaktifkan melalui feature flag belum memiliki implikasi keamanan.

Pada praktiknya, kode untuk fitur tersebut sering kali sudah berada di production.

Komponen pendukungnya mungkin juga sudah tersedia, seperti:

• API endpoint;
• service account;
• database permission;
• integration credential;
• route;
• background job;
• message queue;
• atau akses terhadap layanan eksternal.

Dalam kondisi seperti ini, feature flag hanya menentukan apakah fungsi tertentu ditampilkan atau digunakan oleh aplikasi melalui jalur normal.

Dari perspektif attacker, keberadaan kode dan endpoint sudah cukup untuk menarik perhatian.

Jika fungsi masih dapat dijangkau secara langsung, maka secara praktis fungsi tersebut tetap menjadi bagian dari attack surface.

Oleh sebab itu, status flag “off” tidak dapat diartikan sebagai jaminan bahwa fitur tersebut tidak dapat dieksploitasi.

Feature Flag Dapat Menimbulkan Risiko Kombinatorial

Salah satu persoalan paling kompleks dalam penggunaan feature flag adalah interaksi antar flag.

Sebuah feature flag mungkin aman ketika diuji secara individual.

Namun risiko dapat muncul ketika dua atau lebih flag diaktifkan secara bersamaan.

Misalnya, satu flag mengaktifkan proses checkout baru, sedangkan flag lain mengaktifkan promotion engine baru.

Masing-masing diuji secara terpisah dan tidak menunjukkan kelemahan.

Namun ketika keduanya aktif, perubahan urutan validasi dapat menimbulkan kelemahan business logic.

Dampaknya dapat berupa:

• manipulasi harga;
• duplikasi transaksi;
• bypass workflow;
• inkonsistensi status;
• penyalahgunaan diskon;
• atau akses terhadap proses yang seharusnya dibatasi.

Masalah tersebut menunjukkan bahwa keamanan aplikasi tidak hanya bergantung pada correctness setiap fitur secara individual, tetapi juga pada interaksi antar fitur.

Secara matematis, peningkatan jumlah boolean feature flag menghasilkan pertumbuhan state yang eksponensial.

Sepuluh flag secara teoritis dapat menghasilkan 1.024 kombinasi state.

Walaupun tidak semua kombinasi relevan atau valid secara operasional, angka tersebut menunjukkan bahwa pengujian seluruh kemungkinan state secara exhaustive tidak realistis.

Karena itu dibutuhkan pendekatan security testing berbasis risiko.

Security Testing Perlu Berbasis State dan Konteks

Pendekatan pengujian tradisional sering berorientasi pada versi aplikasi.

Versi tertentu diuji, hasilnya diterima, lalu aplikasi dirilis.

Feature flag menuntut perubahan paradigma.

Objek pengujian bukan hanya versi aplikasi, tetapi juga state aplikasi.

Pengujian perlu mempertimbangkan:

• flag yang aktif;
• flag yang tidak aktif;
• role pengguna;
• tenant;
• environment;
• data classification;
• permission;
• dependency;
• serta interaksi antar workflow.

Tidak semua state memiliki tingkat risiko yang sama.

Karena itu organisasi dapat mengklasifikasikan feature flag berdasarkan dampak keamanan.

Sebagai contoh:

Risiko Rendah

Flag yang hanya memengaruhi tampilan visual dan tidak mengubah data, permission, atau business logic.

Risiko Menengah

Flag yang mengubah workflow aplikasi tetapi tidak menyentuh fungsi sensitif.

Risiko Tinggi

Flag yang memengaruhi:

• authentication;
• authorization;
• transaksi;
• pembayaran;
• approval;
• data sensitif;
• fungsi administratif;
• integrasi eksternal;
• atau perubahan privilege.

Feature flag dengan tingkat risiko tinggi seharusnya mendapatkan security review dan pengujian yang lebih ketat dibandingkan flag yang hanya memengaruhi UI.

Hak Mengubah Feature Flag Merupakan Bagian dari Privileged Access

Implikasi keamanan feature flag juga tidak berhenti pada pengguna aplikasi.

Akses terhadap sistem feature management perlu dipertimbangkan sebagai bagian dari privileged access.

Dalam lingkungan yang matang, perubahan kode production biasanya melalui rangkaian kontrol seperti peer review, automated testing, CI/CD, dan approval.

Namun apabila feature flag production dapat diubah langsung melalui dashboard oleh pengguna dengan hak akses tertentu, maka perubahan behavior aplikasi dapat terjadi di luar pipeline deployment.

Hal ini menciptakan jalur perubahan tambahan.

Jika sebuah feature flag memengaruhi authentication, authorization, transaksi, atau data sensitif, kemampuan untuk mengubah flag tersebut secara praktis dapat memiliki dampak yang setara dengan kemampuan mengubah production configuration.

Karena itu organisasi perlu menerapkan kontrol seperti:

• role-based access control;
• segregation of duties;
• approval workflow;
• audit logging;
• environment separation;
• monitoring;
• dan change governance.

Security posture aplikasi akan sulit dipertahankan apabila deployment dikontrol secara ketat tetapi konfigurasi yang menentukan behavior aplikasi dapat diubah tanpa tingkat governance yang setara.

Rollback Tidak Selalu Mengembalikan Sistem ke Kondisi yang Aman

Feature flag sering digunakan sebagai mekanisme rollback cepat.

Ketika fitur baru menimbulkan masalah, tim dapat menonaktifkan flag dan mengembalikan pengguna ke jalur lama.

Dari sisi availability dan operational resilience, pendekatan ini sangat berguna.

Namun dari perspektif keamanan, rollback memiliki implikasi yang berbeda.

Apabila implementasi lama memiliki kelemahan yang sudah diperbaiki pada versi baru, menonaktifkan feature flag dapat secara tidak langsung mengaktifkan kembali jalur yang lebih rentan.

Situasi ini menunjukkan bahwa rollback path juga perlu diperlakukan sebagai bagian dari attack surface.

Kode lama yang masih dapat diaktifkan kembali tidak boleh dianggap aman hanya karena pernah digunakan sebelumnya.

Setiap jalur yang masih tersedia perlu tetap memenuhi security requirement yang berlaku.

Stale Feature Flag Membentuk Security Debt

Feature flag sering dirancang sebagai mekanisme sementara.

Setelah rollout selesai, flag seharusnya dihapus atau dikonsolidasikan.

Namun dalam prakteknya, tidak semua flag memiliki life cycle yang jelas.

Sebagian tetap berada di codebase karena prioritas engineering berpindah ke fitur lain.

Seiring waktu, organisasi dapat memiliki:

• flag yang selalu aktif;
• flag yang selalu tidak aktif;
• flag tanpa owner;
• flag yang tidak lagi terdokumentasi;
• flag yang masih dapat mengaktifkan legacy workflow.

Kondisi tersebut menghasilkan technical debt sekaligus security debt.

Setiap flag lama memperbesar kompleksitas sistem.

Setiap jalur lama yang masih dapat diaktifkan menambah kemungkinan behavior yang tidak lagi dipahami oleh developer maupun security team.

Karena itu lifecycle management menjadi aspek penting dalam feature flag governance.

Setiap flag sebaiknya memiliki:

• owner;
• tujuan;
• tanggal pembuatan;
• security impact;
• affected endpoint;
• affected role;
• expiry date;
• dan keputusan akhir apakah flag akan dipertahankan atau dihapus.

Business Logic Menjadi Area yang Paling Sulit Diuji

Feature flag memiliki hubungan yang sangat erat dengan business logic security.

Kelemahan business logic biasanya tidak muncul karena satu input tidak divalidasi atau satu konfigurasi salah.

Kelemahan muncul karena aplikasi mengizinkan urutan tindakan atau kombinasi state yang tidak pernah dipertimbangkan oleh developer.

Feature flag memperbesar jumlah state tersebut.

Sebagai contoh, aplikasi mungkin mengharapkan workflow:

A → B → C → D

Namun kombinasi feature flag tertentu dapat menghasilkan:

A → C → D

Jika validation yang sebelumnya dilakukan pada tahap B tidak lagi dieksekusi, sistem dapat memasuki state yang tidak valid.

Dari perspektif attacker, kondisi seperti ini sangat menarik karena sering kali tidak mudah ditemukan oleh automated vulnerability scanner.

Pengujian perlu memahami proses bisnis, role, state transition, dependency, dan hubungan antarfitur.

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

Dalam banyak kasus, kelemahan yang ditemukan tidak selalu berasal dari satu vulnerability klasik, tetapi dari kombinasi authorization, workflow, endpoint, dan state aplikasi yang membentuk jalur akses tidak terduga.

Feature Flag Perlu Dipandang sebagai Bagian dari Security Architecture

Dalam software engineering modern, feature flag sebaiknya tidak hanya diposisikan sebagai alat product management atau release management.

Semakin besar pengaruhnya terhadap behavior production, semakin relevan feature flag terhadap security architecture.

Beberapa pertanyaan yang perlu dijawab antara lain:

Apakah flag mengubah access control?

Apakah endpoint tetap dapat dipanggil ketika flag tidak aktif?

Apakah perubahan flag memengaruhi data sensitif?

Apakah flag mengubah state transition?

Apakah terdapat interaksi dengan flag lain?

Siapa yang berhak mengubah konfigurasi di production?

Apakah perubahan tersebut dicatat?

Apakah konfigurasi dapat menyebabkan aktivasi kembali jalur lama?

Kapan flag harus dihapus?

Pertanyaan tersebut membantu organisasi membedakan feature flag yang hanya bersifat operasional dengan feature flag yang berpotensi mengubah risk profile aplikasi.

Security Testing Tidak Lagi Cukup Berhenti pada Deployment

Feature flag menunjukkan satu perubahan penting dalam pengembangan perangkat lunak modern.

Deployment bukan lagi satu-satunya titik ketika perilaku production berubah.

Remote configuration, progressive delivery, dynamic targeting, dan feature management memungkinkan perubahan terjadi setelah aplikasi selesai dibangun dan dirilis.

Karena itu proses keamanan perlu menyesuaikan diri.

Security review tidak hanya perlu mengikuti perubahan source code.

Security testing juga perlu memperhatikan perubahan runtime configuration yang mampu memengaruhi authorization, data flow, business logic, dan attack surface.

Feature flag bukanlah risiko secara inheren.

Risiko muncul ketika organisasi menggunakan feature flag untuk mengubah behavior sistem tetapi tidak memasukkan perubahan tersebut ke dalam model ancaman dan proses pengujian keamanan.

Pada akhirnya, pertanyaan yang lebih relevan bukan:

“Apakah fitur ini sudah diuji sebelum deployment?”

Melainkan:

“Apakah seluruh state keamanan yang dapat dihasilkan oleh feature flag sudah dipahami dan diuji?”

Jika jawabannya belum jelas, maka fleksibilitas yang mempercepat release dapat sekaligus menciptakan jalur akses yang tidak pernah benar-benar diperiksa.

Evaluasi Keamanan Aplikasi Bersama Fourtrezz

Aplikasi modern semakin bergantung pada API, CI/CD, feature flag, cloud infrastructure, dan berbagai mekanisme otomatisasi. Kompleksitas tersebut membuat kelemahan keamanan tidak selalu muncul sebagai vulnerability yang berdiri sendiri, tetapi dapat terbentuk melalui kombinasi authorization, workflow, konfigurasi, dan state aplikasi.

Fourtrezz membantu perusahaan mengevaluasi kondisi tersebut melalui layanan Penetration Testing dan Vulnerability Assessment, serta layanan cybersecurity dan pengembangan sistem dengan pendekatan keamanan.

Melalui penetration testing, perusahaan dapat menguji bagaimana sistem merespons manipulasi role, akses langsung ke endpoint, perubahan workflow, kelemahan authorization, dan berbagai skenario serangan yang mungkin tidak teridentifikasi melalui functional testing.

Pengujian ini dapat menjadi bagian penting bagi organisasi yang menggunakan feature flag dan progressive delivery untuk memastikan bahwa percepatan rilis tidak menciptakan attack path yang tidak diketahui.

Hubungi Fourtrezz:

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