Cara Menambahkan Kontrol Akses Berbasis Peran (RBAC) ke Aplikasi Anda
Untuk menambahkan kontrol akses berbasis peran, beri setiap pengguna satu atau lebih peran (misalnya admin, editor, penonton), tentukan tindakan apa yang boleh dilakukan setiap peran, dan periksa izin tersebut di server untuk setiap permintaan — bukan hanya dengan menyembunyikan tombol. Periksa juga bahwa record yang diakses milik akun atau tim pengguna. Mulailah dengan beberapa peran tetap di database Anda, dan uji dengan mencoba menjangkau data pengguna lain secara langsung.
Autentikasi vs otorisasi
Dua kata yang sering tertukar:
- Autentikasi adalah siapa Anda? — login. Lihat cara menambahkan login ke aplikasi Anda.
- Otorisasi adalah apa yang boleh Anda lakukan? — halaman, record, dan tindakan mana yang bisa dijangkau pengguna yang sudah login.
RBAC adalah cara paling umum untuk melakukan otorisasi. Ini penting: per September 2026, Broken Access Control menempati posisi #1 di OWASP Top 10:2025, daftar risiko keamanan aplikasi web paling serius yang banyak dipakai. Kegagalan yang umum adalah pengguna membaca data pengguna lain dengan mengubah ID di URL, atau pengguna biasa memanggil rute API khusus admin.
Pilih model
| Model | Cara kerjanya | Cocok untuk | Konsekuensi |
|---|---|---|---|
| Satu kolom peran | users.role = admin / member | Aplikasi kecil dengan dua atau tiga peran | Menjadi berantakan saat orang membutuhkan peran berbeda di tempat yang berbeda |
| Peran + izin | Peran dipetakan ke izin bernama (invoices.approve); kode memeriksa izin | Aplikasi yang aturannya akan berkembang | Lebih banyak tabel; daftar izin yang harus dipelihara |
| Peran per tim (multi-tenant) | Tabel keanggotaan: pengguna + organisasi + peran | SaaS tempat orang tergabung dalam tim atau workspace | Setiap kueri harus dibatasi ke organisasi |
| Berbasis atribut atau relasi | Aturan pada atribut record ("penulis boleh mengedit postingannya sendiri") atau pada relasi (dibagikan dengan) | Dokumen, berbagi, alur kerja kompleks | Lebih sulit dipahami; pertimbangkan pustaka atau layanan khusus |
| Peran dari penyedia auth | Penyedia login Anda menyimpan peran atau keanggotaan organisasi | Aplikasi yang sudah memakai penyedia auth hosted | Terikat pada penyedia itu; tetap tegakkan di server Anda |
Dalam praktiknya, sebagian besar aplikasi menggabungkan dua hal: peran untuk jenis tindakan yang boleh dilakukan seseorang, dan kepemilikan untuk record mana yang boleh mereka tangani. "Editor boleh mengedit postingan" adalah aturan peran; "…postingan di workspace mereka sendiri" adalah aturan kepemilikan. Anda membutuhkan keduanya.
Mulailah lebih sederhana daripada yang Anda kira. Admin, anggota, dan penonton sudah mencakup banyak aplikasi. Lebih mudah memecah satu peran nanti daripada mengurai sepuluh peran yang tidak dipahami siapa pun.
Rancang peran sebelum menulis kode
Tulis tabel izin dalam bahasa sehari-hari terlebih dahulu. Ini berfungsi sebagai spesifikasi untuk AI dan sebagai rencana pengujian Anda:
| Tindakan | Pemilik | Admin | Anggota | Penonton |
|---|---|---|---|---|
| Melihat proyek dalam tim | ✓ | ✓ | ✓ | ✓ |
| Membuat dan mengedit proyek | ✓ | ✓ | ✓ | |
| Menghapus proyek | ✓ | ✓ | ||
| Mengundang dan menghapus orang | ✓ | ✓ | ||
| Mengubah peran | ✓ | |||
| Penagihan | ✓ |
Putuskan juga kasus-kasus pinggirnya: bolehkah pemilik terakhir keluar? Bolehkah admin menghapus pemilik? Apa yang dilihat pengguna yang dihapus?
Langkah demi langkah
1. Pastikan login sudah berfungsi
RBAC berada di atas autentikasi. Server harus mengetahui dengan andal siapa yang membuat setiap permintaan, dari sesi atau token yang terverifikasi — jangan pernah dari ID pengguna yang dikirim browser di body permintaan.
2. Simpan peran di database
Untuk aplikasi satu tim, kolom role pada pengguna sudah cukup. Untuk tim, gunakan tabel keanggotaan:
create table memberships (
user_id uuid references users(id),
organization_id uuid references organizations(id),
role text not null check (role in ('owner','admin','member','viewer')),
primary key (user_id, organization_id)
);
Jangan biarkan pengguna mengatur perannya sendiri lewat pembaruan profil biasa. Perubahan peran harus lewat endpoint khusus yang memeriksa izin.
3. Periksa izin di server, di satu tempat
Tulis satu helper — misalnya can(user, 'projects.delete', project) — dan panggil di setiap rute API, server action, dan tugas latar belakang yang membaca atau mengubah data. Satu fungsi pusat lebih mudah ditinjau dan diuji daripada pemeriksaan yang tersebar di kode. Tolak secara default: jika tidak ada aturan yang mengizinkan suatu tindakan, tindakan itu ditolak.
4. Batasi setiap kueri
Setiap kueri untuk data tim harus menyertakan tim: where organization_id = :currentOrg, bukan hanya where id = :id. Ini mencegah seseorang mengubah /projects/123 menjadi /projects/124 dan melihat proyek perusahaan lain. Kembalikan "tidak ditemukan" alih-alih "dilarang" untuk record milik tim lain, agar Anda tidak membocorkan bahwa record itu ada.
5. Tambahkan perlindungan di level database jika diperlukan
Row-level security (RLS) Postgres memungkinkan database menegakkan baris mana yang bisa dilihat setiap pengguna. Ini sangat penting jika browser berbicara langsung dengan database (seperti pada beberapa backend hosted), dan lapisan kedua yang berguna untuk tabel sensitif lainnya.
6. Cerminkan peran di antarmuka
Sekarang sembunyikan atau nonaktifkan apa yang tidak boleh dilakukan pengguna, agar aplikasi tidak membingungkan. Ini hanya untuk kegunaan; pemeriksaan di server yang melindungi.
7. Catat tindakan sensitif
Catat siapa yang mengubah peran, menghapus data, atau mengekspor record, dan kapan. Log audit membantu menjawab pertanyaan dukungan dan insiden.
8. Uji seperti penyerang
Masuk sebagai setiap peran dan coba setiap tindakan dalam tabel izin. Lalu coba hal-hal yang seharusnya tidak berhasil: panggil rute API admin sebagai penonton, ubah ID di URL dan permintaan, hapus diri sendiri sebagai pemilik terakhir. Menulis tes otomatis untuk tabel izin layak dilakukan setelah aturannya stabil.
Prompt yang berhasil
Tambahkan kontrol akses berbasis peran. Peran per organisasi: pemilik, admin, anggota, penonton, disimpan di tabel memberships. Izinnya ada di tabel ini: [tempel tabel Anda]. Buat satu helper server
can(user, action, resource), tolak secara default, dan gunakan di setiap rute API. Batasi setiap kueri dengan organization_id. Sembunyikan tindakan yang tidak boleh dilakukan pengguna di UI, tetapi jangan pernah mengandalkannya untuk keamanan.
Tinjau setiap rute API dan fungsi server di aplikasi ini. Untuk masing-masing, daftar data apa yang dibaca atau diubahnya, apakah ia memeriksa pengguna sudah login, apakah ia memeriksa perannya, dan apakah ia membatasi kueri ke organisasinya. Perbaiki yang tidak punya pemeriksaan, dan tunjukkan daftarnya kepada saya.
Tambahkan halaman /admin yang hanya bisa diakses admin, tempat pemilik dapat mengubah peran anggota. Cegah penghapusan atau penurunan peran pemilik terakhir, catat setiap perubahan peran beserta siapa yang melakukannya dan kapan, dan pastikan endpoint perubahan peran menolak siapa pun yang bukan pemilik.
Kesalahan umum
- Memeriksa peran hanya di front end. API tetap terbuka untuk siapa pun yang memanggilnya.
- Mempercayai ID dari klien —
userIdatauroledi body permintaan, alih-alih dari sesi. - Kueri tanpa batas yang mengambil data hanya berdasarkan ID record.
- Peran diperiksa di halaman tetapi tidak di rute API, ekspor, unduhan file, atau webhook.
- Admin berdasarkan alamat email yang ditulis langsung di kode (
if email === 'me@...'), mudah terlupakan dan sulit diubah. - Terlalu banyak peran terlalu cepat, yang tidak bisa dijelaskan siapa pun enam bulan kemudian.
- Sesi yang kedaluwarsa: pengguna yang diturunkan perannya tetap memiliki hak admin sampai ia keluar. Periksa peran dari database, atau segarkan, pada tindakan sensitif.
Daftar periksa RBAC
- Tabel izin ditulis dalam bahasa sehari-hari, kasus pinggir sudah diputuskan
- Server mengenali pengguna dari sesi, bukan dari data permintaan
- Peran disimpan di database; pengguna tidak bisa mengubah perannya sendiri
- Satu pemeriksaan izin terpusat, tolak secara default, dipakai di setiap rute
- Setiap kueri dibatasi ke organisasi atau kepemilikan pengguna
- Row-level security jika browser bisa menjangkau database
- UI menyembunyikan apa yang tidak boleh dilakukan pengguna (hanya untuk kegunaan)
- Tindakan sensitif dicatat
- Setiap peran diuji, termasuk panggilan API langsung dan ID yang diubah
Kontrol akses hanyalah satu item dari daftar yang lebih panjang; daftar periksa keamanan untuk aplikasi yang dibangun AI membahas sisanya. Jika Anda membuat alat untuk staf internal Anda sendiri, cara membangun alat internal menunjukkan tempat peran berperan.
RBAC di Mythex
Mythex tidak menyediakan sistem login atau peran bawaan untuk pengguna aplikasi Anda. Anda memilih pustaka atau penyedia auth dan mendeskripsikan perannya, lalu agen menghubungkannya ke kode Anda dan database Postgres proyek Anda (tambahkan login ke aplikasi Anda). Peran ruang kerja Mythex, seperti Owner dan Member, mengatur siapa yang bisa mengedit proyek Mythex Anda, bukan siapa yang bisa memakai aplikasi yang Anda rilis. Gunakan Plan mode untuk menyepakati tabel izin sebelum membangun, lalu gunakan prompt tinjauan di atas dan uji setiap peran di Preview sebelum merilis. Prompt keamanan di dokumentasi juga berguna sebagai langkah lanjutan.
Pertanyaan
Apa itu kontrol akses berbasis peran?
Kontrol akses berbasis peran (RBAC) menentukan apa yang boleh dilakukan setiap pengguna berdasarkan peran yang mereka miliki, seperti admin, editor, atau penonton. Izin dilekatkan pada peran, bukan pada individu, sehingga mengubah apa yang boleh dilakukan seseorang cukup dengan mengubah perannya.
Apa perbedaan antara autentikasi dan otorisasi?
Autentikasi memeriksa siapa seseorang, biasanya lewat login. Otorisasi memutuskan apa yang boleh dilihat dan dilakukan oleh orang yang sudah login itu. RBAC adalah salah satu cara melakukan otorisasi.
Apakah menyembunyikan tombol di antarmuka sudah cukup untuk membatasi akses?
Tidak. Siapa pun bisa memanggil API Anda secara langsung, jadi menyembunyikan tombol hanya mengubah apa yang dilihat orang. Setiap permintaan yang membaca atau mengubah data harus diperiksa di server terhadap peran pengguna dan kepemilikan atas record tersebut.
Apakah saya harus memakai row-level security Postgres?
Row-level security membiarkan database itu sendiri menegakkan baris mana yang boleh dibaca atau ditulis setiap pengguna, yang merupakan jaring pengaman yang kuat, terutama saat front end berbicara langsung dengan database. Ini menambah kerumitan, jadi banyak aplikasi menegakkan izin di kode server dan memakai row-level security sebagai lapisan tambahan untuk tabel sensitif.