AI দিয়ে বানানো অ্যাপের নিরাপত্তা চেকলিস্ট: লঞ্চের আগে যা যাচাই করবেন

একটি AI দিয়ে বানানো অ্যাপ প্রকৃত মানুষ ব্যবহার করার আগে সাতটি জিনিস যাচাই করুন: প্রতিটি পাতা ও API দেখে নেয় ব্যবহারকারী কে এবং তিনি কী করতে পারেন; গোপন কী সার্ভারে থাকে, কখনো ব্রাউজার বা চ্যাটে নয়; সব ইনপুট সার্ভারে যাচাই হয়; প্রতিটি ব্যবহারকারী শুধু নিজের রেকর্ড পর্যন্ত পৌঁছাতে পারেন; লগ-ইন ও ব্যয়বহুল এন্ডপয়েন্টে রেট লিমিট থাকে; ডিপেন্ডেন্সি আপ টু ডেট থাকে; এবং কিছু ভুল হলে আপনি ডেটা ফিরিয়ে আনতে পারেন। নিচের চেকলিস্ট এর প্রতিটিকে এমন নির্দিষ্ট পরীক্ষায় রূপ দেয় যা কোড না পড়েই চালানো যায়।

AI অ্যাপ বিল্ডার কাজ ঠিকভাবে চালাতে ভালো। তারা স্বয়ংক্রিয়ভাবে সাবধানী হয় না, কারণ “সাবধানতা” প্রম্পটে খুব কমই থাকে। নিচের বেশিরভাগ সমস্যা এমন জিনিস থেকে আসে যা কেউ চায়নি, তাই সমাধান সাধারণত হলো জিজ্ঞেস করা।

এই চেকলিস্ট কীভাবে ব্যবহার করবেন

ক্রম অনুযায়ী এগোন, এবং প্রতিটি আইটেমের জন্য দুটি কাজ করুন: AI-কে জিজ্ঞেস করুন যেন বিষয়টি সামলানো হয়, এবং নিজে পরীক্ষা করুন। AI একটি অনুমতি যাচাই লিখতে পারে; এটি কাজ করে কিনা তা শুধু পরীক্ষাই বলে। আইটেমগুলো চিহ্নিত:

• অবশ্যই — কেউ অ্যাপ ব্যবহার করার আগে এটি করুন।
• উচিত — প্রকৃত ব্যবহারকারী বা প্রকৃত ডেটা আসার আগে এটি করুন।
• পরে — অ্যাপ বড় হওয়ার সঙ্গে সঙ্গে করার মতো।

আপনার যদি মাত্র এক ঘণ্টা থাকে, তবে সব অবশ্যই আইটেম করুন।

১. প্রমাণীকরণ: এ কে?

প্রমাণীকরণ মানে কেউ আসলে কে তা নিশ্চিত করা, সাধারণত লগ-ইন। মূল বিষয়গুলোর জন্য প্রমাণীকরণ কী এবং বিকল্পগুলোর জন্য আপনার অ্যাপে লগ-ইন কীভাবে যোগ করবেন দেখুন।

• অবশ্যই: ব্যক্তিগত ডেটা দেখায় এমন প্রতিটি পাতার জন্য লগ-ইন লাগে। পরীক্ষা: লগ আউট করুন, তারপর একটি ব্যক্তিগত পাতার URL সরাসরি ব্রাউজারে পেস্ট করুন।
• অবশ্যই: ওই পাতাগুলোর পেছনের প্রতিটি API এন্ডপয়েন্টেরও লগ-ইন লাগে, শুধু পাতার নয়। পরীক্ষা: লগ আউট করুন, ব্রাউজারের নেটওয়ার্ক ট্যাব খুলুন, এবং লগ-ইন অবস্থায় অ্যাপ যে অনুরোধ করেছিল তা আবার চালান।
• অবশ্যই: পাসওয়ার্ড ধীর একটি পাসওয়ার্ড-হ্যাশিং অ্যালগরিদম দিয়ে হ্যাশ করে সংরক্ষিত হয়, কখনো সাদা টেক্সটে নয়। OWASP-এর পাসওয়ার্ড সংরক্ষণের নির্দেশিকা প্রথমে Argon2id সুপারিশ করে, বিকল্প হিসেবে scrypt, bcrypt বা PBKDF2। জিজ্ঞেস করুন: “পাসওয়ার্ড কীভাবে সংরক্ষিত হয়?”
• উচিত: পাসওয়ার্ড রিসেট লিংকের মেয়াদ শেষ হয় এবং একবারই কাজ করে।
• উচিত: সেশন কুকি Secure, HttpOnly ও SameSite চিহ্নিত, এবং লগ আউট করলে সার্ভারেও সেশন শেষ হয়।
• পরে: দুই-ফ্যাক্টর প্রমাণীকরণ দিন, অথবা এটি আছে এমন প্রোভাইডারের মাধ্যমে সাইন-ইন দিন।

