AI سے بنی ایپس کے لیے سیکیورٹی چیک لسٹ: لانچ سے پہلے کیا جانچیں

حقیقی لوگوں کے استعمال سے پہلے، جو ایپ آپ نے AI سے بنائی ہے اس کی سات چیزیں جانچیں: ہر صفحہ اور API یہ چیک کرے کہ صارف کون ہے اور وہ کیا کر سکتا ہے؛ خفیہ کیز سرور پر رہیں، کبھی براؤزر یا چیٹ میں نہیں؛ تمام ان پٹ سرور پر توثیق شدہ ہو؛ ہر صارف صرف اپنے ریکارڈز تک پہنچ سکے؛ لاگ ان اور مہنگے اینڈ پوائنٹس پر ریٹ لمٹ ہو؛ ڈیپنڈنسیز اپ ٹو ڈیٹ ہوں؛ اور اگر کچھ غلط ہو جائے تو آپ اپنا ڈیٹا بحال کر سکیں۔ ذیل کی چیک لسٹ ان میں سے ہر ایک کو ایسے مخصوص ٹیسٹس میں بدلتی ہے جو آپ کوڈ پڑھے بغیر چلا سکتے ہیں۔

AI ایپ بلڈرز فیچرز کو کام کرانے میں اچھے ہیں۔ وہ خودکار طور پر محتاط نہیں ہوتے، کیونکہ "احتیاط" شاذ و نادر ہی پرامپٹ میں ہوتی ہے۔ ذیل کے زیادہ تر مسائل ان چیزوں سے آتے ہیں جن کا کسی نے مطالبہ نہیں کیا، اس لیے حل عام طور پر یہ ہے کہ پوچھا جائے۔

اس چیک لسٹ کو کیسے استعمال کریں

اسے ترتیب سے مکمل کریں، اور ہر آئٹم کے لیے دو کام کریں: یقینی بنانے کے لیے AI سے پوچھیں کہ یہ ہینڈل ہو چکا ہے، اور خود جانچیں۔ AI اجازت کی جانچ لکھ سکتا ہے؛ صرف ٹیسٹ بتاتا ہے کہ وہ کام کرتی ہے۔ آئٹمز کو اس طرح نشان زد کیا گیا ہے:

• ضروری — کسی اور کے ایپ استعمال کرنے سے پہلے یہ کریں۔
• ہونا چاہیے — حقیقی صارفین یا حقیقی ڈیٹا آنے سے پہلے یہ کریں۔
• بعد میں — ایپ بڑھنے کے ساتھ کرنے کے قابل۔

اگر آپ کے پاس صرف ایک گھنٹہ ہے تو ہر ضروری آئٹم مکمل کریں۔

1. توثیق (Authentication): یہ کون ہے؟

توثیق کا مطلب ہے یہ تصدیق کرنا کہ کوئی شخص کون ہے، عموماً لاگ ان کے ذریعے۔ بنیادی باتوں کے لیے توثیق کیا ہے اور اپنی ایپ میں لاگ ان شامل کرنے کے اختیارات کے لیے اپنی ایپ میں لاگ ان کیسے شامل کریں دیکھیں۔

• ضروری: نجی ڈیٹا دکھانے والے ہر صفحے کے لیے لاگ ان لازمی ہو۔ ٹیسٹ: لاگ آؤٹ کریں، پھر کسی نجی صفحے کا URL براہ راست براؤزر میں پیسٹ کریں۔
• ضروری: ان صفحات کے پیچھے موجود ہر API اینڈ پوائنٹ پر بھی لاگ ان لازمی ہو، صرف صفحے پر نہیں۔ ٹیسٹ: لاگ آؤٹ کریں، براؤزر کا نیٹ ورک ٹیب کھولیں، اور وہ درخواست دوبارہ چلائیں جو ایپ نے لاگ ان کے دوران کی تھی۔
• ضروری: پاس ورڈز سست پاس ورڈ ہیشنگ الگورتھم سے ہیش کر کے محفوظ ہوں، سادہ متن میں کبھی نہیں۔ OWASP کی پاس ورڈ اسٹوریج گائیڈ پہلے Argon2id کی سفارش کرتی ہے، متبادل کے طور پر scrypt، bcrypt یا PBKDF2 کے ساتھ۔ پوچھیں: "پاس ورڈز کیسے محفوظ ہوتے ہیں؟"
• ہونا چاہیے: پاس ورڈ ری سیٹ کے لنکس ایک بار کام کریں اور ان کی میعاد ختم ہو۔
• ہونا چاہیے: سیشن کوکیز پر Secure، HttpOnly اور SameSite لگے ہوں، اور لاگ آؤٹ سرور پر سیشن ختم کرے۔
• بعد میں: دو عنصری توثیق پیش کریں، یا ایسے فراہم کنندہ کے ذریعے سائن ان جو یہ سہولت رکھتا ہو۔

