Wawancara Backend: Bagaimana Cara Anda Merancang API Unggah File yang Aman?

Petunjuk dan Skenario yang Berlaku

Layanan dokumen B2B multi-tenant memungkinkan pengguna terautentikasi mengunggah lampiran PDF, JPEG, dan PNG, dengan batas 20 MiB per file. Setelah pemrosesan, hanya anggota terotorisasi dari tenant yang sama yang dapat mengunduh file. Klien mengontrol byte, nama file asli, ekstensi, Content-Type, dan ukuran yang dideklarasikan, sehingga setiap nilai tersebut tidak tepercaya (untrusted).

Rancang API unggah, pemindaian, publikasi, dan unduh yang aman. Jelaskan bagaimana rancangan ini mencegah:

• web shell, tipe data palsu (spoofed types), ekstensi ganda, path traversal, dan penimpaan objek (object overwrite);
• PDF berbahaya, eksploitasi parser gambar, malware, dan file polyglot;
• akses lintas-tenant, kebocoran URL objek publik, dan rendering inline yang berbahaya;
• permintaan berukuran melebihi batas (oversized requests), kuota penyimpanan habis, perebutan pemindaian (scan contention), dan pemindai mati (scanner outages);
• file diganti setelah lolos pemindaian, serta kerusakan status akibat pemanggilan penyelesaian (completion) yang duplikat.

Batas 20 MiB, tiga format yang diizinkan, dan model tenant B2B adalah batasan wawancara dan bukan rekomendasi keamanan universal. Kandidat harus menghubungkan identitas, protokol unggah, penyimpanan objek, pekerjaan asinkron, dan otorisasi pengunduhan ke dalam batas pertahanan yang kokoh. Kompetensi intinya adalah keamanan API backend dan layanan, sehingga kategorinya adalah backend.

Apa yang Dievaluasi oleh Pewawancara

Pertama, dapatkah kandidat menetapkan invarian? Byte yang belum lolos keputusan keamanan tetap berada dalam karantina dan tidak dapat dibaca oleh pengguna bisnis, di-parse oleh aplikasi, atau disajikan dari origin utama aplikasi. Nama file dari klien tidak pernah dijadikan path penyimpanan. Setiap pembacaan diotorisasi ulang.

Kedua, apakah mereka memahami defense in depth (pertahanan berlapis) untuk validasi tipe data? Ekstensi, Content-Type permintaan, tanda tangan file (file signature), dan hasil parser masing-masing hanya memberikan bukti parsial. Layanan harus menggabungkan allowlist bisnis, normalisasi, parsing struktural, pemindaian malware, dan, jika sesuai, re-encoding atau pelucutan dan rekonstruksi konten (content disarm and reconstruction).

Ketiga, dapatkah mereka merancang state machine asinkron yang eksplisit? Menerima byte hanya berarti bahwa suatu objek telah mencapai karantina. Ini tidak berarti bahwa file tersebut telah tersedia. API membutuhkan status pemrosesan, tersedia, ditolak, dan kegagalan teknis, dengan aturan percobaan ulang (retry), batas waktu (timeout), dan pembersihan yang presisi.

Keempat, apakah mereka menyadari adanya scanning race? Pemindai menilai satu urutan byte tertentu. Jika kunci objek yang sama dapat ditimpa setelahnya, catatan AVAILABLE dapat mengarah ke konten yang tidak pernah dipindai. Keputusan harus terikat pada versi objek yang tidak dapat diubah (immutable) atau hash konten, dan penerbitan harus bersifat kondisional.

Kelima, apakah mereka memasukkan pengambilan kembali file ke dalam threat model? Kunci acak mengurangi kemungkinan tebakan tetapi tidak menggantikan otorisasi tenant dan objek. Unduhan memerlukan handler terkontrol atau signed URL berumur pendek, header respons yang aman, origin yang terisolasi, dan kebijakan caching yang disengaja.

Pertanyaan Klarifikasi Sebelum Menjawab

