𝗜 𝗔𝘂𝗱𝗶𝘁𝗲𝗱 𝗠𝘆 𝗦𝗶𝗱𝗲 𝗣𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗳𝗼𝗿 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 — 𝗛𝗲𝗿𝗲 𝗜𝘀 𝗪𝗵𝗮𝘁 𝗜 𝗙𝗼𝘂𝗻𝗱
میں نے حال ہی میں اپنے تمام سائیڈ پروجیکٹس کا آڈٹ کیا۔ میں نے اپنے FastAPI backends، Telegram bots، اور web apps کو چیک کیا۔ مجھے لگا تھا کہ میں محتاط ہوں۔
میں غلط تھا۔
مجھے ایسے حقیقی بگ (bugs) ملے جو میں نے حقیقت میں پروڈکشن (production) میں بھیج دیے تھے۔ یہ کوئی نظریاتی مسائل نہیں ہیں۔ یہ وہ غلطیاں ہیں جو میں نے تیزی سے کام کرنے کی کوشش میں کیں۔
یہاں وہ اہم مسائل ہیں جو مجھے ملے اور انہیں ٹھیک کرنے کے طریقے:
- Conditional Authentication میں نے ایسا کوڈ لکھا تھا جو API keys کو صرف اس صورت میں چیک کرتا تھا اگر کوئی secret موجود ہو۔ اگر میں اپنے environment میں secret سیٹ کرنا بھول جاتا، تو چیک مکمل طور پر نظر انداز ہو جاتا۔ اس سے میری API ہر کسی کے لیے کھلی رہ جاتی۔
- حل: توثیق (authentication) کو کبھی بھی شرطیہ نہ بنائیں۔ اگر secret موجود نہ ہو، تو ایپ کو ایرر (error) دینا چاہیے اور رک جانا چاہیے۔
- Leaking Keys in Git History مجھے اپنی Git history میں پرانی API keys ملیں۔ میں نے بعد میں انہیں .env فائلوں میں منتقل کر دیا تھا، لیکن Git آپ کے کوڈ کا ہر پرانا ورژن ہمیشہ کے لیے محفوظ رکھتا ہے۔
- حل: Git میں کبھی بھی کمٹ (commit) کی گئی کسی بھی key کو غیر محفوظ (compromised) سمجھیں۔ اسے فوری طور پر منسوخ (revoke) کریں۔ اپنی ہسٹری صاف کرنے کے لیے git-filter-repo جیسے ٹولز استعمال کریں۔
- Leftover Debug Endpoints میں نے پروڈکشن میں ایسے endpoints چھوڑ دیے تھے جو میری ڈیٹا بیس کنفیگریشن اور سسٹم سیٹنگز دکھاتے تھے۔ یہ ڈویلپمنٹ کے دوران مددگار ہوتے ہیں لیکن اصل استعمال میں خطرناک ہیں۔
- حل: اپنی ڈیپلائمنٹ چیک لسٹ (deployment checklist) میں debug endpoint کو ہٹانے کا مرحلہ شامل کریں۔
- Verbose Error Messages میں صارف کو سسٹم کے اصل (raw) ایررز واپس کر رہا تھا۔ یہ ایررز آپ کے فائل پاتھ، ڈیٹا بیس کی اقسام، اور لائبریری کے ورژن ظاہر کرتے ہیں۔ ایک حملہ آور (attacker) آپ کے سسٹم کو نشانہ بنانے کے لیے اس ڈیٹا کا استعمال کر سکتا ہے۔
- حل: اپنے لیے مکمل ایرر کو اندرونی طور پر لاگ (log) کریں۔ کلائنٹ کو ایک عام "Internal Server Error" پیغام واپس کریں۔
- XSS via innerHTML
میں نے اپنے فرنٹ اینڈ (frontend) میں صارف کا ڈیٹا دکھانے کے لیے
innerHTMLکا استعمال کیا۔ یہ حملہ آوروں کو آپ کی سائٹ میں اسکرپٹس (scripts) انجیکٹ کرنے کی اجازت دیتا ہے۔
- حل: ہمیشہ ڈیٹا کو صاف (sanitize) کریں یا
innerHTMLکے بجائےtextContentاستعمال کریں۔
- Lack of Rate Limiting میرے پاس ایسے endpoints تھے جو بغیر کسی حد کے مہنگے AI ماڈلز کو کال کرتے تھے۔ ایک صارف چند منٹوں میں بہت بڑا بل بنا سکتا تھا۔
- حل: Authentication غیر مجاز صارفین کو روکتی ہے۔ Rate limiting مجاز صارفین کو آپ کے سسٹم کا غلط استعمال کرنے سے روکتی ہے۔ آپ کو دونوں کی ضرورت ہے۔
- Permissive CORS Settings
میں نے اپنے middleware میں
allow_origins=["*"]استعمال کیا تھا۔ یہ کسی بھی ویب سائٹ کو آپ کی API کو ریکویسٹ (request) بھیجنے کی اجازت دیتا ہے۔
- حل: پروڈکشن میں صرف اپنے مخصوص ڈومینز (domains) کی اجازت دیں۔
- فائل لیکج میں نے ایسا کوڈ لکھا جو عارضی فائلیں تو بناتا تھا لیکن اگر عمل (process) کریش ہو جائے تو انہیں حذف کرنے میں ناکام رہتا تھا۔ یہ فائلیں آپ کے سرور پر ہمیشہ کے لیے رہ جاتی ہیں۔
- حل: try-finally بلاک کا استعمال کریں تاکہ اس بات کو یقینی بنایا جا سکے کہ غلطی (error) ہونے کی صورت میں بھی فائلیں حذف ہو جائیں۔
سیکیورٹی کے مسائل شاذ و نادر ہی جان بوجھ کر پیدا کیے جاتے ہیں۔ یہ "میں اسے بعد میں ٹھیک کر لوں گا" کہنے کا نتیجہ ہوتے ہیں۔ وہ "بعد میں" کبھی نہیں آتا۔
پہلے دن سے ہی اپنے ورک فلو (workflow) میں سیکیورٹی کو شامل کریں۔ کوڈ کو کمٹ (commit) کرنے اور ڈیپلائے (deploy) کرنے سے پہلے اسے ضرور چیک کریں۔
ماخذ: https://dev.to/justjinoit/i-audited-my-own-side-projects-for-security-issues-heres-what-i-found-1ahb