ہر API روٹ اور صفحے کی جانچ کریں جو صارف کا ڈیٹا واپس کرتا ہے۔ ہر ایک کو ان صارفین کی درخواستیں مسترد کرنی چاہئیں جو لاگ ان نہیں ہیں، سرور پر، صرف صفحے کے کوڈ میں نہیں۔ جن روٹس کی جانچ کی ان کی فہرست بنائیں۔

2. اجازت (Authorization): انہیں کیا کرنے کی اجازت ہے؟

اجازت لاگ ان کے بعد کا مرحلہ ہے: یہ طے کرنا کہ یہ مخصوص صارف کیا دیکھ اور تبدیل کر سکتا ہے۔ AI سے بنی ایپس میں سنگین خامیاں اکثر یہیں ہوتی ہیں، کیونکہ ایپ درست نظر آتی ہے — ہر صارف کا ڈیش بورڈ صرف اس کا ڈیٹا دکھاتا ہے — جبکہ سرور براہ راست پوچھنے پر کسی کا بھی ڈیٹا خوشی سے دے دیتا ہے۔

• ضروری: ہر پڑھنے، اپ ڈیٹ اور حذف کے عمل میں سرور پر جانچ ہو کہ ریکارڈ موجودہ صارف (یا اس کی ٹیم) کا ہے۔
• ضروری: جانچیں: دو اکاؤنٹس بنائیں، A اور B۔ A کے طور پر A کا کوئی ریکارڈ کھولیں اور URL یا نیٹ ورک درخواست میں ID نوٹ کریں۔ B کے طور پر لاگ ان کریں اور وہی ID درخواست کریں۔ B کو خرابی ملنی چاہیے، A کا ڈیٹا نہیں۔
• ضروری: ایڈمن صفحات اور ایڈمن API اینڈ پوائنٹس صارف کا کردار سرور پر چیک کریں۔ ایڈمن لنک چھپانا تحفظ نہیں ہے۔
• ضروری: صارفین درخواست میں ترمیم کر کے اپنا کردار، قیمت، بیلنس یا مالک کے فیلڈز تبدیل نہ کر سکیں۔ ٹیسٹ: نیٹ ورک ٹیب میں دیکھیں کہ پروفائل اپ ڈیٹ کیا بھیجتا ہے۔ اگر اس میں role یا isAdmin جیسے فیلڈز ہوں تو AI سے کہیں کہ انہیں کلائنٹ سے نظر انداز کرے۔
• ہونا چاہیے: URLs میں IDs اندازہ لگانا مشکل ہوں (1، 2، 3 کے بجائے رینڈم IDs)۔ یہ اجازت کی جانچ کا متبادل نہیں، لیکن جب کوئی جانچ غائب ہو تو نقصان کو محدود کرتا ہے۔

ہر اینڈ پوائنٹ کے لیے جو ریکارڈ پڑھتا یا بدلتا ہے، سرور پر جانچیں کہ لاگ ان صارف اس کا مالک ہے یا اس تک رسائی کا حق رکھتا ہے۔ اگر نہیں تو 404 واپس کریں۔ پھر دکھائیں کہ آپ دو اکاؤنٹس کے ساتھ اسے کیسے جانچیں گے۔

3. ڈیٹا بیس میں قطار کی سطح پر رسائی

"قطار کی سطح پر رسائی" کا مطلب ہے کہ ٹیبل کی ہر قطار (ایک بکنگ، ایک انوائس) صرف انہی صارفین کو نظر آئے جن کی وہ ہے۔ اسے نافذ کرنے کے دو عام طریقے ہیں:

دونوں اچھی طرح کیے جا سکتے ہیں۔ اہم باتیں یہ ہیں:

• ضروری: اگر براؤزر ڈیٹا بیس سے براہ راست بات کرتا ہے (کچھ ہوسٹڈ ڈیٹا بیس پروڈکٹس اس کی اجازت دیتی ہیں)، تو ہر ٹیبل پر قطار کی سطح کے قواعد آن ہوں۔ ان کے بغیر، عوامی کی رکھنے والا کوئی بھی شخص پوری ٹیبل پڑھ سکتا ہے۔
• ضروری: کوئریاں موجودہ صارف یا ٹیم سے فلٹر ہوں، براؤزر کی بھیجی ہوئی ID سے نہیں۔
• ہونا چاہیے: مشترکہ ڈیٹا (ٹیم کے پروجیکٹس) کا ایک واضح قاعدہ ہو کہ ٹیم میں کون ہے، جو ایک ہی جگہ نافذ ہو۔

4. خفیہ معلومات اور API کیز

API کی ایک سروس کا پاس ورڈ ہوتی ہے۔ Stripe، ای میل اور AI فراہم کنندگان سبھی انہیں استعمال کرتے ہیں۔ پس منظر کے لیے ماحولیاتی متغیرات اور سیکریٹس کیا ہیں دیکھیں۔

• ضروری: کیز پروجیکٹ کے ماحولیاتی متغیرات یا سیکریٹس میں محفوظ ہوں، کبھی کوڈ میں نہ لکھی جائیں۔
• ضروری: وہ کیز جو پیسے خرچ کر سکتی ہیں یا نجی ڈیٹا پڑھ سکتی ہیں صرف سرور پر استعمال ہوں۔ ٹیسٹ: اپنی لائیو سائٹ کھولیں، ڈیولپر ٹولز میں صفحے کا سورس اور JavaScript فائلیں دیکھیں، اور اپنی کیز کا شروع کا حصہ تلاش کریں (مثلاً sk_)۔ یہ ظاہر نہیں ہونا چاہیے۔
• ضروری: کیز کبھی چیٹ، عوامی ریپوزٹری یا اسکرین شاٹ میں پیسٹ نہ ہوں۔ اگر ہوئی ہوں تو فراہم کنندہ کے پاس انہیں بدل دیں (نئی بنائیں، پرانی حذف کریں)۔
• ہونا چاہیے: جہاں فراہم کنندہ پیش کرے وہاں محدود یا محدود دائرہ کار والی کیز استعمال کریں۔ مثلاً Stripe محدود کیز کی سفارش کرتا ہے جن کے پاس صرف وہی اجازتیں ہوں جن کی آپ کے انٹیگریشن کو ضرورت ہے۔
• ہونا چاہیے: ٹیسٹ اور لائیو کیز الگ ہوں، اور لائیو ایپ لائیو کیز صرف اس وقت استعمال کرے جب آپ تیار ہوں۔

کچھ کیز عوامی ہونے کے لیے بنائی جاتی ہیں، جیسے Stripe کی publishable key (pk_…) یا آپ کے ڈومین تک محدود نقشوں کی کی۔ قاعدہ ان کیز کے بارے میں ہے جو طاقت دیتی ہیں، نہ کہ ہر اس سٹرنگ کے بارے میں جو کی جیسی لگے۔

5. ان پٹ کی توثیق

صارف جو کچھ بھی بھیجے، جیسے فارم فیلڈز، فائل اپ لوڈز، یا URL پیرامیٹرز، وہ کچھ بھی ہو سکتا ہے، صرف وہ نہیں جو آپ کا فارم اجازت دیتا ہے۔

• ضروری: توثیق سرور پر ہو، صرف براؤزر میں نہیں۔ براؤزر کی جانچیں سہولت کے لیے ہیں؛ کوئی بھی انہیں چھوڑ سکتا ہے۔
• ضروری: ڈیٹا بیس کوئریاں پیرامیٹرز استعمال کریں، صارف کے ان پٹ سے جوڑے ہوئے متن سے نہیں (اس سے SQL injection رکتا ہے)۔ AI سے تصدیق کرائیں۔
• ضروری: صارفین کا درج کردہ متن بطور متن دکھایا جائے، HTML کے طور پر نہیں چلایا جائے۔ ٹیسٹ: اپنے نام کے طور پر <b>hello</b> درج کریں۔ آپ کو ٹیگز نظر آنے چاہئیں، بولڈ متن نہیں۔
• ہونا چاہیے: فائل اپ لوڈز کی قسم اور سائز کی جانچ ہو، اور اپ لوڈ شدہ فائلیں آپ کے ایپ کے مرکزی ڈومین سے چلنے والے صفحات کے طور پر پیش نہ ہوں۔
• ہونا چاہیے: صارفین کو دکھائی جانے والی خرابیاں سادہ ہوں ("کچھ غلط ہو گیا")؛ تفصیلی خرابیاں صرف سرور لاگز میں جائیں۔
• ہونا چاہیے: Stripe جیسی سروسز کے webhooks کارروائی سے پہلے فراہم کنندہ کے دستخط کی تصدیق کریں۔ دیکھیں webhook کیا ہے۔