• Bagaimana file akan digunakan? Hanya unduh, pratinjau browser, ekstraksi teks, pembuatan thumbnail, dan pemrosesan pihak ketiga memiliki risiko yang berbeda. Setiap parser tambahan menambah attack surface.
• Apakah ketiga format tersebut cukup? Skenario ini dapat menolak ZIP, Office, dan format lainnya. Mendukung arsip akan memerlukan batasan pada kedalaman, jumlah anggota, ukuran setelah diekstrak, dan rasio kompresi.
• Bagaimana pengguna mengautentikasi? Autentikasi cookie memperkenalkan kontrol CSRF. Bearer token tetap membutuhkan kontrol CORS, cakupan (scope), dan pencegahan kebocoran yang tepat.
• Apakah unggahan langsung ke penyimpanan objek (direct-to-object-storage) diperlukan? API dapat melakukan streaming untuk file kecil. Pada konkurensi yang lebih tinggi, API dapat menerbitkan kredensial berumur pendek yang dibatasi untuk satu objek karantina dan memverifikasi objek sebenarnya setelah diunggah.
• Siapa yang boleh mengunggah, memeriksa status, mengunduh, dan menghapus? Tentukan peran tenant, kepemilikan objek, dan persyaratan audit secara terpisah; hanya memeriksa bahwa pengguna telah masuk tidaklah cukup.
• Berapa SLA pemindaian? Tentukan waktu tunggu, jumlah percobaan ulang, perilaku fail-closed, dan status yang ditampilkan kepada pengguna saat terjadi pemadaman (outage).
• Apakah ada persyaratan kepatuhan atau residensi data? Kunci enkripsi, retensi, catatan audit, penghapusan, dan pembersihan cadangan mungkin memiliki batasan.
• Apa yang menjadi tolok ukur keberhasilan? Byte tersimpan, pemindaian lolos, dan unduhan terotorisasi adalah tiga tonggak pencapaian yang layak mendapatkan semantik API terpisah.

Kerangka Jawaban 30 Detik

\"Saya akan memulai dengan tiga invarian: file yang belum dipindai hanya ada di karantina; server menghasilkan kunci penyimpanan sementara nama file asli tetap menjadi metadata terbatas; dan setiap unduhan melakukan otorisasi tenant dan objek. Siklus hidupnya adalah PENDING_UPLOAD → QUARANTINED → SCANNING → AVAILABLE/REJECTED/FAILED.

Saat membuat sesi unggah, layanan memeriksa peran pengguna, kuota, format yang diizinkan, dan batas 20 MiB, lalu menghasilkan kunci objek yang tidak dapat ditebak dan tidak dapat ditimpa. Byte di-stream ke penyimpanan karantina non-eksekusi dan non-publik. Server memeriksa ukuran sebenarnya, ekstensi yang dinormalisasi, tanda tangan file, dan output parser yang dibatasi, lalu worker terisolasi memindai malware. Hasil keputusan mengikat pada versi objek atau SHA-256, dan penerbitan hanya berhasil jika nilai-nilai tersebut masih cocok.

Untuk pengunduhan, layanan memeriksa ulang izin tenant dan objek, lalu mengembalikan signed URL berumur pendek atau melakukan streaming objek dengan Content-Disposition: attachment, tipe aman yang akurat, dan X-Content-Type-Options: nosniff. Kegagalan pemindai membuat objek tetap tidak tersedia dan memicu percobaan ulang yang dibatasi. Kuota, rate limit, konkurensi, batas waktu, dan pembersihan siklus hidup membatasi penggunaan sumber daya. Saya akan memvalidasi rancangan ini dengan pemalsuan tipe, nama file berbahaya, sampel uji malware, stream berukuran berlebih, penyelesaian duplikat, penggantian objek, dan akses lintas-tenant.\"

Pembahasan Mendalam Langkah-demi-Langkah

Langkah 1: Tentukan batas kepercayaan dan invarian keamanan

