Sebuah API bisa memakai HTTPS, OAuth2, rate limiting, dan API gateway sekaligus, lalu tetap membocorkan data ketika pengguna mengganti
GET /invoices/1043 menjadi GET /invoices/1044. Token valid, request lolos gateway, dan server mengembalikan invoice milik orang lain. Celah ini menempati urutan pertama OWASP API Security Top 10 2023 dengan nama Broken Object Level Authorization (BOLA).Daftar dua belas tips dari ByteByteGo mencakup lapisan yang benar, tetapi menyajikannya sejajar. Padahal beberapa tips adalah kontrol transport, beberapa memilih protokol, dan hanya satu baris, "Authorization", yang menyentuh tempat sebagian besar kebocoran API terjadi.
Dua belas tips dalam lapisan dan risiko OWASP
Kolom ketiga memetakan setiap tips ke kategori OWASP API Security Top 10 2023 yang paling dekat. Kolom keempat adalah catatan saya tentang batas kontrol tersebut.
Tips | Lapisan | Risiko OWASP 2023 | Batasnya |
Use HTTPS | Transport | API8 Security Misconfiguration | Melindungi data di jalan, tidak menentukan siapa boleh membaca data. |
Use OAuth2 | Identitas | API2 Broken Authentication | Framework otorisasi delegasi, bukan protokol login. |
Use WebAuthn | Identitas | API2 Broken Authentication | Untuk login manusia di browser, bukan untuk client mesin ke mesin. |
Use Leveled API Keys | Identitas | API2, API5 | Mengidentifikasi aplikasi pemanggil, bukan pengguna di baliknya. |
Authorization | Aplikasi | API1, API3, API5 | Harus diperiksa di setiap akses objek, field, dan fungsi. |
Rate Limiting | Edge dan aplikasi | API4 Unrestricted Resource Consumption, API6 | Batas per IP tidak cukup untuk alur bisnis yang mahal. |
API Versioning | Inventaris | API9 Improper Inventory Management | Versi lama yang tidak dimatikan menjadi permukaan serangan. |
Whitelisting | Jaringan | API8 | Allowlist IP berguna untuk integrasi tertutup, bukan pengganti autentikasi. |
Check OWASP API Security Risks | Proses | Semua | Daftar risiko, bukan checklist implementasi. |
Use API Gateway | Edge | API2, API4, API8 | Gateway tidak tahu siapa pemilik invoice 1044. |
Error Handling | Aplikasi | API8 | Pesan error untuk client, bukan stack trace. |
Input Validation | Aplikasi | API3, API7 Server Side Request Forgery | Validasi bentuk data tidak membuktikan hak mengubah field. |
Tabel ini memperlihatkan pola yang tidak terlihat dari daftar bernomor: kontrol di edge (HTTPS, gateway, allowlist, rate limit dasar) mudah dipasang sekali untuk semua endpoint, sedangkan tiga kategori teratas OWASP berada di kode aplikasi dan harus ditulis ulang di setiap handler.
OAuth2, WebAuthn, dan API key menjawab pertanyaan berbeda
Tiga tips identitas sering dibaca sebagai pilihan yang setara. RFC 6749 mendefinisikan OAuth 2.0 sebagai cara aplikasi pihak ketiga memperoleh akses terbatas ke layanan HTTP. Cara authorization server mengautentikasi pemilik resource secara eksplisit berada di luar cakupannya. Bila yang dibutuhkan adalah login pengguna dengan identitas terstandar, lapisannya adalah OpenID Connect di atas OAuth2, bukan OAuth2 saja.
WebAuthn Level 2 adalah API browser untuk credential berbasis public key yang terikat pada satu relying party. Ia memperkuat login pengguna dan menutup phishing password, tetapi tidak relevan bagi cron job yang memanggil API laporan. Tempatnya ada di depan authorization server, bukan di setiap endpoint API.
API key mengidentifikasi aplikasi. Saran "leveled" dalam sumber, yaitu key berbeda untuk read-only dan read-write, sejalan dengan prinsip least privilege. Namun key yang sama dipakai oleh semua pengguna aplikasi tersebut, sehingga tidak bisa menjawab apakah pengguna tertentu boleh membaca invoice tertentu. Untuk rincian cookie, session, dan token di sisi browser, saya sudah membahasnya di .
Otorisasi per objek tidak bisa diserahkan ke gateway
OWASP menyatakan pemeriksaan otorisasi tingkat objek perlu dipertimbangkan di setiap fungsi yang mengakses sumber data memakai ID dari pengguna. Gateway hanya melihat token dan path; ia tidak menyimpan relasi antara pengguna dan invoice. Pemeriksaan itu harus berada di lapisan yang memegang data.
Cara paling tahan regresi adalah memasukkan pemilik ke dalam query, bukan membaca objek lalu membandingkan pemiliknya belakangan:
app.get('/invoices/:id', async (req, res) => {
const invoice = await db.invoice.findFirst({
where: { id: req.params.id, tenantId: req.auth.tenantId },
select: { id: true, number: true, total: true, status: true },
})
if (!invoice) {
return res.status(404).type('application/problem+json').json({
type: 'about:blank',
title: 'Not Found',
status: 404,
})
}
res.json(invoice)
})Tiga keputusan terlihat di potongan ini. Filter
tenantId membuat invoice milik tenant lain tidak pernah dibaca dari database. Respons 404, bukan 403, tidak memberi tahu penyerang bahwa ID 1044 ada. Daftar select eksplisit menutup sisi baca dari API3 Broken Object Property Level Authorization: field baru di tabel tidak otomatis ikut terkirim.Sisi tulis API3 adalah mass assignment. Validasi skema yang hanya memeriksa tipe akan meloloskan body
{"status": "paid"} bila field status memang bertipe string. Skema input untuk update harus menyebut field yang boleh diubah oleh peran pemanggil, bukan meneruskan seluruh body ke ORM.Rate limiting perlu kunci yang tepat
RFC 6585 mendefinisikan status
429 Too Many Requests dan header Retry-After yang opsional, tetapi sengaja tidak menentukan cara server mengenali pengguna atau menghitung request. Pilihan itu justru inti desainnya.Batas per IP di gateway menahan lonjakan kasar, tetapi gagal ketika banyak pengguna berbagi satu NAT kantor, atau ketika penyerang menyebar request dari banyak IP. API4 dalam OWASP 2023 juga menyebut biaya per request ke penyedia SMS atau email. Endpoint
POST /otp membutuhkan batas per nomor tujuan dan per akun, bukan hanya per IP, karena setiap request menghasilkan tagihan.Error handling dan versi lama
RFC 9457, pengganti RFC 7807, memberi format
application/problem+json dengan member type, title, status, detail, dan instance. Bagian security considerations-nya menganjurkan agar detail implementasi seperti stack dump tidak tersedia lewat antarmuka HTTP. Format seragam membantu client, sedangkan stack trace cukup berada di log server dengan ID korelasi yang sama.Tips API versioning lebih tepat dibaca sebagai masalah inventaris. API9 Improper Inventory Management menyoroti host dan versi API yang tidak terdokumentasi atau tidak dimatikan.
/v1/invoices yang masih hidup tanpa perbaikan otorisasi yang sudah diterapkan di /v2 membuat perbaikan itu tidak berarti. Versi baru harus disertai jadwal mematikan versi lama dan daftar endpoint yang diperiksa terhadapnya.Urutan kerja yang saya sarankan dari tabel di atas: daftar semua endpoint yang menerima ID dari client, lalu pastikan setiap query di baliknya memuat pemilik atau tenant. Kontrol edge bisa menyusul karena sekali pasang berlaku untuk semua; pemeriksaan per objek tidak punya jalan pintas seperti itu.