ব্যবহারকারীর ডেটা ফেরত দেয় এমন প্রতিটি API রুট ও পাতা যাচাই করুন। প্রতিটি লগ-ইন না করা ব্যবহারকারীর অনুরোধ প্রত্যাখ্যান করা উচিত, সার্ভারে, শুধু পাতার কোডে নয়। আপনি যে রুটগুলো যাচাই করেছেন তার তালিকা দিন।

২. অনুমোদন: তারা কী করতে পারে?

অনুমোদন হলো লগ-ইনের পরের ধাপ: এই নির্দিষ্ট ব্যবহারকারী কী দেখতে বা বদলাতে পারেন তা ঠিক করা। AI-তে বানানো অ্যাপে গুরুতর ফাঁক সবচেয়ে বেশি এখানেই থাকে, কারণ অ্যাপটি ঠিক দেখায়: প্রতিটি ব্যবহারকারীর ড্যাশবোর্ডে শুধু তাদের নিজস্ব ডেটা আসে, অথচ কেউ সরাসরি চাইলে সার্ভার যেকোনো ব্যবহারকারীর ডেটা দিয়ে দেয়।

• অবশ্যই: প্রতিটি পড়া, হালনাগাদ ও মোছার সময় সার্ভারে যাচাই হয় যে রেকর্ডটি বর্তমান ব্যবহারকারীর (বা তার দলের) কিনা।
• অবশ্যই: পরীক্ষা করুন: দুটি অ্যাকাউন্ট তৈরি করুন, A ও B। A হিসেবে A-এর একটি রেকর্ড খুলুন এবং URL বা নেটওয়ার্ক অনুরোধে ID লক্ষ্য করুন। B হিসেবে লগ-ইন করে সেই একই ID অনুরোধ করুন। B-কে একটি ত্রুটি পেতে হবে, A-এর ডেটা নয়।
• অবশ্যই: অ্যাডমিন পাতা ও অ্যাডমিন API এন্ডপয়েন্ট সার্ভারে ব্যবহারকারীর ভূমিকা যাচাই করে। অ্যাডমিন লিংক লুকিয়ে রাখা সুরক্ষা নয়।
• অবশ্যই: ব্যবহারকারী অনুরোধ বদলে নিজের ভূমিকা, দাম, ব্যালেন্স বা মালিকানার ফিল্ড বদলাতে পারবেন না। পরীক্ষা: নেটওয়ার্ক ট্যাবে দেখুন একটি প্রোফাইল আপডেট কী পাঠায়। যদি তাতে role বা isAdmin এর মতো ফিল্ড থাকে, AI-কে বলুন ক্লায়েন্ট থেকে সেগুলো উপেক্ষা করতে।
• উচিত: URL-এর ID অনুমান করা কঠিন (1, 2, 3-এর বদলে র্যান্ডম ID)। এটি অনুমোদন যাচাইয়ের বিকল্প নয়, তবে যাচাই না থাকলে ক্ষতি সীমিত করে।

প্রতিটি এন্ডপয়েন্ট যা কোনো রেকর্ড পড়ে বা বদলায়, সার্ভারে যাচাই করুন যে লগ-ইন করা ব্যবহারকারী সেটির মালিক বা অ্যাক্সেস করার অনুমতিপ্রাপ্ত। না হলে 404 ফেরত দিন। তারপর দেখান কীভাবে দুটি অ্যাকাউন্ট দিয়ে এটি পরীক্ষা করবেন।

৩. ডেটাবেসে সারি-স্তরের অ্যাক্সেস

“সারি-স্তরের অ্যাক্সেস” মানে টেবিলের প্রতিটি সারি (একটি বুকিং, একটি ইনভয়েস) শুধু তার সঙ্গে সম্পর্কিত ব্যবহারকারীদের কাছে দৃশ্যমান। এটি বাস্তবায়নের দুটি সাধারণ উপায় আছে:

দুটোই ভালোভাবে করা যায়। যা গুরুত্বপূর্ণ:

