24 ਨਵੰ 2025·8 ਮਿੰਟ
ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਅਪਲੋਡ: ਪਰਮੀਸ਼ਨ, ਸੀਮਾਵਾਂ, signed URLs, ਸਕੈਨਿੰਗ
ਵੈੱਬ ਐਪਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਅਪਲੋਡ ਲਈ ਕਠੋਰ ਪਰਮੀਸ਼ਨ, ਸਾਈਜ਼ ਸੀਮਾਵਾਂ, signed URLs ਅਤੇ ਮੂਲ ਮਾਲਵੇਅਰ ਸਕੈਨਿੰਗ ਪੈਟਰਨ ਜਰੂਰੀ ਹਨ ਤਾਂ ਕਿ ਘਟਨਾਵਾਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ।
ਵੈੱਬ ਐਪਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਅਪਲੋਡ ਲਈ ਕਠੋਰ ਪਰਮੀਸ਼ਨ, ਸਾਈਜ਼ ਸੀਮਾਵਾਂ, signed URLs ਅਤੇ ਮੂਲ ਮਾਲਵੇਅਰ ਸਕੈਨਿੰਗ ਪੈਟਰਨ ਜਰੂਰੀ ਹਨ ਤਾਂ ਕਿ ਘਟਨਾਵਾਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ।
ਫਾਈਲ ਅਪਲੋਡ ਸਾਦੇ ਲੱਗਦੇ ਹਨ: ਇੱਕ پروਫਾਈਲ ਫੋਟੋ, ਇੱਕ PDF, ਇੱਕ spreadsheet. ਪਰ ये ਅਕਸਰ ਪਹਿਲੀ ਸੁਰੱਖਿਆ ਘਟਨਾ ਬਣ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਇਹ ਅਣਜਾਣ ਬਕਸਾ ਸਿਸਟਮ ਵਿੱਚ ਭੇਜਣ ਦਿੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਸnu਼ ਸਵੀਕਾਰ ਕਰਕੇ, ਸਟੋਰ ਕਰਕੇ, ਅਤੇ ਹੋਰ ਲੋਕਾਂ ਨੂੰ ਵਾਪਸ ਦਿਖਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਆਪਣੀ ਐਪ ਲਈ ਨਵਾਂ ਹਮਲੇ ਦਾ ਰਸਤਾ ਬਣਾਇਆ।
ਖ਼ਤਰਾ ਸਿਰਫ਼ "ਕਿਸੇ ਨੇ ਵਾਇਰਸ ਅਪਲੋਡ ਕੀਤਾ" ਹੀ ਨਹੀਂ ਹੈ। ਇੱਕ ਮਾੜੀ ਫਾਇਲ ਨਿੱਜੀ ਦਸਤਾਵੇਜ਼ ਲੀਕ ਕਰ ਸਕਦੀ ਹੈ, ਸਟੋਰੇਜ ਬਿੱਲ ਫੁਟਾ ਸਕਦੀ ਹੈ, ਜਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਧੋਖਾ ਦੇ ਕੇ ਐਕਸੈਸ ਹਾਸਿਲ ਕਰਵਾ ਸਕਦੀ ਹੈ। "invoice.pdf" ਨਾਂ ਦੀ ਫਾਇਲ ਹਮੇਸ਼ਾ PDF ਨਹੀਂ ਹੋ ਸਕਦੀ। ਅਸਲੀ PDFs ਅਤੇ ਇਮেজ ਵੀ ਮੁਸ਼ਕਿਲ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ ਜੇ ਐਪ ਮੈਟਾ ਡੇਟਾ 'ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ, ਸਮੱਗਰੀ ਦਾ ਪ੍ਰੀਵਿਊ ਆਟੋਮੈਟਿਕਲ ਬਣਾਉਂਦਾ ਹੈ, ਜਾਂ ਗਲਤ ਨਿਯਮਾਂ ਨਾਲ ਸਰਵ ਕਰਦਾ ਹੈ।
ਅਸਲ ਨੁਕਸਾਨ ਆਮ ਤੌਰ 'ਤੇ ਇੰਝ ਹੁੰਦਾ ਹੈ:
ਇੱਕ ਗੱਲ ਕਈ ਘਟਨਾਵਾਂ ਦੀ ਜੜ ਹੈ: ਫਾਇਲਾਂ ਸਟੋਰ ਕਰਨਾ ਅਤੇ ਫਾਇਲਾਂ ਸਰਵ ਕਰਨਾ ਇੱਕੋ ਗੱਲ ਨਹੀਂ। ਸਟੋਰੇਜ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਬਾਈਟ ਰੱਖਦੇ ਹੋ। ਸਰਵਿੰਗ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਬਾਈਟ ਬਰਾਉਜ਼ਰਾਂ ਅਤੇ ਐਪਸ 'ਤੇ ਪਹੁੰਚਦੇ ਹਨ। ਗਲਤ ਵਕਤ ਤੇ ਜੇ ਐਪ ਯੂਜ਼ਰ ਅਪਲੋਡ ਨੂੰ ਆਪਣੀ ਮੁੱਖ ਵੈੱਬਸਾਈਟ ਵਰਗਾ ਹੀ ਭਰੋਸਾ ਦੇ ਕੇ ਸਰਵ ਕਰੇ, ਤਾਂ ਬਰਾਉਜ਼ਰ ਉਸਨੂੰ "ਭਰੋਸੇਯੋਗ" ਸਮਝ ਸਕਦਾ ਹੈ।
ਛੋਟੀ ਜਾਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਰਹੀ ਐਪ ਲਈ "ਪਰਯਾਪਤ ਸੁਰੱਖਿਆ" ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਚਾਰ ਸਵਾਲ ਬਿਨਾਂ ਕਿਸੇ ਫੁਟਕਲਦੇ ਜਵਾਬ ਦੇ ਸਕੋ: ਕੌਣ ਅਪਲੋਡ ਕਰ ਸਕਦਾ, ਤੁਸੀਂ ਕੀ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ, ਕਿੰਨੀ ਵੱਡੀ ਅਤੇ ਕਿੰਨੀ ਵਾਰ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕੌਣ ਪੜ੍ਹ ਸਕਦਾ। ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਿਲਡ ਕਰ ਰਹੇ ਹੋ (ਜਨਰੇਟ ਕੀਤੇ ਕੋਡ ਜਾਂ ਚੈਟ-ਡ੍ਰਾਈਵਨ ਪਲੇਟਫਾਰਮ ਨਾਲ), ਤੋ ਵੀ ਇਹ ਗਾਰਡਰੇਲ ਮਹੱਤਵਪੂਰਨ ਹਨ।
ਹਰ ਅਪਲੋਡ ਨੂੰ ਅਣ-ਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਵਾਂਗ ਸੰਭਾਲੋ। ਅਪਲੋਡਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਦਾ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਇਹ ਸੋਚਣਾ ਹੈ ਕਿ ਕੌਣ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਰਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਲਈ "ਸਫਲਤਾ" ਕੀ ਹੈ।
ਅਧਿਕਤਰ ਹਮਲਾਕਾਰ ਜਾਂ ਤਾਂ ਬੌਟ ਹੁੰਦੇ ਹਨ ਜੋ ਕਮਜ਼ੋਰ ਅਪਲੋਡ ਫਾਰਮਾਂ ਨੂੰ ਸਕੈਨ ਕਰਦੇ ਹਨ ਜਾਂ ਅਸਲ ਯੂਜ਼ਰ ਜਿਹੜੇ ਸੀਮਾਵਾਂ ਤੋ ਪਰੇ ਬਾਹਰ ਜਾ ਕੇ ਫ੍ਰੀ ਸਟੋਰੇਜ ਲੈਣਾ, ਡਾਟਾ ਖੋਜਣਾ ਜਾਂ ਟਰੋਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ। ਕਦੇ-ਕਦੇ ਮੁਕਾਬਲੇ ਵਾਲਾ ਵੀ ਲੀਕ ਜਾਂ ਆਉਟੇਜ ਦੇ ਲਈ ਪਰੋਬ ਕਰਦਾ ਹੈ।
ਉਹ ਕੀ ਚਾਹੁੰਦੇ ਹਨ? ਅਕਸਰ ਇਹਨਾਂ ਨਤੀਜਿਆਂ ਵਿੱਚੋਂ ਕੋਈ ਇਕ:
ਫੇਰ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ। ਅਪਲੋਡ ਐਂਡਪੌਇੰਟ ਫਰণ্ট ਡੋਰ ਹੈ (ਵੱਡੀਆਂ ਫਾਇਲਾਂ, ajeeb ਫਾਰਮੇਟ, ਉੱਚ ਰਿਕਵੇਸਟ ਰੇਟ). ਸਟੋਰੇਜ ਪਿਛਲੇ ਕਮਰਾ ਹੈ (ਪਬਲਿਕ ਬਕੈਟ, ਗਲਤ ਪਰਮੀਸ਼ਨ, ਸਾਂਝੇ ਫੋਲਡਰ). ਡਾਊਨਲੋਡ URLs ਨਿਕਾਸ ਰਾਹ ਹਨ (ਪੇਸ਼ਗੀ, ਲੰਬੀ ਮਿਆਦ ਵਾਲੇ, ਜਾਂ ਕਿਸੇ ਯੂਜ਼ਰ ਨਾਲ ਨਾ ਬੰਨ੍ਹੇ ਹੋਏ).
ਉਦਾਹਰਨ: "resume upload" ਫੀਚਰ. ਇੱਕ ਬੌਟ ਹਜ਼ਾਰਾਂ ਵੱਡੇ PDFs ਅਪਲੋਡ ਕਰਕੇ ਲਾਗਤ ਚੜ੍ਹਾ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਇੱਕ ਦੁਰਵਰਤੋ ਕਰਨ ਵਾਲਾ ਵਰਤੋਂਕਾਰ ਇੱਕ HTML ਫਾਇਲ ਅਪਲੋਡ ਕਰਕੇ ਹੋਰਾਂ ਨੂੰ ਧੋਖਾ ਦੇ ਸਕਦਾ ਹੈ।
ਕੰਟਰੋਲ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਐਪ ਲਈ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਕੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ: ਪ੍ਰਾਈਵੇਸੀ (ਕੌਣ ਪੜ੍ਹ ਸਕਦਾ), ਉਪਲਬਧਤਾ (ਕੀ ਤੁਸੀਂ ਸਰਵ ਕਰਨਾ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹੋ), ਲਾਗਤ (ਸਟੋਰੇਜ ਅਤੇ ਬੈਂਡਵਿਥ), ਅਤੇ ਅਨੁਕੂਲਤਾ (ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਹੈ ਅਤੇ ਕਿੰਨੀ ਦੇਰ ਰੱਖਿਆ ਜਾਂਦਾ)। ਉਹ ਪ੍ਰਾਥਮਿਕਤਾ ਸੂਚੀ ਫੈਸਲਿਆਂ ਨੂੰ ਇੱਕਸਾਰ ਰੱਖਦੀ ਹੈ।
ਜਿਆਦਾਤਰ ਅਪਲੋਡ ਘਟਨਾਵਾਂ ਨਾਜ਼ੁਕ ਹੈਕਸ ਨਹੀਂ। ਇਹ ਸੰਭਵਤ: "ਮੈਂ ਹੋਰ ਯੂਜ਼ਰ ਦੀ ਫਾਇਲ ਦੇਖ ਸਕਦਾ ਹਾਂ" ਵਰਗੀਆਂ ਸਧਾਰਨ ਬਗਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਪਰਮੀਸ਼ਨ ਨੂੰ ਅਪਲੋਡਸ ਦਾ ਹਿੱਸਾ ਮੰਨੋ, ਨਾ ਕਿ ਕੋਈ ਬਾਅਦ ਦੀ ਫੀਚਰ।
ਇੱਕ ਨਿਯਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਡਿਫੋਲਟ ਡਿਨਾਈ। ਮੰਨੋ ਹਰ ਅਪਲੋਡ ਕੀਤੀ ਵਸਤੂ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਨਿੱਜੀ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਖੁੱਲ੍ਹ ਕੇ ਐਕਸੈਸ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੇ। "ਪਹਿਲਾਂ ਤੋਂ ਨਿੱਜੀ" ਇਨਵੋਇਸ, ਮੈਡੀਕਲ ਫਾਇਲਾਂ, ਅਕਾਊਂਟ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਯੂਜ਼ਰ ਨਾਲ ਜੁੜੀਆਂ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਲਈ ਮਜ਼ਬੂਤ ਬੇਸਲਾਈਨ ਹੈ। ਫਾਇਲਾਂ ਨੂੰ ਸਿਰਫ਼ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਪਬਲਿਕ ਕਰੋ ਜਦ ਯੂਜ਼ਰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਉਮੀਦ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ ਪਬਲਿਕ ਅਵਤਾਰ), ਅਤੇ ਫਿਰ ਵੀ ਸਮੇਂ-ਸੀਮਿਤ ਪਹੁੰਚ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
ਭੂਮਿਕਾਵਾਂ ਸਧਾਰਨ ਅਤੇ ਵੱਖ-ਵੱਖ ਰੱਖੋ। ਇੱਕ ਆਮ ਵੰਡ ਇਹ ਹੈ:
ਫੋਲਡਰ-ਸਤਹ ਨੀਤੀਆਂ ਜਿਵੇਂ "/user-uploads/ ਵਿੱਚ ਜੋ ਕੁਝ ਵੀ ਹੈ ਠੀਕ ਹੈ" 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ। ਹਰ ਫਾਇਲ ਪੜ੍ਹਨ ਸਮੇਂ ਮਲਕੀਅਤ ਜਾਂ ਟੇਨੈਂਟ ਪਹੁੰਚ ਦੀ ਜਾਂਚ ਕਰੋ। ਇਹ ਉਸ ਵੇਲੇ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਜਦ ਕਿਸੇ ਨੇ ਟੀਮ ਬਦਲੀ ਕੀਤੀ, ਕਿਸੇ ਨੇ ਆਰਗ ਛੱਡਿਆ, ਜਾਂ ਫਾਇਲ ਨੂੰ ਦੂਜੇ ਨਿਯੁਕਤ ਕੀਤਾ ਗਿਆ।
ਸਪੋਰਟ ਲਈ ਚੰਗਾ ਪੈਟਰਨ ਪਿੰਗਲਾ ਅਤੇ ਅਸਥਾਈ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਖਾਸ ਫਾਇਲ ਲਈ ਪਹੁੰਚ ਦਿਓ, ਉਸ ਨੂੰ ਲੌਗ ਕਰੋ, ਅਤੇ ਆਪੋ-ਆਪ ਹੀ ਖ਼ਤਮ ਕਰ ਦਿਓ।
ਜ਼ਿਆਦਾਤਰ ਅਪਲੋਡ ਹਮਲੇ ਸਾਦੇ ਚਾਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਫਾਇਲ ਜੋ ਦੇਖਣ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਲੱਗਦੀ ਹੈ ਕਿਉਂਕਿ ਨਾਮ ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਹੈਡਰ ਨੇ ਠੱਗਿਆ ਹੋਇਆ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ ਕੁਝ ਹੋਰ ਹੈ। ਕਲਾਇੰਟ ਵੱਲੋਂ ਭੇਜੀ ਹਰ ਚੀਜ਼ ਅਣ-ਭਰੋਸੇਯੋਗ ਹੈ।
allowlist ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਵਾਹੀ ਫਾਰਮੇਟ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ (ਊਦਾਹਰਨ: .jpg, .png, .pdf) ਅਤੇ ਹੋਰ ਸਭ ਨੂੰ ਰੱਦ ਕਰੋ। "ਕੋਈ ਵੀ ਇਮੇਜ" ਜਾਂ "ਕੋਈ ਵੀ ਦਸਤਾਵੇਜ਼" ਜਦ ਤਕ ਲੋੜ ਨਾ ਹੋਵੇ ਤਾਂ ਬਚੋ।
filename ਐਕਸਟੇਸ਼ਨ ਜਾਂ Content-Type ਹੈਡਰ ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਦੋਹਾਂ ਫਰਜ਼ੀ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। invoice.pdf ਇੱਕ executable ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ Content-Type: image/png ਝੂਠ ਹੋ ਸਕਦਾ ਹੈ।
ਇੱਕ ਮਜ਼ਬੂਤ ਤਰੀਕਾ ਫਾਇਲ ਦੀਆਂ ਪਹਿਲੀਆਂ bytes ("magic bytes" ਜਾਂ ਫਾਇਲ ਸਿਗਨੇਚਰ) ਚੈੱਕ ਕਰਨਾ ਹੈ। ਕਈ ਆਮ ਫਾਰਮੇਟਾਂ ਦੇ ਮੁੱਖ ਹੈਡਰ ਇੱਕੋ ਜਿਹੇ ਹੁੰਦੇ ਹਨ (PNG, JPEG). ਜੇ ਹੈਡਰ ਮਨਜ਼ੂਰ ਕੀਤੇ ਫਾਰਮੈਟ ਨਾਲ ਮਿਲਦਾ ਨਹੀਂ, ਤਾਂ ਰੱਦ ਕਰੋ।
ਪ੍ਰਾਇਕਟੀਕਲ ਵੈਰੀਫਿਕੇਸ਼ਨ ਸੈਟਅੱਪ:
ਫਾਇਲਾਂ ਨੂੰ ਰੀਨੇਮ ਕਰਨਾ ਜਿੰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਉਸ ਤੋਂ ਵੱਧ ਨਹੀਂ ਲੱਗਦਾ। ਜੇ ਤੁਸੀਂ ਯੂਜ਼ਰ-ਪ੍ਰਦਾਨ ਅਸਲੀ ਨਾਮ ਸਿੱਧਾ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਪਾਥ ਟ੍ਰਿਕਸ, ਅਜੀਬ ਅੱਖਰ, ਅਤੇ ਅਨਜਾਣ ਓਵਰਰਾਈਟ ਦੇ ਜੋਖਮ ਖੜੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਸਟੋਰੇਜ ਲਈ generated ID ਵਰਤੋ ਅਤੇ ਅਸਲੀ filename ਸਿਰਫ਼ ਦਿਖਾਉਣ ਲਈ ਰੱਖੋ।
ਪ੍ਰੋਫਾਈਲ ਫੋਟੋ ਲਈ ਸਿਰਫ JPEG ਅਤੇ PNG ਮੰਨੋ, ਹੈਡਰ ਚੈੱਕ ਕਰੋ, ਅਤੇ ਜੇ ਸਕੋ ਤਾਂ ਮੈਟਾ ਡੇਟਾ ਹਟਾ ਦਿਓ। ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ PDF ਤੱਕ ਸੀਮਿਤ ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਅਤੇ active content ਵਾਲੀਆਂ ਫਾਇਲਾਂ ਰੱਦ ਕਰੋ। ਜੇ ਬਾਅਦ ਵਿੱਚ SVG ਜਾਂ HTML ਦੀ ਲੋੜ ਪਏ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ executable ਮੰਨ ਕੇ ਅਲੱਗ ਰੱਖੋ।
ਅਧਿਕਤਰ ਅਪਲੋਡ ਆਉਟੇਜ ਆਮ ਤੌਰ 'ਤੇ "ਫੈਂਸੀ ਹੈਕ" ਕਾਰਨ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਵੱਡੀਆਂ ਫਾਇਲਾਂ, ਬਹੁਤ ਵਾਰੀ ਦੀਆਂ ਅਪਲੋਡਾਂ, ਜਾਂ ਧੀਮਾ ਕਨੈਕਸ਼ਨ ਹੁੰਦੇ ਹਨ ਜੋ ਸਰਵਰ ਨੂੰ ਬੰਨ੍ਹ ਲੈਂਦੇ ਹਨ। ਹਰ ਬਾਈਟ ਨੂੰ ਖਰਚ ਮੰਨੋ।
ਫੀਚਰ-ਅਨੁਸਾਰ ਇੱਕ ਮੈਕਸ ਸਾਈਜ਼ ਚੁਣੋ, ਨਾ ਕਿ ਇੱਕ ਗਲੋਬਲ ਨੰਬਰ। ਇੱਕ ਅਵਤਾਰ ਨੂੰ ਟੈਕਸ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਛੋਟੀ ਵੀਡੀਓ ਵਰਗਾ ਮਿਆਦ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਸਭ ਤੋਂ ਛੋਟਾ ਲਕੜਾ ਲਗਾਓ ਜੋ ਅਜੇ ਵੀ ਨਾਰਮਲ ਮਹਿਸੂਸ ਹੋਵੇ, ਤੇ ਇਕ ਵੱਖਰਾ "ਵੱਡਾ ਅਪਲੋਡ" ਪਾਥ ਰੱਖੋ ਜੇ ਲੋੜ ਹੋਵੇ (ਜਿਵੇਂ ਕਿ ਸਿੱਧਾ object storage ਨਾਲ signed URL)।
ਲਿਮਿਟਾਂ ਨੂੰ ਕਈ ਥਾਵਾਂ 'ਤੇ ਲਾਗੂ ਕਰੋ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਝੂਠ ਬੋਲ ਸਕਦਾ ਹੈ: ਐਪ ਲਾਜਿਕ, ਵੈਬ ਸਰਵਰ ਜਾਂ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ, ਅਪਲੋਡ ਟਾਈਮਆਊਟ, ਅਤੇ ਜਦ ਘਾਸਿਤ ਸਾਈਜ਼ ਬਹੁਤ ਵੱਡੀ ਹੁੰਦੀ ਹੈ ਤਾਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਰੱਦ ਕਰ ਦਿਓ (ਪੂਰੀ ਬਾਡੀ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ)।
ਠੋਸ ਉਦਾਹਰਣ: ਅਵਤਾਰ 2 MB ਤੇ ਕੈਪ, PDFs 20 MB ਤੇ ਕੈਪ, ਅਤੇ ਇਸ ਤੋਂ ਵੱਡੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਵੱਖਰਾ ਫਲੋ (ਜਿਵੇਂ direct-to-object-storage)।
ਛੋਟੀਆਂ ਫਾਇਲਾਂ ਵੀ ਲੂਪ ਵਿੱਚ ਅਪਲੋਡ ਕੀਤੀਆਂ ਜਾਣ ਤਾਂ DoS ਬਣ ਸਕਦੀਆਂ ਹਨ। ਅਪਲੋਡ ਐਂਡਪੌਇੰਟਸ 'ਤੇ ਯੂਜ਼ਰ ਅਤੇ IP ਅਨੁਸਾਰ ਰੇਟ ਲਿਮਿਟ ਸ਼ਾਮਿਲ ਕਰੋ। Anonymously ਟ੍ਰੈਫਿਕ ਲਈ ਸਖ਼ਤ ਨੀਤੀਆਂ ਵਿਚਾਰ ਕਰੋ।
Resumable uploads ਅਸਲ ਯੂਜ਼ਰਾਂ ਲਈ ਮਦਦਗਾਰ ਹਨ, ਪਰ session token ਨੂੰ ਸਖ਼ਤ ਰੱਖੋ: ਛੋਟੀ ਮਿਆਦ, ਯੂਜ਼ਰ ਨਾਲ ਬੰਨ੍ਹੀ ਹੋਈ, ਅਤੇ ਖਾਸ ਫਾਇਲ ਸਾਈਜ਼/ਡੈਸਟਿਨੇਸ਼ਨ ਨਾਲ ਲਿੰਕ ਕੀਤੀ। ਨਹੀਂ ਤਾਂ "resume" endpoints ਤੁਹਾਡੇ ਸਟੋਰੇਜ ਲਈ ਇੱਕ ਮੁਫ਼ਤ ਪਾਈਪ ਬਣ ਸਕਦੇ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਅਪਲੋਡ ਬਲੌਕ ਕਰੋ, ਤਾਂ ਯੂਜ਼ਰ-ਮੁੱਖ ਤੌਰ 'ਤੇ ਸਾਫ਼ ਗਲਤੀ ਸੁਨੇਹਾ ਦਿਓ (ਫਾਇਲ ਬਹੁਤ ਵੱਡੀ, ਬਹੁਤ ਬੇਨਤੀਆਂ), ਪਰ ਅੰਦਰੂਨੀ ਜਾਣਕਾਰੀ (ਸਟੈਕ ਟ੍ਰੇਸ, ਬਕੈਟ ਨਾਂ, ਵੇਂਡਰ ਵੇਰਵੇ) ਨਾ ਦਿਖਾਓ।
ਸੁਰੱਖਿਅਤ ਅਪਲੋਡਸ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਕੀ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ। ਇਹ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਫਾਇਲ ਕਿੱਥੇ ਜਾਂਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕਿਸ ਤਰੀਕੇ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਵਾਪਸ ਦਿੰਦੇ ਹੋ।
ਅਪਲੋਡ ਬਾਈਟਸ ਨੂੰ ਆਪਣੀ ਮੁੱਖ ਡੈਟਾਬੇਸ ਤੋਂ ਬਾਹਰ ਰੱਖੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਾਂ ਨੂੰ ਸਿਰਫ਼ ਮੈਟਾ ਡੇਟਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਮਾਲਕ ਯੂਜ਼ਰ ID, ਅਸਲ filename, ਪਤਾ ਲੱਗਿਆ ਟਾਈਪ, ਸਾਈਜ਼, checksum, ਸਟੋਰੇਜ ਕੀ, ਬਣਾਉਣ ਸਮਾਂ). ਬਾਈਟਸ ਨੂੰ object storage ਜਾਂ ਫਾਇਲ ਸਰਵਿਸ ਵਿੱਚ ਰੱਖੋ ਜੋ ਵੱਡੇ blob ਲਈ ਬਣਿਆ ਹੋਵੈ।
ਪਬਲਿਕ ਅਤੇ ਨਿੱਜੀ ਫਾਇਲਾਂ ਨੂੰ ਸਟੋਰੇਜ ਪੱਧਰ 'ਤੇ ਵੱਖਰਾ ਰੱਖੋ। ਵੱਖ-ਵੱਖ ਬਕੈਟ ਜਾਂ ਕੰਟੇਨਰ ਵਰਤੋ ਜਿਨ੍ਹਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਨਿਯਮ ਹੋਣ। ਪਬਲਿਕ ਫਾਇਲਾਂ (ਜਿਵੇਂ ਪਬਲਿਕ ਅਵਤਾਰ) ਲੌਗਿਨ ਬਿਨਾਂ ਪੜ੍ਹੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਨਿੱਜੀ ਫਾਇਲਾਂ (ਕਾਨਟਰੈਕਟ, ਇਨਵਾਇਸ, ਮੈਡੀਕਲ ਦਸਤਾਵੇਜ਼) ਨੂੰ ਕਦੇ ਵੀ ਪਬਲਿਕ ਰੀਡੇਬਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ, ਭਾਵੇਂ ਕੋਈ URL ਅਨੁਮਾਨ ਲਗਾ ਲਵੇ।
ਜਦੋਂ ਸੰਭਵ ਹੋ, ਯੂਜ਼ਰ ਫਾਇਲਾਂ ਨੂੰ ਆਪਣੇ ਮੁੱਖ ਡੋਮੇਨ ਤੋਂ ਸਰਵ ਕਰਨ ਤੋਂ ਬਚੋ। ਜੇ ਕੋਈ ਖਤਰਨਾਕ ਫਾਇਲ ਫਿਸ਼ ਹੋ ਜਾਵੇ (HTML, SVG ਨਾਲ ਸਕ੍ਰਿਪਟ, ਜਾਂ ਬਰਾਉਜ਼ਰ MIME sniffing ਅਸਮਾਨਤਾ), ਤਾਂ ਉਸਨੂੰ ਮੁੱਖ ਡੋਮੇਨ 'ਤੇ ਹੋਸਟ ਕਰਨ ਨਾਲ ਖਾਤਾ ਹੜਪਣ ਤੱਕ ਬੜੀ ਨੁਕਸਾਨ ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕ ਵੱਖਰਾ ਡਾਊਨਲੋਡ ਡੋਮੇਨ (ਜਾਂ ਸਟੋਰੇਜ ਡੋਮੇਨ) ਬਲੇਂਕ ਰੇਡੀਅਸ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
ਡਾਊਨਲੋਡ 'ਤੇ ਸੁਰੱਖਿਅਤ ਹੈਡਰ ਲਾਗੂ ਕਰੋ। Content-Type ਨੂੰ ਉਸ ਚੀਜ਼ ਦੇ ਅਧਾਰ 'ਤੇ ਬਧੋ ਜੋ ਤੁਸੀਂ ਮਨਜ਼ੂਰ ਕਰਦੇ ਹੋ, ਨਾ ਕਿ ਜੋ ਯੂਜ਼ਰ ਦਾਅਵਾ ਕਰਦਾ ਹੈ। ਜੇ ਕੁਝ ਬਰਾਉਜ਼ਰ ਲਈ ਵਿਆਖਿਆ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਵਜੋਂ ਭੇਜੋ।
ਕੁਝ ਡਿਫੋਲਟ ਜੋ ਅਚਾਨਕੀਆਂ ਰੋਕਦੇ ਹਨ:
Content-Disposition: attachment ਵਰਤੋ।Content-Type (ਜਾਂ application/octet-stream) ਵਰਤੋ।ਰਿਟੇਨਸ਼ਨ ਵੀ ਸੁਰੱਖਿਆ ਹੈ। ਬੇਕਾਰ ਅਪਲੋਡਾਂ ਨੂੰ ਮਿਟਾਓ, ਬਦਲੇ ਗਏ ਵਰਜਨਾਂ ਨੂੰ ਹਟਾਓ, ਅਤੇ ਅਸਥਾਈ ਫਾਇਲਾਂ ਲਈ ਸਮੇਂ ਸੀਮਾ ਰੱਖੋ। ਘੱਟ ਡੇਟਾ ਸਟੋਰ ਹੋਵੇ ਤਾਂ ਘੱਟ ਲੀਕ ਹੋਣ ਦੀ ਆਸਾਨੀ।
Signed URLs (pre-signed URLs ਵੀ ਕਹਿੰਦੇ ਹਨ) ਇੱਕ ਆਮ ਤਰੀਕ ਹੈ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਟੋਰੇਜ ਬਕੈਟ ਨੂੰ ਪਬਲਿਕ ਕੀਤੇ ਬਿਨਾਂ ਤੇ ਹਰ ਬਾਈਟ ਆਪਣੀ API ਰਾਹੀਂ ਭੇਜੇ ਬਿਨਾਂ ਅਪਲੋਡ ਜਾਂ ਡਾਊਨਲੋਡ ਦੀ ਆਗਿਆ ਦੇਣ ਲਈ। URL ਅਸਤিত্বਕਾਲੀ ਅਧਿਕਾਰ ਲਿਆਉਂਦਾ ਹੈ, ਫਿਰ ਮਿਆਦ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ।
ਦੋ ਆਮ ਫਲੋਸ:
Direct-to-storage API ਲੋਡ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਸਟੋਰੇਜ ਨਿਯਮਾਂ ਅਤੇ URL ਪਾਬੰਦੀਆਂ ਨੂੰ ਹੋਰ ਜ਼ਰੂਰੀ ਬਣਾਉਂਦਾ ਹੈ।
Signed URL ਨੂੰ ਇਕ-ਵਾਰੀ ਦੀ ਚਾਬੀ ਵਾਂਗ ਸੋਚੋ। ਇਸਨੂੰ ਵਿਸ਼ੇਸ਼ ਅਤੇ ਛੋਟੀ ਮਿਆਦ ਦਾ ਰੱਖੋ।
ਇੱਕ ਪ੍ਰਯੋਗਕ ਪੈਟਰਨ ਇਹ ਹੈ: ਪਹਿਲਾਂ ਇਕ upload record ਬਣਾਓ (status: pending), ਫਿਰ signed URL ਜਾਰੀ ਕਰੋ। ਅਪਲੋਡ ਹੋਣ ਦੇ ਬਾਅਦ, ਆਬਜੈਕਟ ਦੀ ਮੌਜੂਦਗੀ ਅਤੇ ਉਮੀਦਿਤ ਸਾਈਜ਼/ਟਾਈਪ ਚੈੱਕ ਕਰੋ ਅਤੇ ਫਿਰ ready ਬਣਾਓ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਅਪਲੋਡ ਫਲੋ ਜ਼ਿਆਦਾਤਰ ਸਾਫ਼ ਨਿਯਮ ਅਤੇ ਸਾਫ਼ ਸਥਿਤੀਆਂ ਹਨ। ਹਰ ਅਪਲੋਡ ਨੂੰ ਜਾਂਚ ਮੁਕੰਮਲ ਹੋਣ ਤੱਕ ਅਣ-ਭਰੋਸੇਯੋਗ ਸਮਝੋ।
ਹਰ ਫੀਚਰ ਲਈ ਲਿਖੋ ਕਿ ਉਹ ਕੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਪ੍ਰੋਫਾਈਲ ਫੋਟੋ ਅਤੇ ਇੱਕ ਟੈਕਸ ਦਸਤਾਵੇਜ਼ ਇੱਕੋ ਜਿਹੇ ਫਾਇਲ ਟਾਈਪ, ਸਾਈਜ਼ ਸੀਮਾਵਾਂ, ਜਾਂ ਵਿਜ਼ੀਬਿਲਟੀ ਨਹੀਂ ਸਾਂਝੇ ਕਰਨੇ ਚਾਹੀਦੇ।
ਮਨਜ਼ੂਰ ਟਾਈਪ ਅਤੇ ਫੀਚਰ-ਅਨੁਸਾਰ ਮੈਕਸ ਸਾਈਜ਼ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਉਦਾਹਰਨ: ਫੋਟੋ 5 MB ਤੱਕ; PDF 20 MB ਤੱਕ). ਬੈਕਐਂਡ ਵਿੱਚ ਇੱਕੋ ਨਿਯਮ ਲਾਗੂ ਕਰੋ।
bytes ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਕ "upload record" ਬਣਾਓ। ਸਟੋਰ ਕਰੋ: owner (user/org), purpose (avatar, invoice, attachment), original filename, expected max size, ਅਤੇ status ਜਿਵੇਂ pending।
ਨਿੱਜੀ ਥਾਂ ਵਿੱਚ ਅਪਲੋਡ ਕਰੋ। ਕਲਾਇੰਟ ਨੂੰ final path ਚੁਣਨ ਦੀ ਆਗਿਆ ਨਾ ਦੇਵੋ।
ਦੁਬਾਰਾ ਸਰਵਰ-ਸਾਈਡ ਵੈਲਿਡੇਸ਼ਨ: size, magic bytes/type, allowlist. ਜੇ ਪਾਸ ਹੋਇਆ ਤਾਂ status uploaded ਕਰੋ।
ਮਾਲਵੇਅਰ ਸਕੈਨ ਕਰੋ ਅਤੇ status clean ਜਾਂ quarantined ਕਰੋ। ਜੇ ਸਕੈਨ ਅਸਿੰਕ੍ਰੋਨਸ ਹੈ, ਤਾਂ ਜਦ ਤੱਕ ਨਤੀਜਾ ਨਾ ਆਵੇ access locked ਰੱਖੋ।
ਫਾਇਲ ਤਦ ਹੀ download/preview ਜਾਂ processing ਲਈ ਅਨੁਮਤ ਹੋਵੇ ਜਦ status clean ਹੋਵੇ।
ਛੋਟਾ ਉਦਾਹਰਨ: ਪ੍ਰੋਫਾਈਲ ਫੋਟੋ ਲਈ, ਯੂਜ਼ਰ ਨਾਲ ਜੁੜਿਆ record ਬਣਾਓ purpose avatar ਨਾਲ, ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕਰੋ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਵਾਸਤਵ ਵਿੱਚ JPEG/PNG ਹੈ (ਸਿਰਫ਼ ਨਾਮ 'ਤੇ ਨਹੀਂ), ਸਕੈਨ ਚਲਾਓ, ਫਿਰ preview URL ਜਨਰੇਟ ਕਰੋ।
ਮਾਲਵੇਅਰ ਸਕੈਨिंग ਇੱਕ ਸੇਫਟੀ ਨੈਟ ਹੈ, ਪਰ ਇਹ ਸਭ ਪਕੜ ਨਹੀਂ ਸਕਦੀ। ਉਦੇਸ਼ ਸਧਾਰਨ ਹੈ: ਜੋ ਪਤਾ ਲੱਗਣਯੋਗ ਹੈ ਉਹ ਚੀਜ਼ਾਂ ਫੜੋ ਅਤੇ ਅਣਪਛਾਤੀਆਂ ਫਾਇਲਾਂ ਨੂੰ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਨਿਰਸਰ ਬਣਾਓ।
ਇੱਕ ਭਰੋਸੇਯੋਗ ਪੈਟਰਨ ਪਹਿਲਾਂ quarantine ਹੈ। ਹਰ ਨਵੇਂ ਅਪਲੋਡ ਨੂੰ ਇੱਕ ਨਿੱਜੀ, non-public ਥਾਂ ਵਿੱਚ ਸੇਵ ਕਰੋ ਅਤੇ ਉਸਨੂੰ pending ਮਾਰਕ ਕਰੋ। ਜਦੋ ਉਹ ਚੇਕਾਂ ਪਾਸ ਕਰ ਲੈਂਦਾ ਹੈ ਤਾਂ ਉਸਨੂੰ "clean" ਥਾਂ 'ਤੇ ਮੂਵ ਕਰੋ ਜਾਂ ਉਪਲਬਧ ਬਣਾਓ।
ਸਿੰਕ੍ਰੋਨਸ ਸਕੈਨ ਛੋਟੀਆਂ ਫਾਇਲਾਂ ਅਤੇ ਘੱਟ ਟ੍ਰੈਫਿਕ ਲਈ ਹੀ ਚੰਗੇ ਹਨ ਕਿਉਂਕਿ ਯੂਜ਼ਰ ਨੂੰ ਉਡੀਕ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਵੱਡੀਆਂ ਐਪਸ ਆਮ ਤੌਰ 'ਤੇ ਅਸਿੰਕ੍ਰੋਨਸ ਸਕੈਨ ਵਰਤਦੀਆਂ ਹਨ: ਅਪਲੋਡ ਸਵੀਕਾਰ ਕਰੋ, "processing" ਸਟੇਟ ਵਾਪਸ ਕਰੋ, ਬੈਕਗ੍ਰਾਉਂਡ ਵਿੱਚ ਸਕੈਨ ਕਰੋ।
ਬੁਨਿਆਦੀ ਸਕੈਨਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਐਂਟੀਵਾਇਰਸ ਇੰਜਣ (ਜਾਂ ਸਰਵਿਸ) ਅਤੇ ਕੁਝ guardrails ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ: AV ਸਕੈਨ, ਫਾਇਲ-ਟਾਈਪ ਚੈੱਕ (magic bytes), ਆਰਕਾਈਵ ਹੱਦਾਂ (zip bombs, nested zips, ਵੱਡਾ uncompressed size), ਅਤੇ ਉਹਨਾਂ ਫਾਰਮੇਟਾਂ ਨੂੰ ਬਲੌਕ ਕਰਨਾ ਜਿਨ੍ਹਾਂ ਦੀ ਲੋੜ ਨਹੀਂ।
ਜੇ ਸਕੈਨ ਫੇਲ ਕਰਦਾ ਹੈ, ਟਾਈਮਆਊਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਨਤੀਜਾ "ਅਣਜਾਣ" ਆਉਂਦਾ ਹੈ, ਤਾਂ ਫਾਇਲ ਨੂੰ ਸੰਦੇਹਾਸਪદ ਮੰਨੋ। ਇਸ ਨੂੰ quarantine ਰੱਖੋ ਅਤੇ ਡਾਊਨਲੋਡ ਲਿੰਕ ਨਾ ਦਿਓ। ਬਹੁਤ ਸਾਰੀ ਟੀਮਾਂ ਇੱਥੇ ਜ਼ਰੂਰ ਪੇਟ ਜਾਂਦੀਆਂ ਹਨ: "scan failed" ਨੂੰ "ਫਿਰ ਵੀ ਜਾਰੀ ਰੱਖੋ" ਨਾ ਬਣਾਓ।
ਜਦੋਂ ਤੁਸੀਂ ਫਾਇਲ ਬਲੌਕ ਕਰੋ, ਯੂਜ਼ਰ ਸੁਨੇਹਾ ਨਿਊਟਰਲ ਰੱਖੋ: “ਅਸੀਂ ਇਹ ਫਾਇਲ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰ ਸਕੇ। ਕਿਸੇ ਹੋਰ ਫਾਇਲ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਜਾਂ ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ ਕਰੋ।” ਜਾਂ ਵਿਸ਼ੇਸ਼ ਰੂਪ ਨਾਲ ਮਾਲਵੇਅਰ ਦਾ ਦਾਅਵਾ ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਪੱਕੇ ਨਹੀਂ ਹੋ।
ਦੋ ਫੀਚਰ ਸੋਚੋ: ਪ੍ਰੋਫਾਈਲ ਫੋਟੋ (ਜੋ ਪਬਲਿਕ ਰੂਪ ਵਿੱਚ ਦਿਖਾਈ ਜਾਂਦੀ) ਅਤੇ PDF ਰਸੀਟ (ਨਿੱਜੀ, ਬਿਲਿੰਗ ਜਾਂ ਸਪੋਰਟ ਲਈ)। ਦੋਹਾਂ ਸਮੱਸਿਆਵਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਦੇ ਨਿਯਮ ਇਕੋ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ।
ਪ੍ਰੋਫਾਈਲ ਫੋਟੋ ਲਈ ਕੜਾ ਰੂਲ ਰੱਖੋ: ਸਿਰਫ JPEG/PNG, ਸਾਈਜ਼ ਕੈਪ (ਉਦਾਹਰਨ 2-5 MB), ਅਤੇ ਸਰਵਰ-ਸਾਈਡ ਰੀ-ਇੰਕੋਡ ਕਰੋ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਦੀ ਅਸਲੀ ਬਾਈਟ ਸਿੱਧੀ ਸਰਵ ਨਾ ਹੋਵੇ। ਚੈੱਕ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਇਹਨੂੰ ਪਬਲਿਕ ਸਟੋਰੇਜ 'ਚ ਰੱਖੋ।
PDF ਰਸੀਟ ਲਈ ਵੱਧ ਸਾਈਜ਼ (ਉਦਾਹਰਨ 20 MB ਤੱਕ) ਦੀ ਆਗਿਆ ਦਿਓ, ਡਿਫੋਲਟ ਤੌਰ 'ਤੇ ਨਿੱਜੀ ਰੱਖੋ, ਅਤੇ ਮੁੱਖ ਐਪ ਡੋਮੇਨ ਤੋਂ inline render ਨਾ ਕਰੋ।
ਇੱਕ ਸਧਾਰਨ ਸਟੇਟ ਮਾਡਲ ਯੂਜ਼ਰ ਨੂੰ ਬਿਨਾਂ ਅੰਦਰੂਨੀ ਵੇਰਵੇ ਦਿਤੇ ਰੂਪ ਜਾਣੂ ਰੱਖਦਾ ਹੈ:
Signed URLs ਇੱਥੇ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਫਿੱਟ ਹੋ ਜਾਂਦੇ ਹਨ: ਉਪਰੋਕਤ ਲਿਖਣ ਲਈ ਇਕ ਛੋਟੀ ਮਿਆਦ ਵਾਲਾ signed URL (write-only, ਇੱਕ object key) ਜਾਰੀ ਕਰੋ। ਪਾਠ ਤਈਂ ਵੱਖਰਾ ਛੋਟੀ ਮਿਆਦ ਵਾਲਾ signed URL ਜਾਰੀ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਜਦ status clean ਹੋ।
ਲੋੜੀਂਦਾ ਲੋਗ ਜਿੰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਉਤਨਾ ਰੱਖੋ: user ID, file ID, type guess, size, storage key, timestamps, scan result, request IDs. ਰਾਅ ਡਾਟਾ ਜਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਅੰਦਰੋਨੀ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਲਾਗ ਨਾ ਕਰੋ।
ਜਿਆਦਾਤਰ ਅਪਲੋਡ ਬੱਗ ਉਸੇ ਕਿਸੇ ਛੋਟੇ "ਅਸਥਾਈ" ਸ਼ਾਰਟਕਟ ਕਾਰਨ ਪੈਂਦੀ ਹੈ ਜੋ ਫਿਰ ਹਮੇਸ਼ਾਂ ਲਈ ਰਹਿ ਜਾਂਦੀ ਹੈ। ਹਰ ਫਾਈਲ ਨੂੰ ਅਣ-ਭਰੋਸੇਯੋਗ ਮੰਨੋ, ਹਰ URL ਸਾਂਝਾ ਹੋ ਸਕਦੀ ਸੋਚੋ, ਅਤੇ "ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਾਂਗੇ" ਵਾਲੇ ਸੁਧਾਰ ਅਕਸਰ ਭੁੱਲ ਜਾਂਦੇ ਹਨ।
ਆਮ ਜਾਲ:
Content-Type ਨਾਲ ਫਾਇਲ ਸਰਵ ਕਰਨਾ, ਜਿਸ ਨਾਲ ਬਰਾਊਜ਼ਰ ਰਿਸਕੀ ਸਮੱਗਰੀ ਨੂੰ ਵੀ ਚਲਾ ਸਕਦਾ ਹੈ।ਮਾਨੀਟਰਿੰਗ ਉਹ ਚੀਜ਼ ਹੈ ਜਿਸ ਨੂੰ ਟੀਮਾਂ ਅਕਸਰ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ ਜਦ ਤੱਕ ਸਟੋਰੇਜ ਬਿੱਲ ਚੜ੍ਹਦਾ ਨਹੀਂ। ਅਪਲੋਡ ਵੋਲਿਊਮ, ਔਸਤ ਸਾਈਜ਼, ਸਿਖਰ ਅਪਲੋਡਰ, ਅਤੇ ਏਰਰ ਰੇਟ ਟ੍ਰੈਕ ਕਰੋ। ਇੱਕ ਕੋਂਪ੍ਰੋਮਾਈਜ਼ਡ ਅਕਾਊਂਟ ਰਾਤੋਂ-ਰਾਤ ਹਜ਼ਾਰਾਂ ਵੱਡੀਆਂ ਫਾਇਲਾਂ ਅਪਲੋਡ ਕਰ ਸਕਦਾ ਹੈ।
ਉਦਾਹਰਨ: ਇੱਕ ਟੀਮ avatars ਨੂੰ ਯੂਜ਼ਰ-ਪ੍ਰਦਾਨ filenames ਜਿਵੇਂ "avatar.png" ਨਾਲ ਸਾਂਝੇ ਫੋਲਡਰ ਵਿੱਚ ਸਟੋਰ ਕਰਦੀ ਹੈ। ਇੱਕ ਯੂਜ਼ਰ ਹੋਰਾਂ ਦੀਆਂ ਇਮেজਾਂ ਓਵਰਰਾਈਟ ਕਰ ਦਿੰਦਾ ਹੈ। ਠੀਕ ਕਰਨ ਲਈ: ਸਰਵਰ-ਸਾਈਡ generated object keys ਬਣਾਓ, ਅਪਲੋਡਸ ਨੂੰ ਡਿਫੋਲਟ ਤੌਰ 'ਤੇ ਨਿੱਜੀ ਰੱਖੋ, ਅਤੇ ਨਿਯੰਤਰਿਤ ਪ੍ਰਤੀਕ੍ਰਿਆ ਰਾਹੀਂ ਰੀਸਾਈਜ਼ਡ ਇਮੇਜ ਪ੍ਰਦਾਨ ਕਰੋ।
ਇਸਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਆਖਰੀ ਪਾਸ ਦੇ ਤੌਰ 'ਤੇ ਵਰਤੋ। ਹਰ ਆਇਟਮ ਨੂੰ ਰਿਲੀਜ਼ ਬਲੌਕਰ ਸਮਝੋ, ਕਿਉਂਕਿ ਜਿਆਦਾਤਰ ਘਟਨਾਵਾਂ ਇੱਕ ਗੁੰਮ ਹੋਏ ਗਾਰਡਰੇਲ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ।
Content-Type, ਸੇਫ filenames, ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ attachment।ਆਪਣੀਆਂ ਨੀਤੀਆਂ ਸਾਫ਼ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ: ਮਨਜ਼ੂਰ ਟਾਈਪਸ, ਮੈਕਸ ਸਾਈਜ਼, ਕੌਣ ਕਿਹੜੀ ਪਹੁੰਚ ਰੱਖੇਗਾ, signed URLs ਦੀ ਮਿਆਦ, ਅਤੇ “scan passed” ਦਾ ਮਤਲਬ। ਇਹ product, engineering ਅਤੇ support ਵਿਚਕਾਰ ਸਾਂਝਾ ਨਿਯਮ ਬਣ ਜਾਂਦਾ ਹੈ।
ਕੁਝ ਟੈਸਟ ਜੋ ਆਮ ਨੁਕਸਾਨ ਫੜ ਲੈਣ, ਉਨ੍ਹਾਂ ਨੂੰ ਜੋੜੋ: ਓਵਰਸਾਈਜ਼ ਫਾਇਲਾਂ, ਰੀਨੇਮ ਕੀਤੇ executables, ਅਣਅਧਿਕ੍ਰਿਤ ਰੀਡ, ਮਿਆਦ ਖਤਮ ਹੋਇਆ signed URL, ਅਤੇ "scan pending" ਡਾਊਨਲੋਡ ਕੋਸ਼ਿਸ਼। ਇਹ ਟੈਸਟ ਇਕ ਇਨਸידןਟ ਨਾਲੋਂ ਕਾਫ਼ੀ ਸਸਤੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਿਲਡ ਅਤੇ ਇਟਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਐਸਾ ਵਰਕਫਲੋ ਵਰਤੋ ਜਿਸ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਬਦਲਾਅਾਂ ਦੀ ਯੋਜਨਾ ਅਤੇ ਰੋਲਬੈਕ ਕਰਨ ਦੀ ਸਹੂਲਤ ਹੋਵੇ। Koder.ai (koder.ai) ਵਰਗੀਆਂ ਟੀਮਾਂ ਅਕਸਰ planning mode ਅਤੇ snapshots/rollback 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ ਜਦ ਉਹ ਅਪਲੋਡ ਨੀਤੀਆਂ ਕਸਦੀਆਂ ਹਨ, ਪਰ ਮੁੱਖ ਲੋੜ ਹਮੇਸ਼ਾ ਇਹੀ ਰਹਿੰਦੀ ਹੈ: ਨੀਤੀ ਨੂੰ enforced ਕਰਨ ਵਾਲਾ ਬੈਕਐਂਡ ਹੋਵੇ, UI ਨਹੀਂ।
Start with ਪਹਿਲਾਂ ਤੋਂ ਨਿੱਜੀ ਅਤੇ ਹਰ ਅਪਲੋਡ ਨੂੰ ਅਣ-ਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਸਮਝੋ। ਸਰਵਰ-ਸਾਈਡ 'ਤੇ ਇਹ ਚਾਰ ਗੱਲਾਂ ਲਗੂ ਕਰੋ:\n\n- ਕੌਣ ਅਪਲੋਡ ਕਰ ਸਕਦਾ ਹੈ\n- ਤੁਸੀਂ ਕਿਹੜੇ ਫਾਇਲ ਟਾਈਪ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ (allowlist)\n- ਕਿੰਨਾ ਵੱਡਾ/ਕਿੰਨੀ ਵਾਰ (ਸਾਈਜ਼ + ਰੇਟ ਲਿਮਿਟ)\n- ਬਾਅਦ ਵਿੱਚ ਕੌਣ ਪੜ੍ਹ ਸਕਦਾ ਹੈ (ਹਰ ਫਾਇਲ ਲਈ ਪਰਮੀਸ਼ਨ ਚੈਕ)\n\nਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਦੇ ਸਾਫ਼ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਜ਼ਿਆਦਾਤਰ ਘਟਨਾਵਾਂ ਤੋਂ ਪਹਿਲਾਂ ਰਹਿ ਜਾਵੋਗੇ।
ਲੋਕ ਇਕ “ਰਹੱਸਮਈ ਡੱਬਾ” ਭੇਜ ਸਕਦੇ ਹਨ ਜਿਸ ਨੂੰ ਤੁਹਾਡੀ ਐਪ ਸੰਭਾਲਕੇ ਹੋਰ ਯੂਜ਼ਰਾਂ ਨੂੰ ਵਾਪਸ ਦਿਖਾ ਸਕਦੀ ਹੈ। ਇਸ ਨਾਲ ਹੋ ਸਕਦਾ ਹੈ:\n\n- ਨਿੱਜੀ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਅਣਅਧਿਕ੍ਰਿਤ ਪਹੁੰਚ\n- ਜੇ ਕੋਈ ਫਾਇਲ ਭਰੋਸੇਯੋਗ ਵੈੱਬ ਸਮੱਗਰੀ ਵਾਂਗ ਦੁੰਦਲਦੀ ਹੈ ਤਾਂ ਫਿਸ਼ਿੰਗ ਜਾਂ ਅਕਾਊਂਟ ਹੜਪਣਾ\n- ਅਪਲੋਡ ਬੂਮ ਜਾਂ ਬੜੀਆਂ ਫਾਇਲਾਂ ਕਾਰਨ ਸਰਵਰ ਡਾਊਨ ਜਾਂ ਉੱਚਾ ਬਿੱਲ\n\nਇੱਕ ਅਕਸਰ ਗਲਤ ਧਾਰਣਾ ਇਹ ਹੈ ਕਿ “ਕਿਸੇ ਨੇ ਵਾਇਰਸ ਅਪਲੋਡ ਕੀਤਾ।” ਅਸਲ ਵਿੱਚ ਸਮੱਸਿਆ ਅਕਸਰ ਇਸ ਤੋਂ ਵੱਧ ਹੁੰਦੀ ਹੈ।
ਸਟੋਰ ਕਰਨਾ ਸਿਰਫ਼ ਬਾਈਟ ਰੱਖਣਾ ਹੈ। ਸਰਵ ਕਰਨਾ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਬਾਈਟ ਬਰਾਉਜ਼ਰ ਜਾਂ ਐਪਸ ਨੂੰ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ.\n\nਖ਼ਤਰਾ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਯੂਜ਼ਰ-ਅਪਲੋਡ ਨੂੰ ਆਪਣੀ ਮੁੱਖ ਸਾਈਟ ਵਰਗਾ ਹੀ ਭਰੋਸਾ ਦੇਕੇ ਸਰਵ ਕਰਦੇ ਹੋ। ਫਲਸਰੂਪ, ਬਰਾਉਜ਼ਰ ਉਸ ਫਾਇਲ ਨੂੰ ਭਰੋਸੇਯੋਗ ਸਮਝ ਕੇ ਚਲਾਉ ਸਕਦਾ ਹੈ।\n\nਸੁਰੱਖਿਅਤ ਰੂਪ ਇਹ ਹੈ: ਪਹਿਲਾਂ ਨਿੱਜੀ ਸਟੋਰ ਕਰੋ, ਫਿਰ ਨਿਯੰਤਰਿਤ ਡਾਊਨਲੋਡ ਜਵਾਬਾਂ ਰਾਹੀਂ ਸੁਰੱਖਿਅਤ ਹੈਡਰ ਦੇਕੇ ਪਰੋਵਾਈਡ ਕਰੋ।
ਡਿਫੋਲਟ ਡਿਨਾਈ ਅਪਨਾਓ ਅਤੇ ਹਰ ਵਾਰੀ ਫਾਈਲ ਡਾਊਨਲੋਡ/ਪ੍ਰੀਵਿਊ ਹੋਣ 'ਤੇ ਪਹੁੰਚ ਚੈਕ ਕਰੋ।\n\nਅਮਲਕ ਰੂਪ ਵਿੱਚ:\n\n- ਹਰ ਫਾਈਲ ਰਿਕਾਰਡ ਕੋਲ ਮਾਲਕ (ਯੂਜ਼ਰ/ਓਰਗ) ਅਤੇ ਉਦਦੇਸ਼ ਹੋਵੇ\n- ਰੀਡ/ਡਾਊਨਲੋਡ 'ਤੇ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਦੀ ਉਸ ਖਾਸ ਫਾਈਲ ਲਈ ਪਹੁੰਚ ਦੀ ਜਾਂਚ ਕਰੋ\n- /uploads/ ਵਰਗੀਆਂ ਫੋਲਡਰ-ਆਧਾਰਿਤ ਨੀਤੀਆਂ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ\n- ਸਪੋਰਟ ਪਹੁੰਚ ਅਸਥਾਈ ਰੱਖੋ ਅਤੇ ਲੋਗ ਕਰੋ (ਇੱਕ ਫਾਇਲ ਲਈ ਗ੍ਰਾਂਟ, ਆਟੋ-ਐਕਸਪਾਇਰ)\n\nਅਧਿਕਤਰ ਅਸਲੀ ਬੱਗ ਸਧਾਰਨ “ਮੈਂ ਹੋਰ ਯੂਜ਼ਰ ਦੀ ਫਾਈਲ ਵੇਖ ਸਕਦਾ ਹਾਂ” ਜਿਹੇ ਹੁੰਦੇ ਹਨ।
ਫਾਇਲ ਨਾਮ ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਦੇ Content-Type 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਸਰਵਰ 'ਤੇ ਵੈਰੀਫਾਈ ਕਰੋ:\n\n- ਫੀਚਰ ਅਨੁਸਾਰ allowlist ਰੱਖੋ (ਜਿਵੇਂ avatars ਲਈ JPEG/PNG, ਰਸੀਟ ਲਈ PDF)\n- ਸਰਵਰ-ਸਾਈਡ 'ਤੇ ਟਾਈਪ ਪਤਾ ਕਰੋ ਅਤੇ magic bytes (ਫਾਇਲ ਸਿਗਨੇਚਰ) ਚੈੱਕ ਕਰੋ\n- ਸਟੋਰੇਜ ਲਈ ਰੇਂਡਮ ID ਵਰਤੋ; ਅਸਲ ਨਾਮ ਸਿਰਫ਼ ਮੈਟਾ ਡੇਟਾ ਵਜੋਂ ਰੱਖੋ\n- ਜ਼ਰੂਰਤ ਨਾ ਹੋਵੇ ਤਾਂ HTML, SVG ਅਤੇ ਸਕ੍ਰਿਪਟ-ਜਿਹੇ ਟਾਈਪਾਂ ਨੂੰ ਰੋਕੋ\n\nਜੇ ਬਾਈਟਸ ਆਗੇ ਦੀ ਆਸ਼ਾ ਵਾਲੇ ਫਾਰਮੈਟ ਨਾਲ ਮਿਲਦੀਆਂ ਨਹੀਂ, ਤਾਂ ਅਪਲੋਡ ਰੱਦ ਕਰੋ।
ਬਹੁਤ ਸਾਰੀਆਂ ਡਾਉਨਟਾਈਮ ਘਟਨਾਵਾਂ ਸਧਾਰਨ ਦੁਰਵਰਤੋਂ ਦੀ ਵੱਜੋਂ ਹੁੰਦੀਆਂ ਹਨ: ਬਹੁਤ ਵੱਡੀਆਂ ਫਾਇਲਾਂ, ਬਹੁਤ ਬਾਰ ਅਪਲੋਡ, ਜਾਂ ਸਲੇਹੁਕ ਕਨੈਕਸ਼ਨ ਜਿਹੜੇ ਸਰਵਰ ਨੂੰ ਬੁਝਾ ਦਿੰਦੇ ਹਨ। ਹਰ ਬਾਈਟ ਨੂੰ ਇੱਕ ਲਾਗਤ ਸਮਝੋ।\n\nਚੰਗੀਆਂ ਰੁਝਾਨਾਂ:\n\n- ਫੀਚਰ-ਅਨੁਸਾਰ ਮੈਕਸ ਸਾਈਜ਼ ਰੱਖੋ (avatar ਛੋਟੀ, ਦਸਤਾਵੇਜ਼ ਵੱਡਾ)\n- ਲੇਅਰਾਂ 'ਤੇ ਸੀਮਾ ਲਗਾਓ (ਐਪ + ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ + ਟਾਈਮਆਊਟ)\n- ਯੂਜ਼ਰ ਅਤੇ IP ਪੱਧਰ 'ਤੇ ਰੇਟ ਲਿਮਿਟ ਲਗਾਓ; ਐਨੋਨਿਮਸ ਲਈ ਸਖ਼ਤ ਨੀਤੀਆਂ ਰੱਖੋ\n\nਹਰ ਬਾਈਟ ਨੂੰ ਖਰਚ ਮੰਨੋ ਅਤੇ ਹਰ ਰਿਕਵੇਸਟ ਨੂੰ ਸੰਭਾਵਿਤ ਦੁਰਵਰਤੋਂ ਸਮਝੋ।
ਹਾਂ, ਪਰ ਧਿਆਨ ਨਾਲ। Signed URLs ਬਰਤੋਂ ਨੂੰ ਬਿਨਾਂ ਬਕੈਟ ਪਬਲਿਕ ਕੀਤੇ ਬਰਾਊਜ਼ਰ ਨੂੰ ਸਿੱਧਾ ਅਪਲੋਡ/ਡਾਊਨਲੋਡ ਦੀ ਆਗਿਆ ਦੇਂਦੀਆਂ ਹਨ।\n\nਸੁਰੱਖਿਅਤ ਨਿਯਮ:\n\n- ਲਿਖਣ ਵਾਲੇ URLs ਨੂੰ ਛੋਟਾ ਰੱਖੋ (ਅਕਸਰ 1–5 ਮਿੰਟ)\n- ਹਰ URL ਨੂੰ ਇੱਕ ਖ਼ਾਸ ਓਬਜੈਕਟ ਕੀ ਨਾਲ ਬੱਝੋ (ਫੋਲਡਰ ਨਹੀਂ)\n- ਜਿੱਥੇ ਹੋ ਸਕੇ, ਉਮੀਦਿਤ content-type, ਮੈਕਸ ਸਾਈਜ਼, checksum ਜਿਹੀਆਂ ਪਾਬੰਦੀਆਂ ਜੋੜੋ\n- URL ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਰਮੀਸ਼ਨ ਚੈੱਕ ਕਰੋ\n- ਕੌਣ ਅਤੇ ਕਿਉਂ URL ਮੰਗੀ ਇਸਦਾ ਲੌਗ ਰੱਖੋ (ਯੂਜ਼ਰ ID, ਆਈਪੀ, ਯੂਜ਼ਰ ਏਜੈਂਟ)\n\nਇੱਕ ਪ੍ਰਯੋਗਕ ਰੂਪ-ਰੇਖਾ ਇਹ ਹੈ: ਪਹਿਲਾਂ pending ਸਟੇਟ ਨਾਲ ਇਕ ਅਪਲੋਡ ਰਿਕਾਰਡ ਬਣਾਓ, ਫਿਰ signed URL ਜਾਰੀ ਕਰੋ, ਅਪਲੋਡ ਹੋਣ ਤੋਂ ਬਾਅਦ ਆਬਜੈਕਟ ਦੀ ਜਾਂਚ ਕਰਕੇ ਉਸਨੂੰ ready ਕਰੋ।
ਹੇਠਾਂ ਇੱਕ ਆਮ ਤੇ ਸੁਰੱਖਿਅਤ ਫਲੋ ਹੈ ਜੋ ਅਪનਾਇਆ ਜਾ ਸਕਦਾ ਹੈ:\n\n1) ਫੀਚਰ-ਅਨੁਸਾਰ ਮਨਜ਼ੂਰ ਕੀਤੇ ਟਾਈਪ ਅਤੇ ਮੈਕਸ ਸਾਈਜ਼ ਤਿਆਰ ਕਰੋ (ਜਿਵੇਂ: ਫੋਟੋ 5 MB ਤੱਕ; PDF 20 MB ਤੱਕ).\n\n2) bytes ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਕ "upload record" ਬਣਾਓ। ਸਟੋਰ ਕਰੋ: ਮਾਲਕ, ਉਦੇਸ਼, ਅਸਲ filename, ਅਨੁਮਾਨਤ ਮੈਕਸ ਸਾਈਜ਼ ਅਤੇ pending ਵਰਗਾ status.\n\n3) ਅਪਲੋਡ ਨੂੰ ਨਿੱਜੀ ਥਾਂ 'ਤੇ ਕਰੋ। ਕਲਾਇੰਟ ਨੂੰ ਆਖਰੀ ਪਾਥ ਚੁਣਨ ਦੀ ਆਗਿਆ ਨਾ ਦੇਵੋ।\n\n4) ਸਰਵਰ-ਸਾਈਡ ਫਿਰ ਤੋਂ ਵੈਰੀਫਾਈ ਕਰੋ: ਸਾਈਜ਼, magic bytes/type, allowlist. ਜੇ ਪਾਸ ਹੋਏ ਤਾਂ status uploaded ਕਰੋ।\n\n5) ਮਾਲਵੇਅਰ ਸਕੈਨ ਕਰੋ ਅਤੇ status clean ਜਾਂ quarantined ਕਰੋ। ਜੇ ਸਕੈਨ ਅਸਿੰਕ ਹੈ, ਤਾਂ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਐਕਸੈਸ ਲੌਕ ਰੱਖੋ।\n\n6) ਫਾਇਲ ਸਿਰਫ਼ ਹੋਣ 'ਤੇ ਹੀ ਡਾਊਨਲੋਡ/ਪ੍ਰੀਵਿਊ ਲਈ ਦਿਓ।
ਸਕੈਨਿੰਗ ਇੱਕ ਸੁਰੱਖਿਆ ਜਾਲ ਹੈ, ਪਰ ਇਹ ਹਰ ਚੀਜ਼ ਨਹੀਂ ਪਕੜਦੀ। ਨੀਤੀ ਇਹ ਹੋਵੇ: ਪਹਿਲਾਂ ਕਵਾਰੰਟੀਨ, ਫਿਰ ਸਕੈਨ।\n\nਅਮਲਕ ਪੈਟਰਨ:\n\n- ਹਰ ਨਵੇਂ ਅਪਲੋਡ ਨੂੰ ਨਿੱਜੀ, ਕਵਾਰੰਟੀਨ ਥਾਂ 'ਤੇ ਰਖੋ ਅਤੇ ਢੁਕਵਾਂ ਹੋਣ ਤੱਕ ਪਹੁੰਚ ਬੰਦ ਰੱਖੋ\n- ਛੋਟੀਆਂ ਫਾਇਲਾਂ ਅਤੇ ਘੱਟ ਟ੍ਰੈਫਿਕ ਲਈ ਸਿੰਕ੍ਰੋਨਸ ਸਕੈਨ ਚੰਗਾ ਹੈ; ਵੱਡੇ ਸਕੇਲ ਲਈ ਅਸਿੰਕ੍ਰੋਨਸ ਸਕੈਨ ਵਰਤੋ\n\nਬੁਨਿਆਦੀ ਸਕੈਨ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ: AV ਇੰਜਣ, ਫਾਇਲ-ਟਾਈਪ ਚੈੱਕ (magic bytes), ਆਰਕਾਈਵ ਹੱਦਾਂ (zip bombs, nested zips), ਅਤੇ ਬਿਨਾਂ ਲੋੜ ਦੇ ਫਾਰਮੈਟਾਂ ਨੂੰ ਰੋਕਣਾ।\n\nਜੇ ਸਕੈਨ ਫੇਲ ਜਾਂ ਟਾਈਮਆਊਟ ਹੋ ਜਾਵੇ, ਤਾਂ ਫਾਇਲ ਨੂੰ ਸੰਦਾਿਗਧ ਸਮਝੋ ਅਤੇ ਕਵਾਰੰਟੀਨ ਹੀ ਰੱਖੋ। ਯੂਜ਼ਰ ਸੰਦੇਸ਼ ਨਿਊਟਰਲ ਰੱਖੋ: “ਅਸੀਂ ਇਹ ਫਾਇਲ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰ ਸਕੇ। ਕਿਰਪਾ ਕਰਕੇ ਵੱਖਰੀ ਫਾਇਲ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਜਾਂ ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ ਕਰੋ।”
ਅਵਤਾਰ ਫੋਟੋ ਲਈ ਕੜਾ ਰੂਲ: ਸਿਰਫ JPEG/PNG, ਸਾਈਜ਼ ਸੀਮਾ, ਸਰਵਰ-ਸਾਈਡ ਰੀ-ਇੰਕੋਡ (ਤਾਂ ਜੋ ਅਸਲੀ ਬਾਈਟਸ ਨਾ ਸਰਵ ਹੋਣ)। ਜਦੋਂ ਚੈੱਕ ਹੋਜੇ ਤਾਂ ਹੀ ਪਬਲਿਕ ਸਟੋਰੇਜ ਵਿੱਚ ਰੱਖੋ।\n\nPDF ਰਸੀਟ ਲਈ ਵੱਡੀ ਸਾਈਜ਼ ਦੀ ਆਗਿਆ, ਨਿੱਜੀ ਰੱਖੋ ਅਤੇ ਮੁੱਖ ਐਪ ਡੋਮੇਨ ਤੋਂ ਇਨਲਾਈਨ ਰੇਂਡਰ ਨਾ ਕਰੋ।\n\nਸਧਾਰਨ ਸਟੇਟ ਮਾਡਲ ਯੂਜ਼ਰ ਨੂੰ ਬਿਨਾਂ ਅੰਦਰੂਨੀ ਜਾਣਕਾਰੀ ਦਿੱਤੇ ਅਪਡੇਟ ਰੱਖਦਾ ਹੈ:\n\n- pending: ਯੂਜ਼ਰ ਨੇ ਫਾਇਲ ਚੁਣ ਲਈ; ਅਪਲੋਡ ਸ਼ੁਰੂ ਨਹੀਂ\n- uploaded: ਸਟੋਰੇਜ ਨੇ ਬਾਈਟਸ ਲੈ ਲਏ\n- scanning: ਬੈਕਗ੍ਰਾਉਂਡ ਜੌਬ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ\n- clean (ਜਾਂ rejected): ਫਾਇਲ ਉਪਲਬਧ (ਜਾਂ ਬਲੌਕ ਕੀਤੀ ਗਈ)\n\nSigned URLs ਇਥੇ ਵਧੀਆ ਵੱਕਰਾ ਦਿੰਦੇ ਹਨ: ਲਿਖਣ ਲਈ ਛੋਟੀ ਮਿਆਦ ਵਾਲਾ signed URL ਜਾਰੀ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਹੋਣ 'ਤੇ ਪੜ੍ਹਨ ਲਈ ਅਲੱਗ, ਛੋਟੀ ਮਿਆਦ ਵਾਲਾ URL ਦਿਓ।
ਅਕਸਰ ਗਲਤੀਆਂ ਛੋਟੇ ‘ਅਸਥਾਈ’ ਤੌਰ ਤੇ ਕੀਤੇ ਸੁਧਾਰਾਂ ਕਾਰਨ ਪੈਦਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਹਰ ਫਾਈਲ ਨੂੰ ਅਣ-ਭਰੋਸੇਯੋਗ ਮੰਨੋ, ਹਰ URL ਸਾਂਝਾ ਹੋ ਸਕਦੀ ਸੋਚੋ, ਅਤੇ ਕਦੇ-ਕਦੇ "ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਾਂਗੇ" ਵਾਲੇ ਫੈਸਲੇ ਭੁੱਲ ਜਾਂਦੇ ਹਨ।\n\nਆਮ ਫੈਸਲੇ:\n\n- ਸਿਰਫ਼ ਕਲਾਇੰਟ-ਸਾਈਡ ਚੈੱਕ ਤੇ ਭਰੋਸਾ ਕਰਨਾ\n- ਯੂਜ਼ਰ-ਨਿਰਧਾਰਤ ਪਾਥ/ਫਾਈਲ ਨਾਂ ਤੇ ਆਧਾਰਿਤ rਪਾਲਣਾ\n- ਅਪਲੋਡ ਨੂੰ “ਇੱਕ ਛੋਟੇ ਸਮੇਂ ਲਈ” ਪਬਲਿਕ ਕਰਨਾ\n- ਲੰਮੀ ਅਵਧੀ ਵਾਲੇ ਜਾਂ ਬਹੁ-ਯੂਜ਼ਰ ਵਾਲੇ signed URLs\n- ਗ਼ਲਤ Content-Type ਨਾਲ ਸਰਵ ਕਰਨਾ ਜਿਹੜਾ ਬਰਾਉਜ਼ਰ ਨੂੰ ਖਤਰਨਾਕ ਸਮੱਗਰੀ ਚਲਾਉਣ ਦਿੱਤੇ\n\nਮਾਨੀਟਰਿੰਗ ਬਹੁਤ ਜਰੂਰੀ ਹੈ: ਅਪਲੋਡ ਵॉलਯੂਮ, ਆਸਤਾਂ ਸਾਈਜ਼, ਸਿਖਰ ਯੂਜ਼ਰ, ਅਤੇ ਏਰਰ ਰੇਟ ਟ੍ਰੈਕ ਕਰੋ। ਇੱਕ ਕੰਪ੍ਰੋਮਾਈਜ਼ਡ ਅਕਾਉਂਟ ਰਾਤੋ-ਰਾਤ ਹਜ਼ਾਰਾਂ ਵੱਡੀਆਂ ਫਾਇਲਾਂ ਅਪਲੋਡ ਕਰ ਸਕਦੇ ਹਨ।
ਇਹ ਰਹੀ ਇੱਕ ਸਿੱਧੀ ਚੈਕਲਿਸਟ ਜੋ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਕੰਮ ਆ ਸਕਦੀ ਹੈ:\n\n### Quick checklist\n\n- ਸਰਵਰ-ਸਾਈਡ ਤੇ allowlist, ਅਸਲ ਕੰਟੈਂਟ ਚੈੱਕ (filename 'ਤੇ ਨਹੀਂ), ਅਤੇ ਹਰ ਫਾਇਲ ਲਈ ਕਠੋਰ ਮੈਕਸ ਸਾਈਜ਼ ਲਗਾਓ।\n- ਅਪਲੋਡ ਨੂੰ ਡਿਫੋਲਟ ਤੌਰ ਤੇ ਨਿੱਜੀ ਰੱਖੋ, ਅਤੇ ਹਰ ਵਾਰੀ ਪੜ੍ਹਨ/ਡਾਊਨਲੋਡ 'ਤੇ ਪਰਮੀਸ਼ਨ ਚੈੱਕ ਕਰੋ।\n- ਜੇ signed URL ਵਰਤਦੇ ਹੋ, ਤਾਂ ਉਹ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ, ਇੱਕ ਓਬਜੈਕਟ ਕੀ ਤੱਕ ਸੀਮਿਤ ਅਤੇ ਜਾਰੀ ਕਰਨ ਦਾ ਲੌਗ ਰੱਖਣ ਵਾਲੇ ਰੱਖੋ।\n- ਪਹਿਲਾਂ ਕਵਾਰੰਟੀਨ, ਫਿਰ ਸਕੈਨ: ਪ੍ਰੀਵਿਊ ਜਾਂ ਡਾਊਨਲੋਡ ਤੱਕ ਫਾਇਲ ਨੂੰ ਨਾ ਛੱਡੋ ਜਦ ਤੱਕ ਉਹ clean ਨਾ ਹੋਵੇ।\n- ਸੇਫ ਡਾਊਨਲੋਡ ਵਿਹੇਵਿਅਰ ਜਿਵੇਂ ਪ੍ਰਿਡਿਕਟੇਬਲ Content-Type, ਸੇਫ ਫਾਈਲ ਨਾਂ, ਅਤੇ attachment ਦਿਓ।\n\n### Next steps that pay off\n\nਆਪਣੀਆਂ ਨੀਤੀਆਂ ਸਾਫ਼ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ: ਮਨਜ਼ੂਰ ਟਾਈਪ, ਮੈਕਸ ਸਾਈਜ਼, ਕੌਣ ਕਿਹੜੀ ਪਹੁੰਚ ਰੱਖੇਗਾ, signed URLs ਦੀ ਮਿਆਦ, ਤੇ “scan passed” ਦਾ ਮਤਲਬ। ਇਹ product, engineering ਅਤੇ support ਵਿਚਕਾਰ ਸਾਂਝਾ ਸਮਝੌਤਾ ਬਣ ਜਾਂਦਾ ਹੈ।\n\nਅਲੱਗ-ਅਲੱਗ ਟੈਸਟ ਲਿਖੋ ਜੋ ਆਮ ਫੇਲਿਅਰ ਫੇਲ ਕਰਵਾ ਸਕਣ: ਓਵਰਸਾਈਜ਼ ਫਾਇਲ, ਰੀਨੇਮ ਕੀਤੇ ਏਗਜ਼ਿਕਯੂਟੇਬਲ, ਅਣਅਧਿਕ੍ਰਿਤ ਰੀਡਸ, ਮਿਆਦ ਖਤਮ ਹੋਇਆ signed URL, ਅਤੇ "scan pending" ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼।
cleanclean