Tinjauan Penanganan Galat yang Aman dan Pengungkapan Informasi
Setiap kegagalan memiliki dua audiens. Klien membutuhkan respons stabil yang berorientasi tindakan. Operator membutuhkan bukti diagnostik terlindungi. Mencampur keduanya membuka detail implementasi saat reconnaissance dan membuat pengguna menghadapi kegagalan yang membingungkan. CWE-209 menjelaskan pesan error yang memuat informasi sensitif tentang environment, pengguna, atau data terkait. Panduan OWASP Error Handling menyarankan respons generik untuk error tak terduga sementara detail dicatat di sisi server. Respons generik tidak menghilangkan kebutuhan monitoring, pemilik, atau remediasi.
Tetapkan peta respons
Bangun taksonomi error berdasarkan koreksi yang dapat dilakukan klien, bukan nama kelas exception. Error validasi dapat menyebut field dan format yang diizinkan. Respons autentikasi dan otorisasi tidak boleh mengonfirmasi status akun atau resource melebihi kebijakan. Kegagalan dependency boleh menyarankan coba lagi, tetapi tidak boleh mengembalikan hostname, respons provider, fragmen SQL, stack trace, source path, secret, atau versi framework. Error tak terduga mengembalikan problem identifier stabil dan pesan generik.
| Kelas kegagalan | Respons publik | Field bukti | Pemilik | Lulus / gagal |
|---|---|---|---|---|
| Input tidak valid | 400, kode field, panduan aman | request ID, kode field, ID aturan | Pemilik API | Lulus: input mentah tidak dipantulkan |
| Akses ditolak | 403, penolakan generik | request ID, ID kebijakan, outcome | Pemilik kontrol akses | Gagal: keberadaan resource bocor |
| Upstream tidak tersedia | 503, pesan aman untuk retry | request ID, kelas dependency, timeout | Pemilik layanan | Gagal: host, token, atau body upstream mentah dikirim |
| Exception tak terduga | 500, pesan generik | request ID, kelas error, cause terlindungi | Pemilik runtime | Gagal: stack trace atau path berkas sampai ke klien |
Artefak operasional selesai adalah katalog error berversi yang memuat skema respons, pemetaan status, pemilik, ambang alert, test case, target retensi, dan field tautan bukti. Katalog direview bersama perubahan rilis agar exception baru tidak diam-diam menjadi perilaku API publik.
Tempatkan translasi pada satu boundary
Tangani error yang sudah dikenal dekat validasi input; translasi exception yang tidak diketahui di boundary request terluar. Kode perlu membuat objek aman untuk klien sambil mempertahankan korelasi bagi operasi terbatas. Contoh untuk worker atau API handler:
type Problem = { code: string; message: string; requestId: string };
function internalProblem(requestId: string): Response {
const body: Problem = { code: "internal_error", message: "Request could not be completed.", requestId };
return Response.json(body, { status: 500, headers: { "Cache-Control": "no-store" } });
}
try {
return await performAction(request);
} catch (error) {
audit("request.failed", { requestId, errorClass: error instanceof Error ? error.name : "unknown" });
return internalProblem(requestId);
}Jangan serialisasi error.message, error.stack, objek request, hasil database, atau respons provider ke klien. Fungsi logging harus mengikuti kontrak redaksi; bila tidak, output HTTP aman masih dapat bocor lewat telemetry. Pastikan tooling debug mati pada konfigurasi produksi. CWE-209 secara khusus meminta detail minimum sesuai audiens dan memperingatkan password tidak boleh disimpan di log.
Uji jalur negatif dengan sengaja
Jalankan test seperti produksi untuk JSON malformed, encoding tidak valid, autentikasi hilang, objek tanpa otorisasi, route tidak dikenal, body terlalu besar, database timeout, DNS gagal, kuota habis, dan error runtime yang diinjeksi. Tangkap respons klien, header, record log, dan perilaku alert. Assert respons tidak memiliki marker untuk hostname internal, tabel SQL, source path, token, atau stack frame. Bandingkan error untuk akun atau resource yang ada dan tidak ada saat kebijakan meminta respons tidak dapat dibedakan.
OWASP Web Security Testing Guide mendukung pengujian sistematis alih-alih menganggap default framework aman. Halaman error framework, reverse proxy, platform serverless, dan error dari CDN juga harus direview karena lapisan luar dapat mengganti respons aplikasi.
Alur pengecualian dan remediasi
Detail diagnostik sementara tidak boleh dikirim ke klien publik. Bila staf on-call membutuhkan record lebih kaya saat insiden, pemilik membuat pengecualian berisi scope event, storage terlindungi, kelompok pembaca, waktu mulai dan berakhir, kelas data yang dikecualikan, persetujuan, serta tugas penghapusan. Contoh: EXC-ERR-011 mengizinkan status upstream tersanitasi dan jumlah retry pada log diagnostik terbatas selama 72 jam. Pengecualian tidak mengizinkan body, authorization header, atau query database. Saat berakhir, field tambahan dihapus; pemilik memverifikasi dengan test jalur gagal baru.
Jika kebocoran ditemukan, simpan bukti minimum, matikan respons verbose, identifikasi field bocor dan route terdampak, rotasi credential yang terungkap, nilai salinan pada log dan cache, lalu tambahkan regression case. Perbaiki mapper pusat atau konfigurasi, bukan satu endpoint, kecuali perilaku memang hanya dimiliki endpoint itu. Retest output publik dan diagnostik terbatas secara terpisah.
Penerimaan lulus bila kegagalan yang diharapkan memberi panduan aman, kegagalan tak terduga memakai respons generik stabil, debug produksi mati, test jalur negatif tidak menemukan marker, akses log dibatasi, dan katalog memiliki pemilik serta status remediasi. Kegagalan memblokir rilis untuk kebocoran eksternal aktif; pengecualian memerlukan persetujuan bertanggal dan kontrol kompensasi. Pengujian web dapat memvalidasi perilaku error yang terlihat dari luar.
Buktikan pemisahan publik-pribadi
Kirim request gagal terkendali dengan marker menyerupai hostname internal, lalu tangkap body HTTP, header, trace identifier, event log terbatas, dan alert. Hasil publik yang diharapkan adalah application/problem+json stabil tanpa marker; record privat membawa korelasi serta kelas error tersanitasi. Halaman error bermerek dari CDN atau proxy yang membuka detail origin adalah gagal meski handler benar. Pemilik route memperbaiki konfigurasi luar; pemilik insiden mencatat audiens terpapar dan retest.
Uji kegagalan dan penutupan
Latih satu kegagalan terkontrol dari request publik hingga dependensi backend. Kirim identifier sintetis tidak valid, timeout paksa, dan request objek tanpa hak. Respons eksternal yang diharapkan memiliki kelas status stabil, pesan umum, ID korelasi request bila disetujui, tanpa stack trace, query, hostname internal, kredensial, atau oracle keberadaan. Di internal, hubungkan ID request sama ke kelas error tersanitasi dan tindakan pemilik. Contoh perintah: curl -i https://app.example.test/api/orders/not-a-valid-id; output diharapkan adalah error klien terbatas, bukan HTML diagnostik framework.
Periksa perbedaan secara sengaja. Endpoint login, reset, undangan, dan lookup sering membocorkan ada-tidaknya akun atau objek lewat status, body, waktu, atau perilaku retry. Respons umum tetap harus mendukung pemulihan pengguna aman dan aksesibilitas; jangan menyembunyikan semua pesan validasi yang dapat ditindaklanjuti. Bedakan umpan balik format field dari fakta autentikasi atau otorisasi.
Bukti penutupan mencakup kasus request, respons eksternal mentah dengan data sintetis, event internal tersanitasi, revisi pemetaan error, dan hasil regression test. Buka ulang setelah upgrade framework, kebijakan API gateway baru, perubahan exception middleware, atau integrasi dependensi baru. Desain error selesai saat pengguna mendapat langkah berikutnya yang berguna dan penyerang tidak mendapat peta sistem tambahan.