• অবশ্যই: ব্রাউজার যদি সরাসরি ডেটাবেসের সঙ্গে কথা বলে (কিছু হোস্টেড ডেটাবেস পণ্য এটি দেয়), প্রতিটি টেবিলে সারি-স্তরের নিয়ম চালু থাকতে হবে। না থাকলে পাবলিক কী থাকা যে কেউ পুরো টেবিল পড়তে পারবে।
• অবশ্যই: কোয়েরি বর্তমান ব্যবহারকারী বা দল দিয়ে ফিল্টার হয়, ব্রাউজারের পাঠানো ID দিয়ে নয়।
• উচিত: শেয়ার করা ডেটার (একটি দলের প্রজেক্ট) একটি স্পষ্ট নিয়ম থাকে যে দলে কে আছেন, এবং সেটি একটি জায়গায় বলবৎ হয়।

৪. সিক্রেট ও API কী

API কী একটি সেবার জন্য পাসওয়ার্ডের মতো। Stripe, ইমেইল ও AI প্রোভাইডার সবাই এটি ব্যবহার করে। পটভূমির জন্য দেখুন এনভায়রনমেন্ট ভেরিয়েবল ও সিক্রেট কী।

• অবশ্যই: কী প্রজেক্টের এনভায়রনমেন্ট ভেরিয়েবল বা সিক্রেটে সংরক্ষিত হয়, কোডে কখনো লেখা হয় না।
• অবশ্যই: যে কী টাকা খরচ করতে পারে বা ব্যক্তিগত ডেটা পড়তে পারে, তা শুধু সার্ভারে ব্যবহৃত হয়। পরীক্ষা: আপনার লাইভ সাইট খুলুন, ডেভট্যুলসে পেজ সোর্স ও JavaScript ফাইল দেখুন, এবং আপনার কীয়ের শুরুর অংশ খুঁজুন (যেমন sk_)। সেটি সেখানে থাকা উচিত নয়।
• অবশ্যই: কী কখনো চ্যাটে, পাবলিক রিপোজিটরিতে বা স্ক্রিনশটে পেস্ট হয়নি। হয়ে থাকলে এটি রোটেট করুন প্রোভাইডারে (নতুন একটি তৈরি করুন, পুরনোটি মুছে দিন)।
• উচিত: প্রোভাইডার সমর্থন করলে সীমিত বা স্কোপড কী ব্যবহার করুন। উদাহরণস্বরূপ Stripe সেই সীমিত কী সুপারিশ করে যাদের শুধু আপনার ইন্টিগ্রেশনের প্রয়োজনীয় অনুমতি আছে।
• উচিত: টেস্ট ও লাইভ কী আলাদা, এবং লাইভ অ্যাপ লাইভ কী ব্যবহার করে শুধু যখন আপনি প্রস্তুত।

কিছু কী ইচ্ছাকৃতভাবে পাবলিক হওয়ার জন্য তৈরি — Stripe-এর পাবলিশেবল কী (pk_…) বা শুধু আপনার ডোমেইনে সীমাবদ্ধ একটি ম্যাপ কী। নিয়মটি শক্তি দেয় এমন কীয়ের জন্য, কী-এর মতো দেখতে প্রতিটি স্ট্রিংয়ের জন্য নয়।

৫. ইনপুট যাচাই

ব্যবহারকারী যা পাঠায় — ফর্মের ফিল্ড, ফাইল আপলোড, URL প্যারামিটার — তা যা খুশি হতে পারে, শুধু আপনার ফর্ম যা অনুমতি দেয় তা নয়।

• অবশ্যই: যাচাই সার্ভারে হয়, শুধু ব্রাউজারে নয়। ব্রাউজারের পরীক্ষা সুবিধার জন্য; যে কেউ তা এড়িয়ে যেতে পারে।
• অবশ্যই: ডেটাবেস কোয়েরিতে প্যারামিটার ব্যবহৃত হয়, ব্যবহারকারীর ইনপুট থেকে জোড়া দেওয়া টেক্সট নয় (এটি SQL injection ঠেকায়)। AI-কে নিশ্চিত করতে বলুন।
• অবশ্যই: ব্যবহারকারীর লেখা টেক্সট টেক্সট হিসেবে দেখানো হয়, HTML হিসেবে চালানো হয় না। পরীক্ষা: আপনার নাম হিসেবে <b>hello</b> লিখুন। আপনি ট্যাগগুলো দেখবেন, বোল্ড টেক্সট নয়।
• উচিত: ফাইল আপলোড টাইপ ও আকার যাচাই করে, এবং আপলোড করা ফাইল আপনার অ্যাপের মূল ডোমেইন থেকে চালানো যোগ্য পাতা হিসেবে পরিবেশন হয় না।
• উচিত: ব্যবহারকারীদের দেখানো ত্রুটি সরল হয় (“কিছু একটা ভুল হয়েছে”); বিস্তারিত ত্রুটি শুধু সার্ভার লগে যায়।
• উচিত: Stripe-এর মতো সেবার ওয়েবহুক কাজ করার আগে প্রোভাইডারের স্বাক্ষর যাচাই করে। দেখুন ওয়েবহুক কী।

