Semua artikel
// Artikel

Checklist Pengujian Keamanan API OWASP untuk Tim Engineering

Dipublikasikan 9 Juni 2026

Review rilis API berbasis bukti

Mulailah dari manifest rilis, bukan nama kategori. Untuk setiap operasi, tulis pemanggil, method, skema input, data yang dikembalikan, perubahan state, dependency downstream, dan keputusan produk yang didukung. Ekspor gateway dapat menampilkan POST /v2/invoices/export saat file OpenAPI tidak memuatnya; selisih itu tetap terbuka sampai owner menerangkan apakah route sudah dihentikan, privat, atau aktif. Bandingkan manifest dengan route deployment pada setiap rilis.

Kerjakan satu baris pada satu waktu. Perubahan profil pengguna perlu diuji dengan field yang diizinkan, field yang ditolak, referensi objek asing, body rusak, pengiriman berulang, dan payload maksimum. Output yang diharapkan meliputi status HTTP, field respons, state database, state queue, event audit, dan pemanggilan provider. Reviewer membutuhkan peta akun uji dan capture tersamarkan bertimestamp, bukan pernyataan bahwa endpoint telah diperiksa.

Rilis gagal bila operasi pengubah state tidak memiliki uji positif dan negatif, data uji tidak dapat menunjukkan owner, atau gateway dan kontrak bertentangan. Perbaikan harus spesifik: tambah keputusan otorisasi layanan, batasi paginator, hapus route usang, atau dokumentasikan callback mitra beserta autentikasinya. Sesudah perbaikan, ulang kasus gagal dan operasi tetangga yang memakai middleware sama, lalu lampirkan kedua hasil ke catatan rilis.

Buat ledger test berisi ID operasi, hipotesis risiko, fixture, output HTTP yang diharapkan, state yang diharapkan, owner, dan tautan bukti. Review perubahan harus menolak operasi baru tanpa baris ledger. Bandingkan hasil akses negatif dengan request yang diizinkan memakai bentuk sama agar perbedaan status benar-benar berasal dari kebijakan, bukan input rusak. Untuk pekerjaan asinkron, periksa state job setelah penolakan dan pastikan tidak ada email, file, atau callback dibuat. Artefak penutup berupa diff ledger dan referensi regresi yang dijalankan mesin.

Catatan pelaksanaan checklist

Beri nomor setiap operasi dalam ledger rilis API. Catat kelas pemanggil, sensitivitas data, referensi objek, efek tulis, ukuran respons maksimum, dependency, dan perilaku rollback. POST /accounts/{id}/close memerlukan set test berbeda dari GET /accounts/{id}: penutupan dapat memicu queue, notifikasi, workflow retensi, serta perubahan izin. Lampirkan diff kontrak dan diff gateway pada baris ledger yang sama.

Jalankan request positif terkontrol, lalu ubah satu kondisi setiap kali: role pemanggil, ID tenant, properti body, nilai pagination, content type, replay key, dan timeout. Hasil yang diharapkan menyebut status HTTP, field terlihat, state database, state job, serta panggilan provider. Simpan kedua request ID dan query post-condition; respons ditolak belum cukup bila email atau ekspor muncul kemudian.

Reviewer rilis menggagalkan baris tanpa owner, kasus negatif, atau lokasi bukti. Perbaiki kontrak route sebelum deploy; perbaiki kebocoran state di batas layanan; perbaiki celah kuota sebelum dependency mahal. Untuk pekerjaan asinkron, periksa job selesai dan gagal setelah jendela test. Catatan akhir memuat nama test regresi, referensi patch, keputusan owner risiko, dan timestamp retest. Ini adalah bukti rilis, bukan klaim sertifikasi standar eksternal.

Uji bulk, input, dan output

Operasi bulk perlu dipisah per elemen dan aturan transaksi. PATCH /users dapat menolak properti tidak dikenal namun tetap mengizinkan mass assignment melalui objek preferensi bertingkat. Simpan bentuk input setelah validasi, bukan hanya hasil controller. Pada output, nyatakan allowlist field: respons 200 yang memuat metadata reset password atau penanda role internal tetap gagal walau keputusan aksesnya benar. Tandai kesegaran bukti; hasil uji sebelum kebijakan gateway berubah tidak menyetujui route yang diterbitkan kemudian. Owner checklist juga memeriksa dependency baru karena webhook atau penyimpanan file upstream dapat membuka jalur otorisasi dan resource terpisah.

Kasus perubahan akun

Gunakan akun sintetis dengan role pengguna biasa, admin tenant, dan service credential. Kirim pembaruan profil yang sah, lalu ulangi request yang sama dengan isAdmin, tenantId, dan billingPlan pada body. Respons penolakan harus tidak mengubah record, tidak menulis event perubahan hak, serta tidak mengantrikan notifikasi. Uji juga daftar dengan limit maksimum dan cursor rusak. Simpan request ID, snapshot record sebelum-sesudah, keputusan kebijakan, dan hasil job worker. Bila kontrak menyebut field baru tetapi gateway memblokirnya, tandai selisih sebagai kegagalan perubahan sampai owner produk serta engineering menyetujui perilaku yang sama.

Rekonsiliasi kontrak dan runtime

Ambil ekspor gateway serta kontrak OpenAPI dari kandidat rilis yang sama. Normalisasi method dan path, lalu temukan operasi yang hanya ada pada satu sumber. Untuk setiap selisih, periksa route deployment dan penggunaan klien sebelum menetapkan owner. Endpoint pensiun baru lulus bila tidak mengembalikan data bisnis dan monitoring menunjukkan perilaku migrasi yang diharapkan produk. Pemeriksaan ini mencegah dokumentasi menjadi inventaris optimistis.

Untuk kasus pembaruan properti, kirim displayName valid, lalu kirim role, tenantId, dan preferences.plan bertingkat. Bandingkan kolom tersimpan serta event domain yang dipancarkan. Kembalikan 400 atau 403 menurut kebijakan validasi, tetapi jangan memantulkan nilai sensitif yang ditolak. Lanjutkan dengan request sah untuk membuktikan aturan tidak memblokir pembaruan yang benar. Simpan assertion skema respons dan hasil query database bersama baris rilis.

Pengecualian adalah operasi bernama dengan tanggal migrasi dan limit kompensasi, bukan waiver umum. Saat tanggal tiba, hapus allowance gateway lalu jalankan probe route. Bila probe masih mencapai handler, rilis tetap diblokir sampai artefak deployment diperbaiki.

Artefak rilis

OperasiOwnerStatusBuktiHasil yang diharapkanHasil aktualPengecualianPenutupan
POST /v2/invoices/exportowner layanan billingBersyaratdiff gateway/OpenAPI, ID request ditolak, query state job, event audittenant asing mendapat 403; tanpa job ekspor, file, atau callback403 dikembalikan; tanpa job atau file; route tidak ada di OpenAPIroute mitra belum terdokumentasi sampai 2026-06-30 dengan kuota gateway dan approver bernamatambah entri kontrak, ulang kasus ditolak dan diizinkan, tautkan regresi ke ledger rilis

Sumber

Punya sistem yang perlu diuji?