06 अक्टू॰ 2025·8 मिनट
स्केल पर सुरक्षित फ़ाइल अपलोड: साइन किए गए URL और सत्यापन
साइन किए गए URL, सख्त प्रकार और आकार जाँच, असिंक्रोनस मालवेयर स्कैनिंग, और तेज़ परफॉर्मेंस के साथ स्केल पर सुरक्षित फ़ाइल अपलोड।
साइन किए गए URL, सख्त प्रकार और आकार जाँच, असिंक्रोनस मालवेयर स्कैनिंग, और तेज़ परफॉर्मेंस के साथ स्केल पर सुरक्षित फ़ाइल अपलोड।
फ़ाइल अपलोड सरल दिखते हैं जब तक कि असली उपयोगकर्ता नहीं आते। एक व्यक्ति एक प्रोफ़ाइल फोटो अपलोड करता है। फिर दस हज़ार लोग एक ही समय में PDF, वीडियो और स्प्रेडशीट अपलोड करते हैं। अचानक ऐप धीमा लगने लगता है, स्टोरेज लागत बढ़ जाती है, और सपोर्ट टिकट बढ़ने लगते हैं।
सामान्य विफलताएँ अनुमानित होती हैं। अपलोड पेज हैंग या टाइमआउट हो जाते हैं जब आपका सर्वर पूरी फ़ाइल को हैंडल करने की कोशिश करता है बजाय इसके कि ऑब्जेक्ट स्टोरेज भारी काम करे। अनुमतियाँ बदल जाती हैं, जिससे कोई फ़ाइल URL अनुमान लगा कर ऐसी फ़ाइल देख लेता है जो उसे नहीं देखनी चाहिए। "बेहतर" दिखने वाली फ़ाइलों में मालवेयर होता है, या जटिल फ़ॉर्मैट होते हैं जो डाउनस्ट्रीम टूल्स क्रैश कर देते हैं। और लॉग अधूरे होते हैं, इसलिए आप बुनियादी सवालों का जवाब नहीं दे पाते जैसे किसने क्या और कब अपलोड किया।
आपको जिसकी ज़रूरत है वह नीरस पर भरोसेमंद है: तेज़ अपलोड, स्पष्ट नियम (अनुमत प्रकार और आकार), और एक ऑडिट ट्रेल जो घटनाओं की जांच आसान बनाए।
सबसे कठिन ट्रेडऑफ़ गति बनाम सुरक्षा है। अगर आप हर चेक चलाएँगे इससे पहले कि उपयोगकर्ता समाप्त करे, तो वे प्रतीक्षा करेंगे और रीट्राई करेंगे, जो लोड बढ़ाता है। अगर आप बहुत देर तक चेक पोस्टपोन करते हैं, तो असुरक्षित या अनधिकृत फ़ाइलें फैल सकती हैं। एक व्यावहारिक तरीका है अपलोड को चेक से अलग रखना, और हर चरण को तेज़ और मापने योग्य रखना।
"स्केल" के बारे में भी विशिष्ट रहें। अपने नंबर लिखें: प्रतिदिन फ़ाइलें, पीक अपलोड प्रति मिनट, अधिकतम फ़ाइल आकार, और उपयोगकर्ताओं के स्थान। क्षेत्र (regions) लेटेंसी और गोपनीयता नियमों के लिए मायने रखते हैं।
यदि आप Koder.ai जैसे प्लेटफ़ॉर्म पर ऐप बना रहे हैं, तो इन सीमाओं को जल्दी तय करना मदद करता है, क्योंकि ये तय करते हैं कि आप प्राधिकरण, स्टोरेज और बैकग्राउंड स्कैनिंग वर्कफ़्लो कैसे डिजाइन करेंगे।
उपकरण चुनने से पहले यह साफ़ करें कि क्या गलत हो सकता है। एक थ्रेट मॉडल बड़ा दस्तावेज़ नहीं होना चाहिए—यह छोटा, साझा समझ होना चाहिए कि आपको क्या रोकना है, क्या बाद में पता लगाया जा सकता है, और आप कौन से ट्रेडऑफ़ स्वीकार करेंगे।
हमलावर आम तौर पर कुछ अनुमानित बिंदुओं पर घुसपैठ करने की कोशिश करते हैं: क्लाइंट (मेटाडेटा बदलना या MIME टाइप फ़ेक करना), नेटवर्क एज (रीप्ले और रेट-लिमिट दुरुपयोग), स्टोरेज (ऑब्जेक्ट नाम अनुमान लगाना, ओवरराइट), और डाउनलोड/प्रीव्यू (खतरनाक रेंडरिंग ट्रिगर करना या साझा एक्सेस से फ़ाइल चुराना)।
इसके बाद, खतरों को सरल नियंत्रणों से मैप करें:
अत्यधिक बड़े फ़ाइलें सबसे आसान दुरुपयोग हैं। वे लागत बढ़ा सकती हैं और असली उपयोगकर्ताओं को धीमा कर सकती हैं। उन्हें सख्त बाइट लिमिट और तेज़ अस्वीकृति से जल्दी रोकें।
नकली फ़ाइल प्रकार अगला हैं। invoice.pdf नाम की फ़ाइल कुछ और हो सकती है। एक्सटेंशन या UI चेक पर भरोसा न करें। अपलोड के बाद वास्तविक बाइट्स के आधार पर सत्यापित करें।
मालवेयर अलग है। आम तौर पर आप सब कुछ अपलोड पूरा होने से पहले स्कैन नहीं कर सकते बिना अनुभव को दर्दनाक बनाए। सामान्य पैटर्न है असिंक्रोनस तरीके से पता लगाना, संदिग्ध आइटम को क्वारंटाइन करना, और स्कैन पास होने तक एक्सेस ब्लॉक करना।
अनधिकृत एक्सेस अक्सर सबसे नुकसानदेह होता है। हर अपलोड और हर डाउनलोड को प्राधिकरण निर्णय मानें। एक उपयोगकर्ता को केवल उस स्थान में अपलोड करने दें जो वे मालिक हों (या जिसमें उन्हें लिखने की अनुमति हो), और केवल वही फ़ाइलें डाउनलोड करने दें जिन्हें वे देखने के लिए अधिकृत हों।
कई ऐप के लिए, एक ठोस v1 नीति यह है:
सबसे तेज़ तरीका यह है कि अपने ऐप सर्वर को "बाइट्स के बिजनेस" से बाहर रखें। हर फ़ाइल को अपने बैकएंड के माध्यम से भेजने के बजाय, क्लाइंट को ऑब्जेक्ट स्टोरेज पर सीधे शॉर्ट-लाइव्ड साइन किए गए URL का उपयोग करके अपलोड करने दें। आपका बैकएंड निर्णय और रिकॉर्ड्स पर केंद्रित रहे, गीगाबाइट्स भेजने पर नहीं।
यह विभाजन सरल है: बैकएंड जवाब देता है "कौन क्या और कहाँ अपलोड कर सकता है," जबकि स्टोरेज फ़ाइल डेटा प्राप्त करता है। इससे आम बॉटलनेक हटता है: ऐप सर्वर जो डबल काम करते हैं (Auth और फ़ाइल प्रॉक्सी) और लोड के तहत CPU, मेमोरी, या नेटवर्क खत्म हो जाते हैं।
अपलोड के लिए अपने डेटाबेस (उदा. PostgreSQL) में एक छोटा रिकॉर्ड रखें ताकि हर फ़ाइल का स्पष्ट मालिक और जीवन चक्र हो। यह रिकॉर्ड अपलोड शुरू होने से पहले बनायें, फिर घटनाओं के अनुसार इसे अपडेट करें।
जो फ़ील्ड आमतौर पर उपयोगी होते हैं वे हैं: मालिक और टेनेंट/वर्कस्पेस पहचान, स्टोरेज ऑब्जेक्ट की कुंजी, स्थिति, दावा किया गया आकार और MIME प्रकार, और एक चेकसम जिसे आप सत्यापित कर सकें।
अपलोड को एक स्टेट मशीन की तरह व्यवहार करें ताकि जब retries हों तब भी प्राधिकरण चेक सही रहें।
एक व्यावहारिक अवस्थाओं का सेट है:
बैकएंड requested रिकॉर्ड बनाने के बाद ही क्लाइंट को साइन किए गए URL का उपयोग करने की अनुमति दें। स्टोरेज अपलोड की पुष्टि करने पर इसे uploaded में बदलें, बैकग्राउंड में मालवेयर स्कैनिंग शुरू करें, और केवल तब फ़ाइल एक्सपोज़ करें जब वह approved हो।
जब उपयोगकर्ता Upload क्लिक करता है तो शुरू करें। आपकी ऐप बैकएंड को फ़ाइल नाम, फ़ाइल आकार, और इरादे (avatar, invoice, attachment) जैसी बुनियादी जानकारी के साथ अपलोड स्टार्ट करने को कहती है। बैकएंड उस विशिष्ट लक्ष्य के लिए प्राधिकरण जाँचता है, एक अपलोड रिकॉर्ड बनाता है, और एक शॉर्ट-लाइव्ड साइन किए गए URL लौटाता है।
साइन किए गए URL को संकीर्ण रूप से स्कोप किया जाना चाहिए। आदर्श रूप से यह केवल एक सटीक ऑब्जेक्ट की कुंजी पर एक ही अपलोड की अनुमति देता है, छोटा एक्सपायरी समय और स्पष्ट शर्तें (आकार सीमा, अनुमत कंटेंट प्रकार, वैकल्पिक चेकसम) के साथ।
ब्राउज़र उस URL का उपयोग करके सीधे स्टोरेज में अपलोड करता है। समाप्त होने पर ब्राउज़र फिर बैकएंड को फाइनलाइज़ करने के लिए कॉल करता है। फाइनलाइज़ पर, फिर से प्राधिकरण जाँचें (उपयोगकर्ताओं की पहुँच हट सकती है), और सत्यापित करें कि स्टोरेज में वास्तव में क्या आया: आकार, पता चला कंटेंट प्रकार, और यदि आप उपयोग करते हैं तो चेकसम। फाइनलाइज़ को idempotent बनायें ताकि retries डुप्लिकेट न बनायें।
फिर रिकॉर्ड को uploaded मार्क करें और बैकग्राउंड (queue/job) में स्कैनिंग ट्रिगर करें। UI स्कैन के दौरान "Processing" दिखा सकता है।
एक्सटेंशन पर भरोसा करने से invoice.pdf.exe जैसी फ़ाइलें आपके बकेट में पहुंच जाती हैं। सत्यापन को दोहराने योग्य चेक के रूप में लें जो एक से अधिक जगहों पर होता है।
आकार सीमाओं के साथ शुरू करें। अधिकतम आकार को साइन किए गए URL नीति (या प्रीसाइन्ड POST कंडीशन्स) में रखें ताकि स्टोरेज बड़े अपलोड को जल्दी अस्वीकार कर सके। उसी सीमा को बैकएंड में मेटाडेटा रिकॉर्ड करते समय फिर लागू करें, क्योंकि क्लाइंट अभी भी UI को बायपास करने की कोशिश कर सकता है।
टाइप चेक्स को फ़ाइल की सामग्री के आधार पर करें, न कि फ़ाइल नाम पर। फ़ाइल के पहले बाइट्स (magic bytes) की जाँच करें ताकि यह पुष्टि हो सके कि यह आपकी अपेक्षा के अनुरूप है। एक असली PDF %PDF से शुरू होता है, और PNG फाइलें एक निश्चित सिग्नेचर से शुरू होती हैं। अगर कंटेंट आपके allowlist से मेल नहीं खाता, तो इसे अस्वीकार करें भले ही एक्सटेंशन सही दिख रहा हो।
हर फीचर के लिए allowlists को विशिष्ट रखें। एक अवतार अपलोड केवल JPEG और PNG की अनुमति दे सकता है। एक दस्तावेज़ फ़ीचर PDF और DOCX की अनुमति दे सकता है। इससे जोखिम कम होता है और नियम समझाने में आसान होते हैं।
मूल फ़ाइलनाम को स्टोरेज की कुंजी के रूप में कभी भरोसा न करें। डिस्प्ले के लिए इसे सामान्यीकृत करें (अजीब वर्ण हटाएँ, लंबाई सीमित करें), लेकिन अपनी सुरक्षित ऑब्जेक्ट कुंजी स्टोर करें, जैसे कि UUID प्लस एक एक्सटेंशन जो आप प्रकार की पहचान के बाद असाइन करते हैं।
अपने डेटाबेस में एक चेकसम (जैसे SHA-256) रखें और बाद में प्रोसेसिंग या स्कैनिंग के दौरान इसकी तुलना करें। यह करप्शन, आंशिक अपलोड, या टेम्परिंग पकड़ने में मदद करता है, खासकर जब अपलोड्स लोड के तहत रीट्राई हों।
मालवेयर स्कैनिंग महत्वपूर्ण है, लेकिन यह क्रिटिकल पाथ में नहीं होना चाहिए। अपलोड को जल्दी स्वीकार करें, फिर फ़ाइल को ब्लॉक मानें जब तक यह स्कैन पास न हो।
pending_scan जैसे स्टेट के साथ एक अपलोड रिकॉर्ड बनाएं। UI फ़ाइल दिखा सकता है, लेकिन इसे उपयोगी नहीं होना चाहिए।
स्कैन आम तौर पर तब ट्रिगर होता है जब ऑब्जेक्ट बनता है और स्टोरेज ईवेंट जारी होता है, या अपलोड पूर्णता के बाद एक नौकरी को क्यू में प्रकाशित करके, या दोनों (बैकअप के रूप में) किया जाता है।
स्कैन वर्कर ऑब्जेक्ट को डाउनलोड या स्ट्रीम करता है, स्कैनर चलाता है, और फिर परिणाम अपने डेटाबेस में लिखता है। आवश्यक चीज़ें रखें: स्कैन स्थिति, स्कैनर संस्करण, टाइमस्टैम्प, और किसने अपलोड अनुरोध किया। यह ऑडिट ट्रेल सपोर्ट के लिए मददगार होता है जब कोई पूछता है, "मेरी फ़ाइल ब्लॉक क्यों हुई?"।
असफल फ़ाइलों को साफ़ फ़ाइलों के साथ मिश्रित न छोड़ें। एक नीति चुनें और उसे सुसंगत रूप से लागू करें: क्वारंटाइन करें और एक्सेस हटाएँ, या अगर जांच के लिए ज़रूरत न हो तो हटाएँ।
जो भी आप चुनें, उपयोगकर्ता संदेश शांत और विशिष्ट रखें। उन्हें बताएं क्या हुआ और अगला कदम क्या है (फिर से अपलोड करें, सपोर्ट से संपर्क करें)। यदि बहुत सारी विफलताएँ अचानक हो रही हैं तो अपनी टीम को अलर्ट करें।
सबसे महत्वपूर्ण, डाउनलोड और प्रीव्यू के लिए एक सख्त नियम रखें: केवल approved चिन्हित फ़ाइलों को सर्व किया जाना चाहिए। बाकी सब पर सुरक्षित प्रतिक्रिया लौटाएँ जैसे "फ़ाइल अभी जांच के दौर में है।"
तेज़ अपलोड अच्छे हैं, लेकिन अगर गलत व्यक्ति फ़ाइल को गलत वर्कस्पेस से अटैच कर दे तो यह धीमे होने से बड़ी समस्या है। सबसे सरल नियम सबसे मजबूत भी है: हर फ़ाइल रिकॉर्ड बिल्कुल एक ही टेनेंट (वर्कस्पेस/ऑर्ग/प्रोजेक्ट) से संबंधित होना चाहिए और उसका स्पष्ट मालिक या क्रिएटर होना चाहिए।
दो बार प्राधिकरण चेक करें: जब आप साइन किए गए अपलोड URL जारी करते हैं, और फिर जब कोई फ़ाइल डाउनलोड या देखना चाहे। पहला चेक अनधिकृत अपलोड रोकता है। दूसरा चेक आपको सुरक्षित रखता है अगर एक्सेस रद्द हो गई हो, URL लीक हो गया हो, या उपयोगकर्ता की भूमिका अपलोड के बाद बदल गई हो।
लीस्ट प्रिविलेज सुरक्षा और प्रदर्शन दोनों को पूर्वानुमानित बनाये रखता है। "files" जैसी एक व्यापक अनुमति के बजाय अलग रोल बनाएं जैसे "can upload", "can view", और "can manage (delete/share)"। कई अनुरोध तब तेज़ लुकअप (user, tenant, action) बन जाते हैं बजाय महंगे कस्टम लॉजिक के।
ID अनुमानों को रोकरने के लिए, URL और API में क्रमिक फ़ाइल IDs से बचें। अपारदर्शी पहचानकर्ताओं का उपयोग करें और स्टोरेज कुंजियों को अनुमान-रहित रखें। साइन किए गए URL ट्रांसपोर्ट हैं, आपका प्राधिकरण सिस्टम नहीं।
शेयर की गई फ़ाइलें अक्सर धीमी और गंदगी पैदा करती हैं। शेयरिंग को स्पष्ट डेटा मानें, न कि अप्रत्यक्ष एक्सेस। एक सरल तरीका है एक अलग शेयरिंग रिकॉर्ड जो एक उपयोगकर्ता या समूह को एक फ़ाइल के लिए अनुमति देता है, वैकल्पिक रूप से समाप्ति के साथ।
जब लोग सुरक्षित अपलोड के स्केल की बात करते हैं, वे अक्सर सुरक्षा चेक पर ध्यान केंद्रित करते हैं और बुनियादी बातों को भूल जाते हैं: बाइट्स को मूव करना ही धीमा हिस्सा है। लक्ष्य है बड़े फ़ाइल ट्रैफ़िक को आपके ऐप सर्वरों से दूर रखना, retries को नियंत्रित रखना, और सुरक्षा चेक्स को अनियमित कतार में बदलने से बचना।
बड़े फ़ाइलों के लिए multipart या chunked अपलोड का उपयोग करें ताकि कमजोर कनेक्शन उपयोगकर्ताओं को शुरुआत से दोबारा न शुरू कराये। चंक्स यह भी मदद करते हैं कि आप स्पष्ट सीमाएँ लागू कर सकें: कुल अधिकतम आकार, अधिकतम चंक आकार, और अधिकतम अपलोड समय।
क्लाइंट टाइमआउट्स और रीट्राईज़ को उद्देश्यपूर्ण रखें। कुछ रीट्राई असली उपयोगकर्ताओं को बचा सकते हैं; अनिश्चित रीट्राई लागत बढ़ा सकते हैं, खासकर मोबाइल नेटवर्क पर। छोटे प्रति-चंक टाइमआउट, सीमित रीट्राई कैप, और पूरे अपलोड के लिए एक हार्ड डेडलाइन रखें।
साइन किए गए URL भारी डेटा पाथ को तेज़ रखते हैं, लेकिन उन्हें बनाने वाली रिक्वेस्ट अभी भी हॉट स्पॉट हो सकती है। इसे सुरक्षित रखें ताकि यह प्रतिक्रियाशील रहे:
लेटेंसी का निर्भरता भौगोलिकता पर भी होता है। जब संभव हो तो अपने ऐप, स्टोरेज, और स्कैनिंग वर्कर्स को एक ही रीजन में रखें। यदि आपको अनुपालन के लिए देश-विशिष्ट होस्टिंग की ज़रूरत है, तो रूटिंग की योजना पहले से बनाएं ताकि अपलोड महाद्वीपों के बीच ना उछलें। AWS पर ग्लोबली चलने वाले प्लेटफ़ॉर्म (जैसे Koder.ai) उपयोगकर्ताओं के करीब कार्यभार रख सकते हैं जब डेटा रेज़िडेंसी मायने रखती है।
अंत में, सिर्फ अपलोड ही नहीं बल्कि डाउनलोड की भी योजना बनाएं। फ़ाइलों को साइन किए गए डाउनलोड URL के साथ सर्व करें और फ़ाइल प्रकार व गोपनीयता स्तर के आधार पर कैशिंग नियम सेट करें। सार्वजनिक एसेट्स लंबे समय तक कैश किए जा सकते हैं; निजी रिसीट्स छोटा-लाइव्ड और प्राधिकरण-चेक्ड रहने चाहिए।
कल्पना कीजिए एक छोटे व्यवसाय के ऐप की जहाँ कर्मचारी इनवॉइस और रसीदों की तस्वीरें अपलोड करते हैं, और एक प्रबंधक उन्हें प्रतिपूर्ति के लिए मंज़ूर करता है। यही जगह है जहाँ अपलोड डिज़ाइन शैक्षिक से वास्तविक होता है: आपके पास कई उपयोगकर्ता, बड़े चित्र, और असली धन जुड़ा होता है।
एक अच्छा फ्लो स्पष्ट स्टेटस का उपयोग करता है ताकि हर कोई जान सके क्या हो रहा है और आप स्वयंकार (automate) बोरिंग हिस्सों को कर सकें: फ़ाइल ऑब्जेक्ट स्टोरेज में आती है और आप एक रिकॉर्ड सेव करते हैं जो उपयोगकर्ता/वर्कस्पेस/खर्च से जुड़ा होता है; एक बैकग्राउंड जॉब फ़ाइल स्कैन करता है और बुनियादी मेटाडेटा निकालता है (जैसे असली MIME प्रकार); फिर आइटम या तो मंज़ूर कर दिया जाता है और रिपोर्ट में उपयोगी बनता है, या अस्वीकार कर दिया जाता है और ब्लॉक हो जाता है।
उपयोगकर्ताओं को तेज़, विशिष्ट फीडबैक चाहिए। अगर फ़ाइल बहुत बड़ी है, तो सीमा और वर्तमान आकार दिखाएँ (उदा: "फ़ाइल 18 MB है। अधिकतम 10 MB है.")। अगर प्रकार गलत है, तो बताएं क्या अनुमति है ("PDF, JPG, या PNG अपलोड करें"). अगर स्कैनिंग विफल होती है, तो शांत और कार्रवाई योग्य संदेश रखें ("यह फ़ाइल असुरक्षित हो सकती है। कृपया एक नई कॉपी अपलोड करें.")।
सपोर्ट टीम्स को एक ट्रेल चाहिए जो बिना फ़ाइल खोले डिबग करने में मदद करे: अपलोड ID, उपयोगकर्ता ID, वर्कस्पेस ID, बनाए जाने/अपलोड/स्कैन शुरू/स्कैन पूरा होने के टाइमस्टैम्प, परिणाम कोड (बहुत बड़ा, प्रकार मेल नहीं खाता, स्कैन फेल, प्राधिकरण अस्वीकृत), साथ में स्टोरेज कुंजी और चेकसम।
री-अपलोड और रिप्लेसमेंट आम हैं। उन्हें नए अपलोड के रूप में व्यवहार करें, उन्हें उसी खर्च के साथ नए वर्शन के रूप में संलग्न करें, इतिहास रखें (किसने और कब बदला), और केवल सबसे नए वर्शन को सक्रिय मार्क करें। अगर आप यह ऐप Koder.ai पर बना रहे हैं, तो यह आसानी से एक uploads तालिका और एक expense_attachments तालिका के वर्शन फ़ील्ड के साथ मैप होता है।
अधिकांश अपलोड बग्स कोई जटिल हैक नहीं होते। वे छोटे शॉर्टकट होते हैं जो ट्रैफ़िक बढ़ने पर असली जोखिम बन जाते हैं।
ज्यादा चेक्स होने से अपलोड धीमा नहीं होना चाहिए। तेज़ पाथ और भारी पाथ को अलग करें।
त्वरित चेक्स सिंक्रोनसली करें (auth, आकार, अनुमत प्रकार, रेट लिमिट), फिर स्कैनिंग और डीप इंस्पेक्शन को बैकग्राउंड वर्कर पर हेंड-ऑफ करें। उपयोगकर्ता अपलोड से "uploaded" से "ready" तक जाते हुए काम चलाते रहें। अगर आप चैट-आधारित बिल्डर जैसे Koder.ai के साथ बना रहे हैं, तो यही मानसिकता रखें: अपलोड एंडपॉइंट को छोटा और सख्त रखें, और स्कैनिंग व पोस्ट-प्रोसेसिंग को जॉब्स में धकेलें।
अपलोड भेजने से पहले परिभाषित करें कि v1 के लिए "पर्याप्त सुरक्षित" क्या है। टीमें अक्सर कड़े नियम (जो असली उपयोगकर्ताओं को ब्लॉक करते हैं) और गायब नियम (जो दुरुपयोग आमंत्रित करते हैं) को मिला देती हैं। छोटा शुरू करें, पर सुनिश्चित करें कि हर अपलोड के पास "प्राप्त" से "डाउनलोड के लिए अनुमति" तक एक स्पष्ट मार्ग हो।
एक कसा हुआ प्री-लॉन्च चेकलिस्ट:
यदि आपको न्यूनतम व्यवहार्य नीति चाहिए, तो इसे सरल रखें: आकार सीमा, संकीर्ण प्रकार allowlist, साइन किए गए URL अपलोड, और "स्कैन पास होने तक क्वारंटाइन"। कोर पाथ स्थिर होने के बाद आगे फीचर जोड़ें (प्रीव्यू, अधिक प्रकार, बैकग्राउंड री-प्रोसेसिंग)।
मॉनिटरिंग यह सुनिश्चित करती है कि "तेज़" बड़े होते समय "अनिश्चित रूप से धीमा" न बन जाए। अपलोड विफलता दर (क्लाइंट बनाम सर्वर/स्टोरेज), स्कैन विफलता दर और स्कैन लेटेंसी, फ़ाइल-साइज़ बकेट के अनुसार औसत अपलोड समय, डाउनलोड पर प्राधिकरण अस्वीकृतियाँ, और स्टोरेज egress पैटर्न ट्रैक करें।
रीयल-वर्ल्ड नेटवर्क्स के साथ वास्तविक फ़ाइल आकारों के साथ एक छोटा लोड टेस्ट चलाएँ (मोबाइल डेटा ऑफिस Wi-Fi से अलग तरह से बर्ताव करता है)। लॉन्च से पहले टाइमआउट्स और रीट्राई ठीक करें।
यदि आप इसे Koder.ai (Koder.ai) में लागू कर रहे हैं, तो Planning Mode एक व्यावहारिक जगह है पहले अपने अपलोड स्टेट्स और एंडपॉइंट्स मैप करने के लिए, और फिर उस फ्लो के चारों ओर बैकएंड और UI जनरेट करने के लिए। स्नैपशॉट और रोलबैक भी तब मदद करते हैं जब आप सीमाएँ ट्यून कर रहे हों या स्कैन नियम समायोजित कर रहे हों।
Use direct-to-object-storage uploads with short-lived signed URLs so your app servers don’t stream file bytes. Keep your backend focused on authorization decisions and recording upload state, not moving gigabytes.
Check twice: once when you create the upload and issue a signed URL, and again when you finalize and when you serve a download. Signed URLs are just a transport tool; your app still needs permission checks tied to the file record and its tenant/workspace.
Treat it as a state machine so retries and partial failures don’t create security gaps. A common flow is requested, uploaded, scanned, approved, rejected, and you only allow downloads when the status is approved.
Put a hard byte limit into the signed URL policy (or pre-signed POST conditions) so storage rejects oversized files early. Enforce the same limit again during finalize using storage-reported metadata so clients can’t bypass it.
Don’t trust the filename extension or browser MIME type. Detect type from the file’s actual bytes after upload (for example, magic bytes) and compare it to a tight allowlist for that specific feature.
Don’t block the user on scanning. Accept the upload quickly, quarantine it, run scanning in the background, and only allow download/preview after a clean result is recorded.
Pick a consistent policy: quarantine and remove access, or delete if you don’t need it for investigation. Give the user a calm, specific message and keep audit data so support can explain what happened without opening the file.
Never use the user-provided filename or path as the storage key. Generate an unguessable object key (like a UUID) and store the original name only as display metadata after normalizing it.
Use multipart or chunked uploads so unstable connections don’t restart from zero. Keep retries capped, set timeouts intentionally, and add a hard deadline for the whole upload so one client can’t tie up resources indefinitely.
Use a small upload record with owner, tenant/workspace, object key, status, timestamps, detected type, size, and checksum if you use one. If you build on Koder.ai, this fits well with a Go backend, PostgreSQL tables for uploads, and background jobs for scanning while keeping the UI responsive.