প্রতিটি ফর্ম ও API এন্ডপয়েন্টে সার্ভার-সাইড যাচাই যোগ করুন: প্রয়োজনীয় ফিল্ড, দৈর্ঘ্য, ফরম্যাট ও অনুমোদিত মান। বাকিগুলো স্পষ্ট বার্তা দিয়ে প্রত্যাখ্যান করুন। ব্যবহারকারীদের অভ্যন্তরীণ ত্রুটির বিবরণ দেখাবেন না।

৬. রেট লিমিট ও অপব্যবহার

রেট লিমিট একটি সময়কালে কেউ কতগুলো অনুরোধ করতে পারবেন তা সীমিত করে। এটি না থাকলে যে কেউ সারাদিন পাসওয়ার্ড অনুমান করতে পারে, আপনার সাইনআপ ফর্মে বন্যা বইয়ে দিতে পারে, বা একটি পেইড API-তে আপনার বিল বাড়িয়ে দিতে পারে।

• অবশ্যই: লগ-ইন, সাইনআপ ও পাসওয়ার্ড রিসেট প্রতি IP ঠিকানা ও প্রতি অ্যাকাউন্টে রেট-সীমিত।
• অবশ্যই: প্রতিটি কলে যা আপনার টাকা খরচ করে — AI মডেল অনুরোধ, SMS, ইমেইল — তার প্রতি-ব্যবহারকারী সীমা আছে এবং লগ-ইন লাগে।
• উচিত: পাবলিক ফর্মে (যোগাযোগ, ওয়েটলিস্ট) স্প্যাম সুরক্ষা আছে: একটি রেট লিমিট, একটি লুকানো হানিপট ফিল্ড, বা একটি CAPTCHA।
• উচিত: আপনার পেইড প্রোভাইডারগুলোতে খরচের সীমা বা সতর্কতা সেট করুন, যাতে কোনো বাগ বা আক্রমণকারী সীমাহীন বিল তৈরি করতে না পারে।

৭. ডিপেন্ডেন্সি

অ্যাপগুলো ওপেন-সোর্স প্যাকেজ দিয়ে বানানো হয়, এবং প্যাকেজে মাঝে মাঝে পরিচিত দুর্বলতা থাকে।

• উচিত: AI-কে পরিচিত দুর্বলতা যাচাই করতে বলুন (JavaScript প্রজেক্টের জন্য npm audit বা আপনার প্যাকেজ ম্যানেজারের সমতুল্য) এবং যা প্রভাবিত তা হালনাগাদ করুন।
• উচিত: অ্যাপ আর ব্যবহার করে না এমন প্যাকেজ সরান।
• উচিত: খুব কম ব্যবহারকারী আছে এমন প্যাকেজ বা জনপ্রিয় প্যাকেজের বানান ভুলের মতো নামের প্যাকেজ নিয়ে সতর্ক থাকুন।
• পরে: প্রতি এক-দুই মাসে আবার যাচাই করুন, বা আপনার কোড GitHub-এ থাকলে স্বয়ংক্রিয় সতর্কতা চালু করুন।

৮. ব্যাকআপ ও পুনরুদ্ধার

নিরাপত্তার মধ্যে ভুল থেকে পুনরুদ্ধার করার ক্ষমতাও অন্তর্ভুক্ত — আপনার, AI-এর বা কোনো আক্রমণকারীর ভুল।

• অবশ্যই: আপনার ডেটা কোথায় থাকে এবং সেটির ব্যাকআপ হয় কিনা জানুন। ধরে নেবেন না; আপনার হোস্টের ডকুমেন্টেশন দেখুন।
• উচিত: গুরুত্বপূর্ণ ডেটার নিজস্ব নিয়মিত এক্সপোর্ট রাখুন (যেমন CSV এক্সপোর্ট ফিচার বা ডেটাবেস ডাম্প), আলাদা একটি জায়গায়।
• উচিত: আপনার কোড ভার্সন কন্ট্রোলে রাখুন, যাতে যেকোনো সংস্করণ ফিরিয়ে আনা যায়।
• উচিত: ধ্বংসাত্মক কাজ (অ্যাকাউন্ট মোছা, প্রজেক্ট মোছা) নিশ্চিতকরণ চায়, এবং একটি “সফট ডিলিট” বিবেচনা করুন যা কিছু সময়ের জন্য ফেরানো যায়।
• পরে: একবার আসলে পুনরুদ্ধার পরীক্ষা করুন। যে ব্যাকআপ কখনো পুনরুদ্ধার করা হয়নি, তা একটি আশা, পরিকল্পনা নয়।