ہر فارم اور API اینڈ پوائنٹ میں سرور پر توثیق شامل کریں: مطلوبہ فیلڈز، لمبائی، فارمیٹس اور اجازت شدہ قدریں۔ باقی سب کو واضح پیغام کے ساتھ مسترد کریں۔ صارفین کو اندرونی خرابی کی تفصیلات نہ دکھائیں۔

6. ریٹ لمٹس اور غلط استعمال

ریٹ لمٹ کسی مدت میں کوئی شخص کتنی درخواستیں کر سکتا ہے اس کی حد مقرر کرتی ہے۔ ان کے بغیر، کوئی بھی دن بھر پاس ورڈ کا اندازہ لگا سکتا ہے، آپ کا سائن اپ فارم بھر سکتا ہے، یا ادا شدہ API پر آپ کا بل بڑھا سکتا ہے۔

• ضروری: لاگ ان، سائن اپ اور پاس ورڈ ری سیٹ پر فی IP ایڈریس اور فی اکاؤنٹ ریٹ لمٹ ہو۔
• ضروری: ہر کال پر پیسے خرچ کرنے والی ہر چیز (AI ماڈل درخواستیں، SMS، ای میل) پر فی صارف حد ہو اور لاگ ان ضروری ہو۔
• ہونا چاہیے: عوامی فارمز (رابطہ، ویٹ لسٹ) پر اسپیم سے تحفظ ہو: ریٹ لمٹ، چھپا ہوا honeypot فیلڈ، یا CAPTCHA۔
• ہونا چاہیے: ادا شدہ فراہم کنندگان پر خرچ کی حد یا الرٹس لگائیں، تاکہ کوئی بگ یا حملہ آور لامحدود بل نہ بنا سکے۔

7. ڈیپنڈنسیز

ایپس اوپن سورس پیکجز سے بنتی ہیں، اور پیکجز میں بعض اوقات معلوم خامیاں ہوتی ہیں۔

• ہونا چاہیے: AI سے معلوم خامیوں کی جانچ کرائیں (JavaScript پروجیکٹس کے لیے npm audit یا آپ کے پیکج مینیجر کا مساوی) اور متاثرہ چیزیں اپ ڈیٹ کریں۔
• ہونا چاہیے: وہ پیکجز ہٹائیں جو ایپ اب استعمال نہیں کرتی۔
• ہونا چاہیے: ایسے پیکجز سے محتاط رہیں جن کے صارف بہت کم ہوں یا جن کے نام مشہور پیکجز کی املاء کی غلطیوں جیسے ہوں۔
• بعد میں: ہر ایک یا دو ماہ بعد دوبارہ جانچیں، یا اگر آپ کا کوڈ GitHub پر ہے تو خودکار الرٹس آن کریں۔

8. بیک اپس اور بحالی

سیکیورٹی میں غلطیوں سے بحال ہونے کی صلاحیت شامل ہے، چاہے وہ آپ کی ہوں، AI کی ہوں، یا کسی حملہ آور کی۔

• ضروری: جانیں کہ آپ کا ڈیٹا کہاں رہتا ہے اور کیا اس کا بیک اپ ہوتا ہے۔ اندازہ نہ لگائیں؛ اپنے ہوسٹ کی دستاویزات چیک کریں۔
• ہونا چاہیے: اہم ڈیٹا کی اپنی وقفے وقفے سے ایکسپورٹ رکھیں (مثلاً CSV ایکسپورٹ فیچر یا ڈیٹا بیس ڈمپ)، کسی الگ جگہ پر محفوظ۔
• ہونا چاہیے: اپنا کوڈ ورژن کنٹرول میں رکھیں تاکہ کوئی بھی ورژن بحال ہو سکے۔
• ہونا چاہیے: تباہ کن کارروائیوں (اکاؤنٹ حذف، پروجیکٹ حذف) کے لیے تصدیق مانگی جائے، اور ایک "سافٹ ڈیلیٹ" پر غور کریں جو کچھ عرصے کے لیے واپس ہو سکے۔
• بعد میں: ایک بار واقعی بحالی کی جانچ کریں۔ جو بیک اپ کبھی بحال نہیں کیا گیا وہ منصوبہ نہیں، امید ہے۔

