Anatomi Ancaman Umum: OWASP API Security Basics

Di artikel sebelumnya, kita bahas kenapa keamanan penting dan mindset defense-in-depth. Sekarang saatnya membedah apa saja ancaman spesifik yang paling sering menyerang API. Kita pakai kerangka OWASP API Security Top 10 — daftar ancaman API paling umum yang disusun komunitas keamanan global — sebagai peta, supaya begitu masuk ke sesi praktik, kamu tahu persis ancaman mana yang sedang kita cegah di tiap langkah.

Broken Object Level Authorization (BOLA) — Ancaman #1

Ini ancaman API PALING umum, dan persis skenario yang dibahas di Bagian 1: user bisa mengakses data milik user LAIN, cuma dengan mengganti ID di request — misalnya GET /api/tasks/42 menjadi GET /api/tasks/43, dan server tidak pernah mengecek apakah task #43 itu benar-benar milik user yang sedang login.

User A login → GET /api/tasks/42  → task milik User A → OK
User A login → GET /api/tasks/43  → task milik User B → SEHARUSNYA ditolak, tapi API bilang OK

Ini bug otorisasi klasik: autentikasi-nya benar (kita tahu siapa yang login), tapi otorisasi-nya bolong (kita tidak cek apakah dia BERHAK atas resource spesifik itu). Kita akan bangun proteksi ini secara eksplisit di Bagian 4.

Broken Authentication — Ancaman #2

Masalah di lapisan "membuktikan identitas". Beberapa bentuk umum:

Password disimpan dalam bentuk plaintext atau di-hash dengan algoritma lemah (MD5, SHA1 tanpa salting) — sekali database bocor, semua password langsung terbongkar.

Token/session yang tidak pernah kedaluwarsa, atau gampang ditebak.

Tidak ada proteksi terhadap percobaan login bertubi-tubi (brute force).

Kita selesaikan lewat password hashing yang benar dan JWT dengan masa berlaku terbatas di Bagian 3, plus rate limiting di Bagian 4.

Excessive Data Exposure — Ancaman #3

API mengembalikan LEBIH BANYAK data daripada yang sebenarnya dibutuhkan client, dengan asumsi "toh frontend cuma menampilkan sebagian". Masalahnya: response API bisa dilihat langsung lewat DevTools browser atau tool seperti Postman — apa pun yang dikirim server, bisa dilihat siapa pun yang bisa menyadap response itu.

Contoh konkret: endpoint login yang mengembalikan seluruh objek User dari database, termasuk hashed_password-nya. Walaupun ter-hash, tidak ada alasan itu perlu dikirim ke client sama sekali.

# BURUK — mengembalikan objek database mentah-mentah
return user  # ikut membawa hashed_password

# BAIK — response model eksplisit, cuma field yang memang perlu
class UserRead(BaseModel):
    id: int
    username: str
    created_at: datetime

Ini persis kenapa kita selalu memisahkan response model dari model database sejak seri FastAPI — bukan cuma soal rapi, tapi soal keamanan.

Injection — Ancaman #4

Data yang dikirim user diperlakukan sebagai KODE, bukan cuma data — paling terkenal lewat SQL injection: kalau query database dibangun dengan menggabung string mentah dari input user, penyerang bisa menyisipkan perintah SQL tambahan.

# BURUK — rentan SQL injection
query = f"SELECT * FROM users WHERE username = '{username}'"
# input username: "admin' OR '1'='1" → query jadi selalu TRUE, bypass login!

# BAIK — parameterized query, input SELALU diperlakukan sebagai data
session.exec(select(User).where(User.username == username))

Kabar baiknya: ORM modern seperti SQLModel/SQLAlchemy yang sudah kita pakai sejak awal seri FastAPI otomatis memakai parameterized query di belakang layar — kita akan buktikan ini secara konkret (termasuk mencoba "menyerang" API kita sendiri) di Bagian 5.

Security Misconfiguration — Ancaman #5

Ini kategori luas untuk kesalahan konfigurasi yang membuka celah — bukan bug di logic aplikasi, tapi di cara aplikasinya di-deploy dan dikonfigurasi:

Credential/secret hardcode di kode atau ter-commit ke git.

CORS yang mengizinkan SEMUA origin (*) padahal tidak perlu.

Header keamanan HTTP yang hilang, membuka celah untuk serangan seperti clickjacking.

Pesan error yang menampilkan detail internal (stack trace, versi library) ke user biasa.

Kita bahas dan perbaiki semuanya secara eksplisit di Bagian 6.

Unrestricted Resource Consumption — Ancaman #6

API tanpa batas — tidak ada limit berapa kali satu user boleh memanggil endpoint dalam rentang waktu tertentu. Ini membuka pintu untuk brute force (coba password berkali-kali), scraping data besar-besaran, atau sekadar membebani server sampai tidak responsif untuk user lain. Kita selesaikan dengan rate limiting di Bagian 4.

Peta Seri Ini vs Ancaman OWASP

Supaya jelas kaitannya, berikut peta ancaman yang dibahas di atas dengan artikel praktik yang menanganinya:

Ancaman	Ditangani di
Broken Authentication	Bagian 3
Broken Object Level Authorization	Bagian 4
Unrestricted Resource Consumption	Bagian 4
Injection	Bagian 5
Excessive Data Exposure	Bagian 5 (response model)
Security Misconfiguration	Bagian 6
Kerentanan dari dependency pihak ketiga	Bagian 7

Bukan kebetulan urutan ini mengikuti urutan yang paling sering jadi celah nyata di API production sungguhan — kita akan tutup satu per satu, dengan bukti konkret di tiap langkah, bukan cuma teori.

Rangkuman

BOLA — user bisa akses data user lain cuma dengan mengganti ID, karena otorisasi tidak dicek per-resource.

Broken Authentication — password lemah, token tidak kedaluwarsa, tanpa proteksi brute force.

Excessive Data Exposure — API mengembalikan lebih banyak data daripada yang seharusnya, mengandalkan frontend untuk "menyaring".

Injection — data user diperlakukan sebagai kode; solusinya parameterized query, sudah default di ORM modern.

Security Misconfiguration — kesalahan di konfigurasi deployment, bukan logic aplikasi.

Unrestricted Resource Consumption — tanpa rate limiting, API rentan disalahgunakan lewat volume request.