৯. লঞ্চের আগে

• অবশ্যই: লাইভ সাইট সবখানে HTTPS ব্যবহার করে।
• অবশ্যই: ডেভেলপমেন্টের নমুনা ডেটা, টেস্ট অ্যাকাউন্ট ও ডিবাগ পাতা সরানো হয়েছে।
• উচিত: একটি গোপনীয়তা নীতি বলে কী ডেটা সংগ্রহ করেন এবং কেন — ব্যক্তিগত ডেটা সংগ্রহ করলে অনেক জায়গায় এটি বাধ্যতামূলক। আপনার কাছে নেই এমন সার্টিফিকেশন (SOC 2, HIPAA) দাবি করবেন না।
• উচিত: নিরাপত্তা সমস্যা নিয়ে যোগাযোগের একটি উপায় আছে, এবং আপনি দ্রুত প্রতিটি কী রোটেট করতে জানেন।

নিরাপত্তার বাইরে বৃহত্তর প্রাক-লঞ্চ পর্যালোচনার জন্য দেখুন কীভাবে একটি AI প্রোটোটাইপ প্রোডাকশনে নেবেন।

কখন পেশাদার পর্যালোচনা নেবেন

একটি চেকলিস্ট সাধারণ ভুল ধরে, কিন্তু একজন বিশেষজ্ঞের বিকল্প নয়। আপনি যদি কার্ড নম্বর নিজে প্রক্রিয়া করেন (হোস্টেড চেকআউটের বদলে), স্বাস্থ্য, আর্থিক বা শিশুদের ডেটা সংরক্ষণ করেন, নিরাপত্তা প্রশ্নাবলি চায় এমন কোম্পানির কাছে বিক্রি করেন, অথবা ফাঁস হলে গুরুতরভাবে ক্ষতিগ্রস্ত হতে পারেন, তবে পর্যালোচনার জন্য অর্থ দেওয়া বিবেচনা করুন। আপনার কোড রপ্তানি করা যাওয়া থাকলে সেই পর্যালোচনা অনেক সহজ হয়।

Mythex-এ বানানোর সময় নিরাপত্তা

Mythex-এ নিরাপত্তা-স্ক্যানের কোনো প্যানেল নেই, তাই উপরের চেকলিস্টই অনুসরণ করার প্রক্রিয়া। কিছু বিষয় সাহায্য করে:

• প্রজেক্ট সিক্রেট। প্রজেক্ট সেটিংস → Secrets-এ কী রাখুন, অথবা এজেন্ট চ্যাটে যে সিক্রেট কার্ড দেখায় তার মাধ্যমে, যাতে সেগুলো আপনার কোড ও বার্তার বাইরে থাকে। লাইভ অ্যাপের জন্য কোনো সিক্রেট বদলালে আবার প্রকাশ করুন।
• Plan ও Ask মোড। এজেন্টকে সম্পাদনা না করে অনুমতি পর্যালোচনা করতে বলুন: “Ask মোডে প্রতিটি API রুট ও সেটি কী অনুমতি যাচাই করে তার তালিকা করো।”
• /test এজেন্টকে আপনার প্রিভিউতে একজন ব্যবহারকারী হিসেবে ক্লিক করে ঘোরায় — সেকশন ২-এর দুই-অ্যাকাউন্ট পরীক্ষার জন্য কাজে লাগে।
• চেকপয়েন্ট আপনাকে এমন একটি পরিবর্তন ফিরিয়ে নিতে দেয় যা কিছু ভেঙেছে।

দেখুন আপনার বানানো অ্যাপের নিরাপত্তা ও এনভায়রনমেন্ট ভেরিয়েবল ও সিক্রেট ডকুমেন্টেশনে। আপনি যদি এরপর ব্যবহারকারী অ্যাকাউন্ট যোগ করতে যাচ্ছেন, আপনার অ্যাপে লগ-ইন কীভাবে যোগ করবেন পড়ুন।

প্রশ্নোত্তর