9. لانچ سے پہلے

• ضروری: لائیو سائٹ ہر جگہ HTTPS استعمال کرے۔
• ضروری: ڈویلپمنٹ کے نمونہ ڈیٹا، ٹیسٹ اکاؤنٹس اور ڈیبگ صفحات ہٹا دیے گئے ہوں۔
• ہونا چاہیے: ایک پرائیویسی پالیسی بتائے کہ آپ کون سا ڈیٹا جمع کرتے ہیں اور کیوں — اگر آپ ذاتی ڈیٹا جمع کرتے ہیں تو کئی جگہوں پر یہ لازمی ہے۔ ایسی سرٹیفیکیشنز (SOC 2، HIPAA) کا دعویٰ نہ کریں جو آپ کے پاس نہیں ہیں۔
• ہونا چاہیے: سیکیورٹی مسائل پر رابطے کا ذریعہ ہو، اور آپ جانتے ہوں کہ ہر کی کو تیزی سے کیسے بدلنا ہے۔

سیکیورٹی کے علاوہ وسیع تر لانچ سے پہلے کی جانچ کے لیے، دیکھیں AI پروٹو ٹائپ کو پروڈکشن تک کیسے لے جائیں۔

کب پیشہ ور کا جائزہ لیں

چیک لسٹ عام غلطیاں پکڑتی ہے؛ یہ ماہر کی جگہ نہیں لیتی۔ اگر آپ کارڈ نمبر ہوسٹڈ چیک آؤٹ کے بجائے خود سنبھالتے ہیں، صحت، مالی یا بچوں کا ڈیٹا محفوظ کرتے ہیں، ایسی کمپنیوں کو بیچتے ہیں جو سیکیورٹی سوالنامے مانگتی ہیں، یا لیک سے سنگین نقصان اٹھا سکتے ہیں، تو جائزے کے لیے ادائیگی پر غور کریں۔ آپ کے کوڈ کا ایکسپورٹ کے قابل ہونا اس جائزے کو بہت آسان بناتا ہے۔

Mythex پر بناتے ہوئے سیکیورٹی

Mythex میں سیکیورٹی اسکین کا پینل شامل نہیں ہے، اس لیے اوپر کی چیک لسٹ ہی وہ عمل ہے جس پر چلنا ہے۔ کچھ چیزیں مدد کرتی ہیں:

• پروجیکٹ کے سیکریٹس۔ کیز پروجیکٹ سیٹنگز → Secrets کے تحت محفوظ کریں، یا ایجنٹ جو سیکریٹ کارڈ چیٹ میں دکھاتا ہے اس کے ذریعے، تاکہ وہ آپ کے کوڈ اور پیغامات سے باہر رہیں۔ لائیو ایپ کے لیے سیکریٹ بدلنے کے بعد دوبارہ شائع کریں۔
• Plan اور Ask موڈز۔ ایجنٹ سے بغیر ترمیم کے اجازتوں کا جائزہ لینے کو کہیں: "Ask موڈ میں ہر API روٹ اور وہ اجازت کی کون سی جانچ کرتا ہے، فہرست بنائیں۔"
• /test ایجنٹ کو آپ کے پریویو میں صارف کی طرح کلک کرواتا ہے — سیکشن 2 کے دو اکاؤنٹس والے ٹیسٹ کے لیے مفید ہے۔
• Checkpoints آپ کو وہ تبدیلی واپس لانے دیتے ہیں جو کچھ توڑ دے۔

دستاویزات میں آپ کی بنائی ہوئی ایپس کے لیے سیکیورٹی اور ماحولیاتی متغیرات اور سیکریٹس دیکھیں۔ اگر آپ اگلے مرحلے میں صارف اکاؤنٹس شامل کر رہے ہیں تو اپنی ایپ میں لاگ ان کیسے شامل کریں پڑھیں۔

سوالات