Klien mengontrol setiap byte multipart, nama file, Content-Type, ukuran yang dideklarasikan, dan urutan permintaan. API gateway, layanan aplikasi, event object-store, dan antrean pemindaian juga dapat menduplikasi, menunda, atau mengubah urutan pekerjaan. Bangun rancangan di sekitar invarian ini:

1. Objek karantina tidak memiliki akses baca publik dan tidak dapat dieksekusi oleh server web.
2. Hanya objek AVAILABLE yang terotorisasi yang dapat diunduh.
3. Nilai tenant_id dari catatan bisnis berasal dari konteks terautentikasi, bukan field permintaan yang dikirimkan secara bebas.
4. Nama file asli tidak pernah digunakan dalam pembentukan path atau pencarian objek.
5. Keputusan keamanan terikat pada byte yang tidak dapat diubah; penerbitan tidak dapat mentransfer keputusan tersebut ke versi lain.
6. Pengecualian (exception), batas waktu, atau hasil yang tidak pasti selalu menghasilkan fail-closed.

Mengacak nama file dan menjaga privasi objek menyelesaikan masalah yang berbeda. Kunci objek acak mencegah penimpaan, manipulasi path, dan tebakan mudah. Otorisasi dan penyimpanan privat menyediakan kerahasiaan. Rancangan ini membutuhkan keduanya.

Langkah 2: Pisahkan penerimaan dari ketersediaan dengan state machine

State machine minimal adalah:

PENDING_UPLOAD
  ├─ bytes verified ─> QUARANTINED ─> SCANNING
  │                                      ├─ safe ─> AVAILABLE
  │                                      ├─ malicious/invalid ─> REJECTED
  │                                      └─ scanner unavailable ─> FAILED
  └─ expired/abandoned ─> EXPIRED

POST /uploads membuat sesi dan mengembalikan upload_id. Untuk unggahan langsung, endpoint ini juga mengembalikan kredensial berumur pendek yang hanya dapat menulis ke objek karantina yang ditentukan. POST /uploads/{id}/complete memicu verifikasi tepercaya dan pemindaian, sehingga 202 Accepted adalah respons yang tepat. GET /uploads/{id} melaporkan status. Titik masuk unduhan hanya muncul untuk AVAILABLE.

Setiap transisi menggunakan kondisi basis data. Misalnya, hanya catatan yang saat ini berada di QUARANTINED yang dapat masuk ke SCANNING. Pengiriman antrean duplikat atau panggilan penyelesaian yang berulang kali oleh karena itu hanya menerapkan transisi yang sama paling banyak satu kali. FAILED berarti kegagalan pemrosesan teknis; REJECTED berarti file atau kebijakan tidak valid. Menggabungkannya menjadi satu kesalahan yang tidak jelas akan melemahkan pemulihan dan auditabilitas.

Langkah 3: Terima byte dengan aman dan batasi sumber daya

Pada pembuatan sesi, periksa izin unggah, sisa kuota tenant, laju pengguna, dan format bisnis yang diminta. Hasilkan upload_id acak dan kunci objek seperti quarantine/{tenant-id}/{uuid}. Normalisasi nama file asli untuk panjang, karakter kontrol, dan Unicode, lalu simpan hanya sebagai metadata tampilan.

Ketika API bertindak sebagai proksi unggahan, lakukan streaming byte ke dalam karantina dan hitung ukurannya saat membaca. Hentikan segera setelah melebihi 20 MiB daripada melakukan buffering seluruh file di memori proses. Pada unggahan langsung, batasi cakupan tanda tangan seketat mungkin sesuai kemampuan sistem penyimpanan berdasarkan metode, kunci objek, masa kedaluwarsa, dan ukuran. Setelah itu, layanan tepercaya tetap membaca metadata objek dan memverifikasi panjang sebenarnya, versi, dan kepemilikan. Layanan tidak pernah mempercayai permintaan lengkap dari klien.

