Pengguna Standar Mengubah Konfigurasi Tingkat Proyek

Autentikasi berhasil bukan berarti setiap operasi yang mengikuti otomatis sah. Dalam kasus ini, pengguna dengan role standar memiliki sesi valid dan dapat memakai fitur normal proyek. Masalah muncul ketika backend menerima perubahan konfigurasi yang seharusnya hanya tersedia bagi administrator atau owner.

Security Invariant

Pengguna standar tidak boleh mengubah konfigurasi tingkat proyek yang mengendalikan lifecycle atau kebijakan environment tanpa permission administratif yang eksplisit.

Actor: pengguna terautentikasi dengan role standar
Object: konfigurasi tingkat proyek yang diotorisasi untuk pengujian
Operation: mengubah satu atribut lifecycle
Required role: administrator atau owner
Trust decision: session validity + role permission + project binding

Observed Baseline

State awal konfigurasi dibaca melalui endpoint resmi dan marker lifecycle dicatat. Pengujian menggunakan sesi pengguna standar pada proyek yang berada dalam ruang lingkup terotorisasi.

Baseline penting karena respons mutasi saja tidak membuktikan state sebelumnya, role actor, ataupun perubahan yang bertahan.

Controlled Mutation

Permintaan perubahan normal dipertahankan, lalu hanya satu nilai konfigurasi lifecycle yang diubah. Tidak ada role, cookie, project identifier, maupun atribut lain yang dimutasi.

ONE-VARIABLE EXPERIMENT

actor role              → STANDARD USER
project                  → AUTHORIZED TEST PROJECT
initial lifecycle marker → STATE A
single mutation          → STATE B
server response          → ACCEPTED

Authoritative Verification

Setelah mutasi diterima, konfigurasi dibaca kembali melalui request terpisah. Server mengembalikan marker baru yang sama dengan nilai uji. Dengan demikian, bukti tidak berhenti pada HTTP 200 atau reflection di response mutasi.

BASELINEKonfigurasi berada pada State A.

MUTATIONPengguna standar meminta perubahan ke State B.

READBACKState B dikonfirmasi dari server.

INVARIANTOperasi membutuhkan authority administratif.

DECISIONBOUNDARY_CROSSED.

Mengapa Ini Bukan Sekadar ID yang Dapat Ditebak?

Inti masalah bukan format identifier. Kegagalan terjadi karena backend mengizinkan actor berprivilege rendah melakukan operasi sensitif terhadap objek tingkat proyek. Bahkan identifier yang tidak dapat ditebak tidak akan memperbaiki permission check yang hilang.

Dampak Keamanan

integritas konfigurasi proyek dapat diubah oleh role yang tidak semestinya;
resource yang dimaksudkan memiliki lifecycle tertentu dapat dipaksa mengikuti kebijakan berbeda;
governance environment dan proses approval dapat kehilangan asumsi dasarnya;
audit trail menjadi penting karena perubahan terlihat seperti operasi aplikasi biasa dari sesi valid.

Batas klaim dipertahankan: eksperimen membuktikan perubahan konfigurasi pada proyek yang diotorisasi. Tidak ada klaim akses lintas tenant, pengambilalihan akun, atau dampak terhadap data pihak ketiga.

Alternative Explanations yang Dieliminasi

“Mungkin hanya response reflection”

Dibantah oleh authoritative readback yang menunjukkan state baru bertahan.

“Mungkin pengguna memang admin”

Role actor dicatat sebagai pengguna standar dan invariant fitur memerlukan kewenangan lebih tinggi.

“Mungkin perubahan hanya lokal di browser”

Mutasi dikirim ke backend dan hasilnya diperoleh kembali melalui pembacaan server terpisah.

Cleanup Terverifikasi

Nilai konfigurasi dikembalikan ke baseline menggunakan perubahan satu variabel yang sama. Pembacaan ulang memastikan marker awal kembali dan tidak ada state uji yang tertinggal.

Remediasi

Server-Side RBAC: evaluasi permission administratif pada setiap operasi konfigurasi, bukan hanya autentikasi.
Project binding: ikat actor, tenant, project, operation, dan state dalam satu policy decision.
Permission granular: pisahkan read configuration dari update lifecycle, approval, dan policy management.
Default deny: endpoint sensitif menolak role yang tidak secara eksplisit diizinkan.
Audit logging: catat actor, role, project, field yang berubah, before/after, source, dan timestamp.
Regression matrix: standard user versus admin pada web, API, endpoint lama/baru, dan batch workflow.

Pelajaran untuk Tim Produk

Endpoint administratif sering tidak terlihat di UI pengguna standar, tetapi invisibility bukan kontrol keamanan. Backend harus menegakkan authority yang sama untuk request dari UI, API client, automation, dan integrasi.

Kesimpulan

Finding ini menunjukkan pola klasik broken access control: sesi valid melewati trust decision yang terlalu sempit. Server memverifikasi siapa actor-nya, tetapi tidak memverifikasi apakah role tersebut boleh mengubah konfigurasi tingkat proyek. Baseline, controlled mutation, authoritative verification, dan cleanup membuktikan kegagalan integrity boundary secara reproduktif.