ปุ่มเลือกรูปในหน้าเว็บดูเป็นงานเล็กๆ ผู้ใช้กดเลือกไฟล์ รออัปโหลด แล้วก็เห็นรูปที่ส่งเข้าไป แต่เส้นทางหลังปุ่มนั้นมีงานมากกว่าการย้ายข้อมูลจากเครื่องหนึ่งไปอีกเครื่อง เพราะไฟล์ที่เข้ามายังเป็นข้อมูลจากภายนอก ซึ่งเราไม่รู้ล่วงหน้าว่าตรงกับสิ่งที่ระบบรองรับจริงหรือเปล่า
แม้หน้าจอจะให้เลือกเฉพาะรูป ผู้เรียกก็ไม่จำเป็นต้องส่งผ่านหน้าจอของเราเสมอไป และชื่อที่ลงท้ายด้วย .jpg ก็ไม่ได้รับรองว่าเนื้อหาข้างในเป็นภาพชนิดนั้น การรับไฟล์จึงต้องมีกติกาที่ฝั่งบริการด้วย ไม่ฝากการตัดสินใจไว้กับตัวเลือกใน browser เพียงจุดเดียว
พอแยกคำว่าอัปโหลดสำเร็จออกจากคำว่าพร้อมนำไปใช้งาน เราจะเริ่มเห็นว่าควรตรวจอะไรระหว่างทาง และไฟล์ที่ยังไม่ผ่านขั้นเหล่านั้นควรอยู่ตรงไหนครับ
ถ้าหน้านี้ต้องการเพียงรูปประจำตัว กติกาก็ควรเริ่มจากรูปแบบที่จำเป็นสำหรับงานนั้น แทนการเปิดรับทุกอย่างแล้วค่อยหาว่านามสกุลใดอันตราย การระบุรายการที่ยอมรับช่วยให้กำหนดวิธีอ่านและประมวลผลได้ชัดขึ้น รวมถึงอธิบายให้ผู้ใช้รู้ล่วงหน้าว่าต้องเตรียมไฟล์แบบไหน
ฝั่งหน้าเว็บใช้ accept เพื่อช่วยกรองตัวเลือกในหน้าต่างเลือกไฟล์ได้ แต่ MDN ระบุว่าค่านี้เป็นเพียงคำใบ้ให้ browser ไม่ใช่การตรวจความถูกต้องของไฟล์ ส่วนค่า Content-Type ที่มาพร้อมคำขอก็เป็นข้อมูลที่ผู้ส่งกำหนดได้ จึงควรใช้เป็นข้อมูลประกอบมากกว่าหลักฐานยืนยันชนิดเพียงอย่างเดียว
การตรวจส่วนหัวของไฟล์ช่วยดูว่าคล้ายรูปแบบที่คาดไว้หรือไม่ แต่การพบลายเซ็นที่ถูกต้องก็ยังไม่ยืนยันว่าเนื้อหาทั้งไฟล์อ่านได้หรือปลอดภัย ขั้นถัดไปจึงขึ้นอยู่กับประเภทงาน เช่น ใช้ตัวอ่านภาพที่ดูแลอัปเดตแล้วทดลองถอดรหัสภายในขอบเขตทรัพยากรที่กำหนด และปฏิเสธข้อมูลที่อ่านไม่ครบตามรูปแบบที่รองรับ
กรณีที่ตรวจไม่ผ่าน ควรคืนเหตุผลที่ผู้ใช้แก้ไขได้ เช่น ชนิดไม่รองรับหรือขนาดเกินที่กำหนด โดยไม่ส่งรายละเอียดภายในของตัวอ่านไฟล์ออกไปทั้งหมด วิธีนี้ช่วยให้คนใช้เตรียมไฟล์ใหม่ได้ และไม่ทำให้ข้อความผิดพลาดกลายเป็นช่องเปิดเผยเส้นทางจัดเก็บของบริการ
การจำกัดจำนวน byte ระหว่างรับเป็นจุดเริ่มที่จำเป็น แต่ไฟล์เล็กบนดิสก์อาจขยายเป็นข้อมูลขนาดใหญ่เมื่ออ่านเข้าหน่วยความจำได้ สำหรับภาพจึงต้องคิดต่อถึงความกว้าง ความสูง และจำนวนพิกเซลที่ตัวประมวลผลจะต้องจัดการ ไม่ปล่อยให้ตัวอ่านทำงานจนหมดแล้วค่อยตรวจขนาดผลลัพธ์
ถ้ารองรับไฟล์บีบอัดหรือเอกสารซับซ้อน ขอบเขตก็ต้องครอบคลุมจำนวนรายการข้างใน การขยายข้อมูล และเวลาประมวลผลตามลักษณะนั้นด้วย แต่หากงานไม่ได้ต้องการไฟล์กลุ่มนี้ การไม่เปิดรับตั้งแต่ต้นก็ช่วยลดขั้นตอนที่ต้องดูแลโดยไม่มีประโยชน์ต่อคนใช้
นอกจากขนาดต่อไฟล์ ยังมีจำนวนไฟล์ต่อคำขอ จำนวนงานพร้อมกัน และพื้นที่รวมต่อเจ้าของงาน เมื่อระบบต้องส่งต่อไฟล์ไปสแกนหรือแปลงรูป ขั้นตอนปลายทางก็ควรมีคิวและเวลาทำงานที่จำกัด ไม่ให้การรับไฟล์หนึ่งจุดกลายเป็นทางเริ่มงานไม่สิ้นสุดในอีกจุดหนึ่ง
พื้นที่รับไฟล์ที่ยังไม่ผ่านการตรวจควรแยกจากชุดที่พร้อมนำไปแสดง การแยกนี้ทำให้สถานะของข้อมูลชัดขึ้น เช่น อยู่ระหว่างตรวจ ผ่านการแปลงแล้ว หรือถูกปฏิเสธ และช่วยป้องกันไม่ให้หน้าเว็บนำ URL ของไฟล์ดิบไปใช้ก่อนรู้ผล
งานบางชนิดอาจเพิ่มการสแกนหรือสร้างไฟล์ใหม่จากเนื้อหาที่อ่านได้ เช่น แปลงภาพไปเป็นรูปแบบที่ใช้แสดงบนเว็บ แต่ต้องเข้าใจขอบเขตของแต่ละขั้นด้วย ผลสแกนที่ไม่พบปัญหาไม่ได้รับรองทุกความเสี่ยง และการแปลงก็ยังอาศัยตัวอ่านไฟล์ที่ต้องจำกัดทรัพยากรและดูแลอัปเดตอยู่
หากต้องลบข้อมูลประกอบของภาพ ควรกำหนดจากความต้องการจริง เช่น ภาพที่ใช้แสดงสาธารณะอาจไม่ต้องมีตำแหน่งถ่ายติดไปด้วย ขณะเดียวกันต้นฉบับที่ต้องเก็บเพื่อกระบวนการอื่นอาจมีสิทธิ์และอายุข้อมูลต่างออกไป จึงควรแยกนโยบายของต้นฉบับกับไฟล์แสดงผลให้ชัด
การเอาชื่อไฟล์จากผู้ใช้มาเป็นเส้นทางจัดเก็บตรงๆ ทำให้ต้องรับมือทั้งอักขระที่ระบบตีความเป็น path การชนชื่อ และการทับข้อมูลเดิม แนวทางหนึ่งคือให้บริการสร้างรหัสจัดเก็บเอง แล้วเก็บชื่อเดิมเป็นข้อมูลสำหรับแสดงหลังผ่านกติกาความยาวและอักขระที่เหมาะสม
ชื่อที่สุ่มขึ้นมายังไม่ใช่ระบบสิทธิ์ หากไฟล์เป็นเอกสารเฉพาะบัญชี จุดดาวน์โหลดก็ต้องตรวจว่าใครมีสิทธิ์อ่านไฟล์นั้น ไม่ถือว่า URL เดายากเท่ากับอนุญาตเฉพาะเจ้าของ ส่วนไฟล์ที่ตั้งใจเปิดสาธารณะก็ควรเป็นชุดที่ผ่านกระบวนการตามนโยบายแล้ว
เวลาส่งกลับให้ browser ต้องกำหนดชนิดและวิธีแสดงให้ตรงกับงานด้วย โดยเฉพาะเนื้อหาที่อาจมีส่วนทำงานได้อย่าง HTML หรือ SVG ไม่ควรถูกปฏิบัติเหมือนภาพนิ่งทุกชนิดโดยไม่มีการพิจารณา การแยกพื้นที่หรือ origin สำหรับเนื้อหาภายนอกอาจเป็นอีกชั้นตามความเสี่ยง แต่ยังต้องใช้ร่วมกับการตรวจไฟล์และสิทธิ์เดิม
หากผู้ใช้อัปโหลดแล้วปิดหน้าก่อนกดบันทึก หรือขั้นแปลงไฟล์ล้มเหลว เราอาจเหลือข้อมูลที่ไม่มีรายการใดอ้างถึง จึงควรมีสถานะและอายุสำหรับไฟล์ชั่วคราว พร้อมกระบวนการเก็บกวาดที่ตรวจการอ้างอิงล่าสุดก่อนลบ ไม่ลบเพียงเพราะเห็นว่าไฟล์เก่า
ก่อนใช้จริงสามารถตรวจด้วยไฟล์ทดลองที่ไม่เป็นอันตราย เช่น ชื่อไม่ตรงชนิด ไฟล์อ่านไม่ครบ รูปเกินขนาดที่อนุญาต และบัญชีที่พยายามอ่านไฟล์ของอีกบัญชี แล้วดูว่าระบบปฏิเสธในขั้นที่คาดไว้พร้อมคืนพื้นที่ได้หรือไม่ บทนี้เป็นแนวทางออกแบบ ยังไม่มีผลสแกนหรือผลทดสอบรับไฟล์ของระบบผู้ใช้มาอ้าง
การรับไฟล์ให้ดูแลง่ายเริ่มจากรู้ว่างานต้องการไฟล์ชนิดใด แล้วกำหนดขอบเขตการรับ การอ่าน และการประมวลผลตามนั้น เมื่อแยกไฟล์ที่ยังไม่เชื่อถือออกจากชุดพร้อมใช้ พร้อมดูแลชื่อ สิทธิ์ และอายุข้อมูล เราจะตามสถานะได้ตลอดเส้นทาง แทนการให้อัปโหลดสำเร็จเป็นจุดตัดสินว่าไฟล์พร้อมเผยแพร่แล้วทันที