Bucket atau direktori karantina bersifat privat secara default, non-eksekusi, terisolasi dari origin aplikasi utama, dan diakses melalui kredensial dengan hak akses terendah (least-privilege). Sesi yang kedaluwarsa, unggahan yang ditinggalkan, dan status pemindaian akhir memerlukan pembersihan siklus hidup sehingga objek yatim (orphaned objects) tidak menghabiskan kuota tanpa batas.

Langkah 4: Gabungkan validasi tipe, parsing, dan pemindaian konten berbahaya

Pemeriksaan dapat berjalan dari yang berbiaya rendah hingga yang tinggi, tetapi tidak ada satu lapisan pun yang dapat menghasilkan AVAILABLE:

1. Terapkan allowlist PDF, JPEG, dan PNG pada ekstensi yang telah dinormalisasi.
2. Perlakukan Content-Type dari klien sebagai petunjuk semata. Tolak ketidakcocokan yang jelas, tetapi jangan pernah menggunakannya sebagai bukti.
3. Periksa tanda tangan (magic bytes) dan struktur lengkap sehingga awalan yang valid saja tidak dianggap cukup.
4. Gunakan parser yang diperbarui dan dibatasi untuk mengonfirmasi bahwa seluruh file dapat di-parse.
5. Jalankan pemindaian malware di worker terisolasi dan catat versi mesin serta aturannya.
6. Lakukan re-encoding pada gambar yang telah didekode, dan pertimbangkan pelucutan dan rekonstruksi konten (CDR) untuk PDF jika model risiko membenarkannya.

Pemindai dan parser memproses byte yang dikendalikan oleh penyerang. Jalankan mereka di sandbox dengan batasan CPU, memori, disk sementara, waktu, dan akses jaringan. Skenario ini menolak arsip, yang menghilangkan cabang decompression-bomb, nesting, dan path-traversal arsip. Antivirus tidak membuktikan keamanan mutlak, sehingga isolasi penyimpanan, pengambilan yang aman, dan parsing minimal tetap diperlukan.

Langkah 5: Ikat keputusan pada byte yang tidak dapat diubah sebelum menerbitkan

Job pemindaian membaca version_id karantina yang tidak dapat diubah dan menghitung SHA-256. Hasilnya mencakup setidaknya upload_id, versi objek, hash, ukuran sebenarnya, tipe yang terdeteksi, versi mesin pemindai, dan hasil keputusan (verdict).

Penerbitan melakukan transisi basis data kondisional. Catatan harus masih berstatus SCANNING, dan versi objek serta hash-nya harus tetap sama dengan input pemindaian sebelum dapat menjadi AVAILABLE. Penyimpanan objek juga mencegah versi tersebut ditimpa. Jika sistem menyalin file ke area yang disetujui, target menerima kunci acak baru dan operasi penyalinan mengidentifikasi versi sumber yang tepat. Setiap ketidakcocokan menyebabkan karantina ulang atau penolakan daripada menggunakan kembali keputusan lama.

Pengikatan ini menutup celah time-of-check-to-time-of-use (TOCTOU). Penyerang tidak dapat mengunggah byte yang aman, mendapatkan hasil lolos, lalu mengganti kunci yang sama dengan byte berbahaya. Tanpa versioning pada penyimpanan, gunakan kunci objek write-once atau penyimpanan berbasis konten (content-addressed storage), dan buat catatan bisnis hanya merujuk ke objek akhir yang tidak dapat diubah.

Langkah 6: Otorisasi unduhan dan kendalikan interpretasi browser

GET /files/{id}/download mengambil tenant saat ini dari autentikasi, lalu memeriksa kepemilikan objek, peran, status penghapusan, dan status AVAILABLE. Penggunaan UUID tidak menghilangkan pemeriksaan-pemeriksaan tersebut. Setelah otorisasi, aplikasi dapat melakukan streaming objek atau menerbitkan signed URL berumur pendek yang terikat pada satu objek dan operasi.

