Autentikasi vs Otorisasi & Cara Berpikir Keamanan
Membedakan autentikasi (siapa kamu) dan otorisasi (boleh apa), kode status 401 vs 403, model ancaman sederhana, dan prinsip dasar keamanan API.
Dua pertanyaan yang berbeda
Setiap kali sebuah permintaan masuk ke API, server perlu menjawab dua pertanyaan yang sering tertukar:
| Autentikasi (authentication) | Otorisasi (authorization) | |
|---|---|---|
| Pertanyaan | Siapa kamu? | Kamu boleh melakukan apa? |
| Contoh | Login dengan email dan sandi, token, sidik jari | Hanya admin boleh menghapus pengguna; kamu hanya boleh melihat catatanmu sendiri |
| Analogi | Satpam memeriksa kartu identitasmu di pintu gedung | Kartu aksesmu hanya membuka lantai 3, bukan ruang server |
| Kegagalan | Status 401 Unauthorized | Status 403 Forbidden |
| Urutan | Selalu lebih dulu | Dilakukan setelah identitas diketahui |
Cara mengingat: 401 berarti "saya belum tahu kamu siapa" (harusnya bernama unauthenticated). 403 berarti "saya tahu kamu siapa, tapi kamu tidak boleh". Mencampur keduanya membuat klien bingung: klien yang menerima 401 akan mencoba login ulang; klien yang menerima 403 tahu bahwa login ulang tidak akan membantu.
Kenapa keamanan API itu penting?
API adalah pintu masuk ke datamu. Aplikasi web, ponsel, dan pihak ketiga semua berbicara lewat API. Kesalahan kecil — lupa memeriksa kepemilikan data, membocorkan hash sandi, mempercayai token tanpa memverifikasi — bisa membuat data semua pengguna bocor. Kebocoran data berarti kerugian pengguna, kehilangan kepercayaan, bahkan sanksi hukum (di Indonesia ada UU Pelindungan Data Pribadi).
Cara berpikir seperti penyerang
Saat merancang sebuah endpoint, tanyakan: "Bagaimana jika seseorang sengaja mengirim sesuatu yang aneh?" Contoh pertanyaan rutin:
- Bagaimana kalau permintaan datang tanpa token? Dengan token palsu? Dengan token pengguna lain?
- Bagaimana kalau
iddi URL diganti dengan id milik orang lain (/catatan/1→/catatan/2)? - Bagaimana kalau body berisi field tambahan seperti
"role": "admin"? - Bagaimana kalau ada 10.000 percobaan login per menit?
- Bagaimana kalau pesan error mengungkap struktur database atau jejak kode?
Prinsip dasar yang akan kita pegang sepanjang course
| Prinsip | Artinya |
|---|---|
| Jangan percaya input | Semua yang datang dari klien (header, body, query, cookie, id di URL) dianggap tidak tepercaya sampai divalidasi. |
| Hak akses minimum | Beri pengguna dan layanan hanya izin yang benar-benar dibutuhkan. |
| Tolak secara default | Endpoint terlindungi kecuali sengaja dibuka (bukan sebaliknya). |
| Pertahanan berlapis | Jangan bergantung pada satu pengaman; kalau satu lapis jebol, lapis lain menahan. |
| Gagal dengan aman | Saat terjadi error, tolak akses — jangan buka akses. |
| Jangan bocorkan detail | Pesan error untuk penyerang harus sesedikit mungkin informasinya. |
Peta course ini
- Fondasi: hashing sandi, login, JWT.
- Akses: middleware, peran (RBAC), kepemilikan data, refresh token.
- Sesi & browser: cookie, sesi, CSRF, CORS.
- Pertahanan: validasi input, rate limit, header keamanan, error dan log aman.
- Lanjutan: reset sandi, MFA, OAuth, API key, webhook, rotasi kunci.
- Audit & proyek akhir: OWASP API Top 10 dan API Catatan Aman.
Catatan tentang latihan
Latihan berjalan di runtime Node mini di browser yang hanya menyediakan modul bawaan Node dan express. Karena itu kita membangun semuanya dari crypto (hash, HMAC, nilai acak). Ini disengaja: kamu akan paham isi dalamnya. Di proyek sungguhan, jangan menulis kriptografi sendiri — pakai library teruji (argon2/bcrypt, jose/jsonwebtoken, helmet, express-rate-limit). Setiap bab akan menyebut padanannya.
Kesalahan umum pemula
- Memakai 403 untuk "belum login" atau 401 untuk "tidak punya izin".
- Mengira "tidak ada tombolnya di UI" berarti aman. Penyerang memanggil API langsung, tidak lewat UI.
- Menyembunyikan endpoint (security by obscurity) alih-alih melindunginya.