Untuk lampiran yang tidak memerlukan pratinjau, kembalikan Content-Disposition: attachment, nama file tampilan yang dienkode dengan aman, tipe media yang dikonfirmasi oleh server, dan X-Content-Type-Options: nosniff. Mengisolasi origin file dari domain cookie aplikasi utama mengurangi kemungkinan konten aktif memengaruhi sesi primer. Jaga agar signed URL berumur pendek karena perubahan izin pengguna biasanya tidak langsung mencabut URL yang telah diterbitkan.

Jalur pengambilan juga memerlukan kontrol laju dan bandwidth, log audit otorisasi, dan keputusan eksplisit mengenai apakah proksi atau cache boleh menyimpan respons privat. Log mencatat ID objek, tenant, pelaku, dan hasil, tetapi tidak menyimpan konten file atau signed URL yang dapat digunakan kembali.

Langkah 7: Rancang penanganan kegagalan, idempoten, kuota, dan observabilitas

Ketika pemindaian mengalami batas waktu (timeout) atau tidak tersedia, file tetap tidak tersedia. Worker dapat mencoba lagi dalam jumlah terbatas dengan backoff. Percobaan ulang yang habis akan masuk ke FAILED untuk pemulihan manual atau otomatis yang terkontrol. Hasil berbahaya atau struktur yang tidak valid secara definitif masuk ke REJECTED, dan byte di karantina dihapus sesuai kebijakan retensi.

Endpoint pembuatan dapat menerima idempotency key sehingga batas waktu klien tidak membuat beberapa sesi. Penyelesaian, konsumsi pemindaian, dan penghapusan menggunakan transisi status kondisional untuk memastikan idempotensi. Batasan konkurensi mencakup unggahan per pengguna, total byte tenant, ukuran per file, kedalaman antrean, dan slot pemindaian per tenant sehingga satu tenant tidak dapat memonopoli kapasitas global.

Metrik yang berguna meliputi waktu di setiap status, byte karantina, sesi kedaluwarsa, tingkat kelolosan/penolakan/kegagalan pemindaian, percobaan ulang, usia antrean, batas waktu parser, penolakan lintas-tenant, dan kegagalan otorisasi unduhan. Log audit mencatat transisi, versi objek, hash, kebijakan, dan versi pemindai, memungkinkan operator menjawab byte mana yang dinilai di bawah aturan apa secara tepat.

Langkah 8: Validasi seluruh alur dengan matriks adversarial

Minimal, uji hal berikut:

1. .jpg.php, variasi huruf besar-kecil, null bytes, dan nama file Unicode berukuran berlebih;
2. Content-Type palsu, awalan valid dengan ekor berbahaya, PDF rusak, dan file polyglot;
3. file uji EICAR di lingkungan yang aman, ditambah sampel yang memicu batas waktu parser atau batas sumber daya;
4. tepat 20 MiB, lebih satu byte, panjang yang hilang, stream yang lambat, dan banyak unggahan konkuren;
5. idempotency key yang sama, panggilan penyelesaian konkuren, pesan antrean duplikat, dan hasil pemindaian yang usang;
6. percobaan penggantian objek selama pemindaian, membuktikan bahwa ketidakcocokan versi atau hash tidak dapat diterbitkan;
7. tenant lain membaca status, mengunduh, atau menghapus objek, dengan setiap permintaan ditolak;
8. pemadaman pemindai, batas waktu job, restart aplikasi, dan pembersihan objek yatim;
9. perilaku pengunduhan untuk attachment, tipe media, nosniff, caching, dan kedaluwarsa signed-URL.

Kelulusan membutuhkan keamanan dan kebenaran bisnis secara bersamaan: file yang ditolak tidak pernah menerima jalur unduhan, file yang aman pada akhirnya tersedia, percobaan ulang tidak membuat catatan duplikat, permintaan tidak sah tidak membocorkan data, kegagalan tetap tertutup (fail-closed), penggunaan sumber daya tetap dibatasi, dan jejak audit dapat merekonstruksi seluruh rantai keputusan.

Contoh Jawaban Kuat

\"Saya akan membagi proses unggah menjadi tahap karantina, keputusan, dan publikasi, dengan invarian bahwa pengguna bisnis tidak akan pernah dapat membaca byte yang belum lolos keputusan. Saat membuat sesi, saya mengambil tenant_id dari autentikasi, memeriksa peran, batas 20 MiB, kuota tenant, dan allowlist PDF/JPEG/PNG, serta menghasilkan kunci karantina acak yang tidak dapat ditimpa. Nama file asli tetap menjadi metadata tampilan yang dinormalisasi dan dibatasi panjangnya.

Byte di-stream melalui API atau menggunakan kredensial berumur pendek yang dibatasi pada kunci karantina tersebut. Saat selesai, server memverifikasi ukuran sebenarnya, versi objek, dan kepemilikan, memindahkan catatan secara kondisional dari PENDING_UPLOAD ke QUARANTINED, dan memindai secara asinkron. Validasi menggabungkan ekstensi, tipe yang dideteksi server, parsing struktural penuh, pemindaian malware, dan re-encoding yang sesuai. Pemindai berjalan dengan sumber daya dan akses jaringan yang dibatasi.

Pemindai membaca versi yang tidak dapat diubah dan menghitung SHA-256. Catatan hanya dapat menjadi AVAILABLE jika masih berstatus SCANNING dan versi serta hash-nya cocok dengan input pemindaian. Oleh karena itu, mengganti file aman setelah pemindaian tidak dapat menggunakan kembali hasil keputusan lama. Pemadaman pemindai menghasilkan fail-closed dengan percobaan ulang terbatas; konten yang pasti berbahaya atau tidak sesuai menjadi REJECTED.

Setiap pengunduhan memeriksa izin tenant, izin objek, dan status AVAILABLE sebelum melakukan streaming atau menerbitkan URL berumur pendek. Lampiran menggunakan origin terisolasi, Content-Disposition: attachment, dan X-Content-Type-Options: nosniff. Saya kemudian akan menguji pemalsuan tipe, EICAR, stream berukuran berlebih, penyelesaian duplikat, race condition penggantian objek, pembacaan lintas-tenant, dan pemadaman pemindai sambil memantau durasi status, byte karantina, usia antrean, dan versi pemindai.\"

Kesalahan Umum

• Hanya memeriksa ekstensi → ekstensi ganda, perubahan huruf besar-kecil, dan konten yang disamarkan dapat melewatinya → gabungkan allowlist bisnis, normalisasi, tanda tangan, parsing struktural, dan pemindaian.
• Mempercayai Content-Type → klien dapat menentukan header permintaan → gunakan hanya untuk penyaringan awal dan deteksi tipe akhir di server.
• Menggunakan nama file asli sebagai path → path traversal, penimpaan, dan bug normalisasi sistem file menjadi mungkin terjadi → hasilkan kunci objek acak dan pertahankan nama hanya sebagai metadata terbatas.
• Membuat byte tersimpan langsung dapat diunduh → byte berbahaya terekspos sebelum pemindaian selesai → gunakan karantina dan jadikan AVAILABLE sebagai satu-satunya syarat penerbitan.
• Mengeklaim bahwa lolos antivirus menjamin keamanan mutlak → sampel baru, bug parser, dan konten aktif masih mungkin terjadi → pertahankan isolasi, parsing minimal, header aman, dan otorisasi.
• Memindai kunci yang dapat ditimpa → hasil lolos dapat berlaku untuk byte pengganti berikutnya → ikat versi yang tidak dapat diubah atau hash konten dan publikasikan secara kondisional.
• Memperlakukan UUID sebagai otorisasi → ID objek yang bocor dapat memungkinkan pembacaan lintas-tenant → lakukan otorisasi objek untuk pemeriksaan status, pengunduhan, dan penghapusan.
• Mempercayai konfirmasi penyelesaian dari klien setelah unggah langsung → klien dapat memalsukan ukuran, tipe, atau kepemilikan → baca metadata objek tepercaya dan bukti byte di server.
• Fail-open saat pemindai mati → kegagalan infrastruktur menjadi jalan pintas keamanan → terapkan fail-closed, coba ulang dalam batas wajar, dan tampilkan status pemrosesan yang presisi.
• Hanya membatasi ukuran per file → banyak file yang valid secara individual dapat menghabiskan penyimpanan dan pemindaian → terapkan kuota tenant, pembatasan laju, konkurensi, dan backpressure antrean.
• Merender file sembarang secara inline pada origin utama → interpretasi browser dan konten aktif dapat memengaruhi sesi utama → tetapkan default ke pengunduhan lampiran dan isolasi origin file.

Pertanyaan Lanjutan dan Jawaban

Lanjutan 1: Mengapa harus mem-parse struktur lengkap jika Anda sudah memeriksa magic bytes?

Tanda tangan biasanya hanya mencakup beberapa byte awal. Penyerang dapat menyisipkan format lain setelah header yang valid atau membuat file yang dapat diterima oleh beberapa parser. Parsing struktural penuh memeriksa panjang internal, hubungan, dan penanda akhir. Parser tetap memproses input yang tidak tepercaya, sehingga harus selalu diperbarui, dibatasi sumber dayanya, dan diisolasi.

Lanjutan 2: Apakah unggahan langsung ke penyimpanan objek melewati keamanan backend?

Metode ini hanya mengubah jalur transfer byte. Backend tetap membuat sesi berumur pendek yang terikat pada tenant dan kunci objek, dan kredensial hanya dapat menulis ke karantina. Backend kemudian memverifikasi objek asli, ukuran, versi, dan hash sebelum memindai. Objek tidak memiliki izin baca sebelum AVAILABLE, sehingga unggahan langsung tidak dapat langsung menerbitkannya.

Lanjutan 3: Bagaimana pengalaman pengguna saat terjadi pemadaman pemindai?

Penyelesaian mengembalikan status pemrosesan, sementara status melaporkan bahwa pemeriksaan keamanan sedang berlangsung atau bahwa pemrosesan gagal dan dapat dicoba kembali. Sistem mencoba ulang dengan backoff terbatas dan memantau usia antrean. Setelah melampaui batas ambang, catatan masuk ke FAILED dan tetap tidak tersedia. Pemulihan mencoba ulang versi tidak berubah yang sama melalui jalur terkontrol; ketersediaan tidak pernah melewati tahap keputusan.

Lanjutan 4: Mengapa unduhan masih memerlukan attachment dan nosniff?

Otorisasi menentukan siapa yang menerima byte. Header respons memengaruhi cara browser menginterpretasikannya. attachment mengarahkan browser untuk mengunduh, dan nosniff mencegah browser mengesampingkan tipe yang dideklarasikan server melalui content sniffing. Origin file yang terisolasi lebih lanjut membatasi akses konten aktif ke cookie dan konteks skrip aplikasi utama.

Lanjutan 5: Kontrol apa yang menjadi perlu jika file ZIP diizinkan?

Periksa setiap path anggota di dalam sandbox terisolasi, tolak path absolut dan .., serta batasi kedalaman nesting, jumlah anggota, ukuran individual, total ukuran setelah diekstrak, rasio kompresi, CPU, dan waktu. Jalankan pemeriksaan tipe dan konten berbahaya kembali untuk setiap anggota yang diekstrak. Skenario ini tidak memiliki persyaratan ZIP, sehingga menolaknya memberikan attack surface yang lebih kecil.

Lanjutan 6: Bagaimana Anda membuktikan bahwa race condition tidak mengotori hasil keputusan?

Catat versi input yang tidak dapat diubah dan SHA-256 dalam job pemindaian. Penerbitan menggunakan pembaruan basis data kondisional yang mengharuskan catatan saat ini tetap SCANNING dengan versi dan hash yang sama persis. Pengujian dapat dilakukan dengan menimpa objek logis selama pemindaian dan mengirimkan hasil usang; penerbitan harus gagal. Log audit menghubungkan versi input, keputusan, dan objek akhir yang disetujui.