Claude Code নিরাপত্তা চেকলিস্ট — দ্রুত ওয়েব অ্যাপ স্পট-চেকের জন্য

হালকা ওজনের নিরাপত্তা স্পট-চেক কী

হালকা ওজনের (lightweight) নিরাপত্তা স্পট-চেক হলো দ্রুত একটি রিভিউ (সাধারণত ৩০–৬০ মিনিট) যার লক্ষ্য চালান প্রদানের আগে স্পষ্ট, উচ্চ-প্রভাব বিষয়গুলো ধরানো। এটা একটি সম্পূর্ণ অডিট নয়। একে ভাবুন নিরাপত্তা ওয়াক-থ্রুর মতো: আপনি সেই পথগুলো স্ক্যান করেন যেগুলো বাস্তব অ্যাপগুলোতে সবচেয়ে বেশি সমস্যা দেয় এবং অনুমানের বদলে প্রমাণ খুঁজেন।

এই Claude Code নিরাপত্তা চেকলিস্টটি প্রতিদিনের ওয়েব অ্যাপগুলিতে সবচেয়ে বেশি ভেঙে পড়া ক্ষেত্রগুলোর উপর ফোকাস করে:

• Authentication (আপনি কিভাবে জানেন ব্যবহারকারী কে) নিয়ে অনুমান
• Authorization গ্যাপ (তারা কী করতে পারে)
• ইনপুট ভ্যালিডেশন
• সিক্রেট হ্যান্ডলিং
• সাধারণ ইনজেকশন সারফেস (SQL, কমান্ড এক্সিকিউশন, টেমপ্লেট রেন্ডারিং, রিডিরেক্ট, আপলোড)

এটি বাগের অনুপস্থিতি প্রমাণ করার চেষ্টা করে না, জটিল থ্রেট অ্যাক্টরদের মডেল করে না, এবং penetration testing-এর বিকল্প নয়।

“কংক্রিট ফাইন্ডিং” মানে প্রতিটি ইস্যুতে এমন প্রমাণ থাকবে যাতে ডেভেলপার তা তৎক্ষণাৎ কাজ করতে পারে। প্রতিটি ফাইন্ডিংয়ের জন্য নিনদিষ্ট করুন:

• সঠিক ফাইল(গুলি) এবং ফাংশন/হ্যান্ডলার নাম
• ঝুঁকিপূর্ণ আচরণ এক বাক্যে
• একটি নূন্যতম repro ধাপ (রিকোয়েস্ট, পেলোড, বা ক্লিক পথ)
• কেন এটা গুরুত্বপূর্ণ (ইমপ্যাক্ট) এবং কে এটি ট্রিগার করতে পারে
• একটি নিরাপদ ফিক্স দিকনির্দেশনা (পুরো রিরাইট নয়)

AI একটি সহায়ক, কর্তৃত্ব নয়। এটাকে সার্চ, সারমাইজ এবং টেস্ট প্রস্তাব করতে ব্যবহার করুন। তারপর কোড পড়ে যাচাই করুন এবং সম্ভব হলে আসল রিকোয়েস্ট দিয়ে পুনরুৎপাদন করুন। যদি মডেল সুনির্দিষ্ট লোকেশন ও ধাপ দেখাতে না পারে, সেই দাবিকে প্রমাণহীন হিসেবে বিবেচনা করুন।

১০ মিনিটে স্কোপ নির্ধারণ করুন

একটি দ্রুত রিভিউ তখনই কাজ করে যখন আপনি লক্ষ্যটি সংকীর্ণ করেন। Claude Code-কে কিছু দেখানোর আগে ঠিক করুন আজ আপনি কি প্রমাণ করতে চাইছেন এবং কি যাচাই করছেন না।

১ থেকে ৩টি বাস্তব ইউজার জার্নি দিয়ে শুরু করুন যেখানে ভুল হলে অর্থ ক্ষতি, ডেটা প্রকাশ বা ক্ষমতা দেয়ার ঝুঁকি থাকে। ভালো ক্যান্ডিডেট: লগইন, পাসওয়ার্ড রিসেট, চেকআউট, এবং অ্যাডমিন এডিট স্ক্রিন।

এরপর সেই অ্যাসেটগুলো নাম করুন যেগুলো আপনাকে রক্ষা করতে হবে। নির্দিষ্ট থাকুন: ইউজার অ্যাকাউন্ট, পেমেন্ট অ্যাকশন, পার্সোনাল ডাটা, অ্যাডমিন-ওনলি অপারেশন।

তারপর সাধারণ ভাষায় আপনার থ্রেট অনুমানগুলো লিখে রাখুন। আপনি কি কৌতূহলী ব্যবহারকারী, বাইরের স্ক্রিপ্ট চালানো আক্রমণকারী, নাকি কিছু অ্যাক্সেস থাকা ইনসাইডার থেকে প্রতিরক্ষা করছেন? আপনার উত্তর “ভালো পর্যাপ্ত” কেমন হয় সেটা বদলে দেবে।

শেষে, পাস এবং ফেইল সংজ্ঞায়িত করুন যাতে স্পট-চেক ফাইন্ডিং দিয়ে শেষ হয়, আবেগ দিয়ে নয়। সহজ নিয়মগুলি ভালো কাজ করে:

• পাস: প্রতিটি সংবেদনশীল অ্যাকশনে স্পষ্ট authn এবং authz চেক আছে।
• ফেইল: কোনো এন্ডপয়েন্ট ক্লায়েন্টের কাছেই ইউজার আইডি বা রোল ট্রাস্ট করছে।
• পাস: ইনপুট সার্ভার-সাইডে ভ্যালিডেট করা হয়, কেবল UI-তে নয়।
• ফেইল: সিক্রেট লগ, কনফিগ বা ক্লায়েন্ট কোডে দেখা যায়।

যদি আপনি ব্যর্থতার পরিচিতি বর্ণনা করতে না পারেন, স্কোপ এখনও অস্পষ্ট।

Claude Code-কে যে কনটেক্সট দেবেন তা প্রস্তুত করুন

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

শুরু করুন সিকিউরিটি-ক্রিটিকাল পথ শেয়ার করে: রিকোয়েস্ট এন্ট্রি পয়েন্ট এবং সেই কোড যা নির্ধারণ করে ব্যবহারকারী কে এবং তারা কী করতে পারে। ডেটা কিভাবে প্রবাহিত হয় তা দেখাতে চারপাশের ছোট অংশ যোগ করুন।

একটি ব্যবহারিক বাণ্ডিলে সাধারণত থাকে:

• Auth এন্ট্রি: সেশন/JWT পার্সিং, কুকি সেটিংস, লগইন কলব্যাক, auth middleware
• Routes + handlers: কন্ট্রোলার, RPC মেথড, GraphQL রেজলভার, ব্যাকগ্রাউন্ড জব হ্যান্ডলার
• ডাটা লেয়ার: ORM কুয়েরি, রো SQL হেলপার, কুয়েরি বিল্ডার, সংবেদনশীল টেবিলের মাইগ্রেশন
• পলিসি চেক: রোল চেক, মালিকানা চেক, ফিচার ফ্ল্যাগ, অ্যাডমিন-ওনলি এন্ডপয়েন্ট
• ভ্যালিডেশন: রিকোয়েস্ট স্কিমা ভ্যালিডেটর, ফাইল আপলোড হ্যান্ডলার, ডেসেরিয়ালাইজেশন কোড

কিছু লাইন এনভায়রনমেন্ট নোট যোগ করুন যাতে অনুমানগুলো স্পষ্ট হয়: সেশন বনাম JWT, টোকেন কোথায় থাকে (কুকি না হেডার), রিভার্স প্রক্সি বা API গেটওয়ের আচরণ, কিউ/ক্রন ওয়ার্কার, এবং কোনো “ইন্টারনাল-ওনলি” এন্ডপয়েন্ট থাকলে তা।

বাগ খোঁজার আগেই, একটি ইনভেন্টরি চাইুন: এন্ট্রি পয়েন্ট, প্রিভিলেজড এন্ডপয়েন্ট, এবং ডাটা স্টোরস কোনগুলো টাচ করে। এটি মিসড সারফেসগুলো আটকায়।

একটি আউটপুট ফরম্যাটে সম্মত হোন যা কংক্রিট ফাইন্ডিং জোর দেয়। একটি সাদামাটা টেবিল ঠিক কাজ করে: Finding, Severity, Affected endpoint/file, Evidence (নির্দিষ্ট স্নিপেট বা লাইন রেঞ্জ), Exploit scenario, Fix suggestion.

৩০–৬০ মিনিট রিভিউয়ের স্টেপ-বাই-স্টেপ ওয়ার্কফ্লো

টাইমবক্স করুন:

• ১০ মিনিট ওরিয়েন্ট করতে
• ১৫–৩০ মিনিট ফ্লো ট্রেস করতে
• ১০ মিনিট লিখে সাজাতে

লক্ষ্য পারফেক্ট কভারেজ নয়। এটি টেস্টেবল ফাইন্ডিংগুলোর একটি ছোট সেট পেতে।

আপনি পড়ার সময় অ্যাপ খুলে রাখুন। UI ক্লিক করে দেখুন কোন অনুরোধগুলো ফায়ার হচ্ছে। নোটগুলো নির্দিষ্ট এন্ডপয়েন্ট, প্যারামিটার এবং ডাটা সোর্স দেখাবে।

একটি ওয়ার্কফ্লো যা এক বসায় হয়:

1. এন্ট্রি পয়েন্ট এবং ট্রাস্ট বাউন্ডারি স্কেচ করুন। পাবলিক রুট, লগ-ইন রুট, অ্যাডমিন রুট, ওয়েবহুক, আপলোড, এবং তৃতীয় পক্ষ কলব্যাক নোট করুন। যেখানে ডাটা ইউজার-কন্ট্রোলড থেকে সার্ভার-ট্রাস্টেড হয় সেই জায়গাগুলো মার্ক করুন।
2. প্রতিটি গুরুত্বপূর্ণ এন্ডপয়েন্টের জন্য লিখে রাখুন কি কি পরিচয় প্রমাণ করে এবং কোথায় হয়। যদি চেকটি “মিডলওয়্যার” হয়, নিশ্চিত করুন প্রতিটি রুট সত্যিই তা ব্যবহার করে।
3. অথরাইজেশনেও একই কাজ করুন। একটি ঝুঁকিপূর্ণ অ্যাকশন (অন্যদের ডেটা দেখা, রোল আপডেট, এক্সপোর্ট, ডিলিট) বেছে নিন এবং পারমিশন ডিসিশনটি ডাটাবেস কুয়েরি পর্যন্ত ট্রেস করুন।
4. ইনপুটকে সিঙ্কে পাঠান। একটা প্যারামিটারকে রিকোয়েস্ট থেকে SQL/ORM কুয়েরি, টেমপ্লেট রেন্ডারিং, কমান্ড এক্সিকিউশন, URL ফেচ (SSRF), রিডিরেক্ট, এবং ফাইল পাথ পর্যন্ত অনুসরণ করুন।
5. ট্রেস করার সময় সিক্রেট ও কনফিগ স্ক্যান করুন। লগে টোকেন, ক্লায়েন্ট সাইড কোড, এরর মেসেজ, এনভায়রনমেন্ট ডাম্প কোথায় পড়ে দেখুন এবং দুর্বল স্টোরেজ প্যাটার্ন অনুসন্ধান করুন।

একটি কার্যকর অভ্যাস: প্রতিটি “ঠিকই লাগছে” জন্য লিখে রাখুন আপনি কিভাবে ভাঙবেন। যদি আপনি ভাঙার চেষ্টা বর্ণনা না করতে পারেন, সম্ভবত ভালভাবে যাচাই করেননি।

Authn স্পট-চেক: প্রমাণ করুন ব্যবহারকারী কে

Authentication সেই জায়গা যেখানে অ্যাপ সিদ্ধান্ত নেয়, “এই রিকোয়েস্টটি এই ব্যক্তির।” দ্রুত স্পট-চেক সব লাইন পড়ার ব্যাপার নয়। এটা সেই জায়গা খুঁজে বের করার ব্যাপার যেখানে identity তৈরি বা গ্রহণ করা হয়, তারপর শর্টকাট ও failure paths চেক করা।

ট্রাস্ট বাউন্ডারি লোকেট করুন: পরিচয় প্রথম কোথায় তৈরি বা গ্রহণ হয়? এটি হতে পারে সেশন কুকি, JWT বিয়ারার টোকেন, API কী, বা এজে mTLS। Claude Code-কে বলুন সঠিক ফাইল ও ফাংশন দেখাতে যেই "anonymous" কে user id এ বদলে দেয়, এবং সব অন্য পথ গুলো তালিকাভুক্ত করতে।

Authn চেকগুলো যা স্ক্যান করা উচিত:

• সব auth এন্ট্রি পয়েন্ট চিহ্নিত করুন (ওয়েব লগইন, API টোকেন, মোবাইল অথ, ইন্টারনাল সার্ভিস অথ) এবং নিশ্চিত করুন এগুলো একটি সঙ্গত identity মডেলে কনভার্জ করে।
• লগইন ও পাসওয়ার্ড রিসেটের জন্য রেট লিমিট, লকআউট, এবং ইউজার এনারুমারেশন (ভিন্ন এরর মেসেজ বা টাইমিং) চেক করুন।
• সেশন ও কুকি পর্যালোচনা: HttpOnly, Secure, SameSite, মেয়াদ, লগইনের সময় বা প্রিভিলেজ পরিবর্তনের সময় রোটেশন, এবং লগআউট ইনভ্যালিডেশন (সার্ভার-সাইডে, কেবল “কুকি মোছে ফেলা” নয়)।
• MFA এবং রিকভারি রিভিউ করুন যাতে রিকভারি পথ MFA-র চেয়ে দুর্বল না হয় (উদাহরণ: ইমেইল-অনলি রিসেট যা MFA বাইপাস করে)।
• auth ব্যর্থতা লগিং রিভিউ করুন: অপসের জন্য দরকারী কিন্তু আক্রমণকারীর সহায়তায় তথ্য ফাঁস না করে (কোনো “ইউজার আছে” সূত্র বা টোকেন ডাম্প নয়)।

একটি ব্যবহারিক উদাহরণ: যদি রিসেট ইমেইল "অ্যাকাউন্ট পাওয়া যায়নি" বলে, তাহলে সেটি দ্রুত একটি এনারুমারেশন সমস্যা। এমনকি সাধারণ মেসেজ থাকলেও টাইমিং ডিফারেন্স একই তথ্য ফাঁস করতে পারে, তাই রেসপন্স টাইমিংও চেক করুন।

Authz স্পট-চেক: প্রমাণ করুন ব্যবহারকারী অনুমোদিত

Authorization ভুল হলে সবচেয়ে বেশি ক্ষতি হয়: "এই ব্যবহারকারী কি এই নির্দিষ্ট রিসোর্সে এই কাজটি করার অনুমতি পায়?" দ্রুত স্পট-চেক ইচ্ছাকৃতভাবে সেই অনুমান ভাজার চেষ্টা করা উচিত।

রোল ও পারমিশন সরল ভাষায় লিখুন। মানবীয় রাখুন:

• মালিক পারবে সদস্য আমন্ত্রণ করতে
• সদস্য নিজের প্রোফাইল এডিট করতে পারবে
• সাপোর্ট বিলিং ডিটেইল দেখতে পারবে কিন্তু প্ল্যান বদলাতে পারবে না
• অ্যাডমিন প্রজেক্ট ডিলিট করতে পারবে

তারপর যাচাই করুন প্রতিটি সংবেদনশীল অ্যাকশন সার্ভারে enforced হচ্ছে, কেবল UI-তে নয়। বোতাম লুকানো বা ক্লায়েন্টে রুট ব্লক করা যথেষ্ট নয় — আক্রমণকারী সরাসরি API ডাকে তা খেলিয়ে দিতে পারে।

দ্রুত স্ক্যান যেটা সাধারণত সমস্যাগুলো খুঁজে পায়:

• যে এন্ডপয়েন্ট/মিউটেশনগুলো তৈরি, ডিলিট, এক্সপোর্ট, রোল বদল বা বিলিং অ্যাকসেস করে সেগুলো খুঁজুন
• প্রতিটির জন্য সার্ভার-সাইড পারমিশন চেক লোকেট করুন (ফ্রন্টএন্ড নয়)
• ইউজার-কন্ট্রোলড আইডি (projectId, userId, orgId) আছে কি না দেখুন এবং মালিকানা চেক নিশ্চিত করুন
• অ্যাডমিন-ওনলি পথগুলোতে রোল মিসিং হলে ক্লোজ হওয়া উচিত
• টেন্যান্সি বাউন্ডারি চেক করুন: orgId/accountId সেশন কনটেক্সট থেকে আসছে কি কেবল রিকোয়েস্ট ইনপুট থেকে নয়

ক্লাসিক IDOR গন্ধ সহজ: একটি রিকোয়েস্ট যেমন GET /projects/{id} যেখানে {id} ইউজার-কন্ট্রোলড, এবং সার্ভার এটি লোড করে কিন্তু নিশ্চিত করে না যে এটি বর্তমান ব্যবহারকারীর বা টেন্যান্টের অন্তর্গত।

একটি প্রম্পট যা বাস্তব উত্তর জোর করে:

"এই এন্ডপয়েন্টের জন্য, সঠিক কোড দেখান যা অ্যাক্সেস সিদ্ধান্ত নেয়, এবং তালিকাভুক্ত করুন কোন শর্তগুলো অন্য orgId-র ব্যবহারকারীকে তা অ্যাক্সেস করতে দেবে। যদি না থাকে, ফাইল ও ফাংশন নামসহ কেন ব্যাখ্যা করুন।"

ইনপুট ভ্যালিডেশন: খারাপ ডেটা আগেই আটকান

বেশিরভাগ দ্রুত ওয়েব অ্যাপ সমস্যা শুরু হয় এমন কোনো গ্যাপ থেকে: অ্যাপ এমন ইনপুট গ্রহণ করছে যা ডেভেলপার আশা করেননি। “ইনপুট” মানে কিছুই হতে পারে যা ব্যবহারকারী বা অন্য সিস্টেম প্রভাবিত করতে পারে, এমনকি যদি সেটা ক্ষুদ্র লাগে।

স্পট-চেক করতে শুরু করার আগে এন্ডপয়েন্টের ইনপুটগুলো নাম করুন:

• URL কুয়েরি ও পাথ ভ্যালু
• রিকোয়েস্ট বডির ফিল্ড (নেস্টেড JSON সহ)
• হেডার (অথ হেডার, কনটেন্ট টাইপ, ফরওয়ার্ডেড IP)
• কুকি
• ফাইল আপলোড (নাম, সাইজ, টাইপ, মেটাডাটা)

ভ্যালিডেশন ডেটা অ্যাপ-এ প্রবেশের কাছাকাছি হওয়া উচিত, ব্যবসায়িক লজিকে গভীরে নয়। বেসিকগুলো চেক করুন: টাইপ (স্ট্রিং বনাম সংখ্যা), সর্বোচ্চ দৈর্ঘ্য, প্রয়োজনীয়তা, এবং ফরম্যাট (ইমেইল, UUID, ডেট)।

রোল, স্ট্যাটাস ফিল্ড বা সোর্ট নির্দেশনার মতো পরিচিত মানগুলোর জন্য allowlist ব্যবহার করুন। এটি "কয়েকটি খারাপ মান ব্লক করা" থেকে কঠিন করে দেয় বাইপাস করা।

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

রিস্কি এন্ডপয়েন্টগুলো (লগইন, সার্চ, আপলোড, অ্যাডমিন অ্যাকশন) জন্য দ্রুত "খারাপ ইনপুট" মিনি-প্ল্যান:

• অত্যন্ত দীর্ঘ স্ট্রিং (১০,০০০+ ক্যারেক্টর)
• ভুল টাইপ (অ্যার্রে ইনপ্লেস স্ট্রিং)
• অনাকাঙ্ক্ষিত enum মান
• বিশেষ ক্যারেক্টার যা অর্থ পাল্টে দিতে পারে
• প্রয়োজনীয় ক্ষেত্রগুলোর জন্য খালি মান

উদাহরণ: একটি সোর্ট প্যারামিটার যে কোনো স্ট্রিং নেয় সেটি পরে SQL ফ্রেগমেন্ট হতে পারে। "date" বা "price" এর মতো allowlist এমন ধরনের ভুলগুলো শুরুতেই আটকায়।

দ্রুত স্ক্যান করার মতো সাধারণ ইনজেকশন সারফেস

অধিকাংশ দ্রুত রিভিউ একই কিছু জায়গায় সমস্যা খুঁজে পায়: যেখানে ইনপুটকে কোড, কুয়েরি, পাথ বা URL হিসেবে ইন্টারপ্রেট করা হয়। এই অংশে আপনি “ইনপুট ট্রাস্ট বাউন্ডারি পার হচ্ছে” মুহূর্তগুলো হান্ট করবেন।

এন্ট্রি পয়েন্ট (কুয়েরি প্যারাম, হেডার, কুকি, আপলোড, অ্যাডমিন ফর্ম) থেকে ডাটা যেখানে শেষ হয় সে জায়গা পর্যন্ত ট্রেস করুন।

দ্রুত স্ক্যান টার্গেট

এই প্যাটার্নগুলো খুঁজুন এবং প্রতিটির জন্য একটি কংক্রিট কল সাইট ও পেলোড উদাহরণ চাইুন:

• SQL injection: স্ট্রিং-বিল্ট কুয়েরি, ডাইনামিক ORDER BY, এবং IN (...) বিল্ডারগুলো যা ইউজার মান যোগ করে
• XSS: HTML রেন্ডারিং, টেমপ্লেট, markdown প্রিভিউ, রিচ টেক্সট এডিটর যেখানে "পরে sanitize করা হবে" ধরা হয়েছে
• Command injection: শেল কল চারপাশে ইমেজ প্রসেসিং, PDF টুল, ব্যাকআপ বা "convert" ধাপ যেখানে ইউজার-কন্ট্রোলড ফ্ল্যাগ পাঠানো হয়
• SSRF: URL ফেচার ফিচার (ওয়েবহুক, লিংক প্রিভিউ, URL থেকে ইম্পোর্ট), এবং এমন অভ্যন্তরীণ চেক যা ইউজার URL নেয়
• Path traversal: ফাইল ডাউনলোড এন্ডপয়েন্ট, zip এক্সট্র্যাকশন, এবং আপলোড পাইপলাইন যেখানে পরে ফাইল নাম দিয়ে পড়া হয়

ডেসেরিয়ালাইজেশন ও টেমপ্লেট ইনজেকশনের দিকে ও চকচকে নজর রাখুন। যেকোনো ফিচার যা ইউজার দেওয়া JSON, YAML বা টেমপ্লেট-স্ট্রিং পার্স করে ঝুঁকি লুকাতে পারে, বিশেষত যখন কাস্টম টাইপ বা এক্সপ্রেশন সমর্থন করে।

একটি ফিচার URL, ফাইলনেম বা ফরম্যাট করা টেক্সট নেয়, ধরে নিন এটি কুআব্যবহার করা যেতে পারে যতক্ষণ না আপনি কোড-পথ ও টেস্ট দিয়ে প্রমাণ করেন।

সিক্রেট হ্যান্ডলিং: লিক ও দুর্বল স্টোরেজ খুঁজুন

সিক্রেট সমস্যা বেশ জোরে ভেসে ওঠে যেহেতু আপনি জানেন কোথায় দেখবেন। কোথায় সিক্রেট থাকে এবং কোথায় আকস্মিকভাবে কপি হচ্ছে তাতে ফোকাস করুন।

সিক্রেট সাধারণত কোথাও প্রদশিত হয়:

• এনভায়রনমেন্ট ভ্যারিয়েবল ও অ্যাপ কনফিগ ফাইল
• CI আউটপুট ও বিল্ড লগ (ফেইল্ড ডিপ্লয় লগ সহ)
• ক্লায়েন্ট বান্ডল ও মোবাইল বিল্ড (ইউজারদের কাছে শিপ করা কিছুই)
• ডিবাগ এন্ডপয়েন্ট, হেলথ পেজ, অ্যাডমিন টুল
• এরর পেজ, স্ট্যাক ট্রেস, অ্যানালিটিক্স ইভেন্ট

তাহলে একটি কংক্রিট উত্তর জোর করুন: যদি আজ একটি সিক্রেট ফাঁস হয়, পরের পদক্ষেপ কী? একটি ভাল সিস্টেমে রোটেশন পাথ (নতুন কী ইস্যু), রিভোকেশন (পুরনো কী ডিসেবল), এবং দ্রুত রেডিপ্লয়ের উপায় থাকবে। যদি উত্তর "পরে পরিবর্তন করব" হয়, সেটাকে ফাইন্ডিং হিসেবে নিন।

লিস্ট প্রিভিলেজ একটি দ্রুত উইন। কী অত্যাধিক ক্ষমতাসম্পন্ন হলে ইনসিডেন্ট খারাপ হয়। ডাটাবেস ইউজার যারা টেবিল ড্রপ করতে পারে, তৃতীয়-পক্ষ টোকেন যারা অ্যাকাউন্ট ম্যানেজ করতে পারে, বা পরিবেশে শেয়ার করা API কী দেখুন। পরিষেবাভিত্তিক, পরিবেশভিত্তিক একটি কী এবং ন্যূনতম অনুমতি পছন্দ করুন।

দ্রুত স্পট-চেক প্রম্পট উদাহরণ:

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

শেষে, গার্ডরেইল কনফার্ম করুন: সোর্স কন্ট্রো-তে সিক্রেট ব্লক করুন (pre-commit/CI চেক), এবং ব্যাকআপ বা স্ন্যাপশট_plaintext credentials না রাখার নিশ্চয়তা দিন। যদি প্ল্যাটফর্ম স্ন্যাপশট ও রোলব্যাক সপোর্ট করে, নিশ্চিত করুন সিক্রেটগুলো রানটাইম-এ ইনজেক্ট হয়, সেভ করা ইমেজে বেকড নয়।

কংক্রিট ফাইন্ডিং জোর করার প্রম্পট (কপি-পেস্ট প্যাটার্ন)

অনিশ্চিত প্রম্পট অনিশ্চিত উত্তর দেয়। মডেলকে প্রমাণের জন্য বাধ্য করুন: সঠিক লোকেশন, ট্রেস যা আপনি অনুসরণ করতে পারেন, একটি রেপ্রো যেটা চালাতে পারবেন, এবং কি হলে দাবি ভুল প্রমাণ হবে।

একটি সময়-একটি প্যাটার্ন ব্যবহার করুন, তারপর আপনার সম্মতি বা প্রত্যাখ্যানের পরে পুনরায় বলুন।

• ফাইল-লেভেল প্রমাণ: "রেপোতে auth, sessions, tokens, এবং middleware খুঁজুন। সঠিক ফাইল, ফাংশন, এবং লাইনের রেঞ্জ নামান। প্রাসঙ্গিক স্নিপেট উদ্ধৃত করুন। যদি কোডে নির্দেশ করতে না পারেন, বলুন 'no evidence found'।"
• এন্ট্রি থেকে সিংকে ট্রেস: "একটি ইউজার-কন্ট্রোলড ইনপুট (হেডার, কুয়েরি, বডি, কুকি) নিন। এন্ট্রি পয়েন্ট থেকে যেখানে এটি ব্যবহার হয় (SQL, HTML, শেল, টেমপ্লেট, রিডিরেক্ট, ফাইলপাথ) পর্যন্ত ধাপে ধাপে ডেটা ফ্লো দেখান। প্রতিটি ফাংশন তালিকাভুক্ত করুন।"
• রেপ্রো ধাপ: "একটি ন্যূন্যতম রেপ্রো দিন curl-এ (মেথড, URL শেপ, হেডার, বডি)। প্রত্যাশিত স্ট্যাটাস কোড এবং সফল/ব্যর্থ রেসপন্সের উদাহরণ দিন। অনুমানগুলো লিখুন (রোল, অথ স্টেট)।"
• ফালস-পজিটিভ কন্ট্রোল: "এই ফাইন্ডিংকে কি প্রমাণ করবে ভুল? ২–৩টি চেক তালিকাভুক্ত করুন: কনফিগ ফ্ল্যাগ, মিডলওয়্যার অর্ডার, allowlist ভ্যালিডেশন, প্যারামিটারাইজড কুয়েরি, ফ্রেমওয়ার্ক escaping। যদি কোনগুলো আছে, ব্যাখ্যা করুন ঝুঁকি কিভাবে বদলে যায়।"
• সবচেয়ে ছোট নিরাপদ ফিক্স + টেস্ট: "সবচেয়ে ছোট পরিবর্তন প্রস্তাব করুন যা ইস্যুটি ব্লক করবে যাতে বৈধ কেস ভাঙে না। তারপর একটি টেস্ট লেখুন (নাম, উদ্দেশ্য, ইনপুট, প্রত্যাশিত ফল)। যদি ট্রেডঅফ থাকে, সেগুলো উল্লেখ করুন।"

যদি আউটপুট এখনও অস্পষ্ট লাগে, এটাকে পিন করুন:

"উত্তর কেবল: ফাইল পাথ, ফাংশন নাম, ঝুঁকিপূর্ণ লাইন, এবং এক বাক্যে ইমপ্যাক্ট।"

একটি বাস্তব উদাহরণ: অনুমানকে যাচাইযোগ্য ইস্যুতে পরিণত করা

প্রোফাইল আপডেট এন্ডপয়েন্ট প্রায়ই অ্যাক্সেস কন্ট্রোল বাগ লুকায়। এখানে একটি ছোট কেস যা এই চেকলিস্ট অনুসরণ করে দেখা যাবে।

পরিস্থিতি: একটি API এন্ডপয়েন্ট ইউজার প্রোফাইল আপডেট করে:

PATCH /api/profile?accountId=123 JSON যেমন { "displayName": "Sam" }।

আপনি Claude Code-কে হ্যান্ডলার খুঁজে বের করতে, accountId কিভাবে ব্যবহার হচ্ছে ট্রেস করতে, এবং সার্ভার মালিকানা এনফোর্স করছে কিনা প্রমাণ করতে বলেন।

সাধারণত যা দেখা যায়:

• Authn: রিকোয়েস্টে সেশন বা টোকেন লাগে, তাই এটা সুরক্ষিত মনে হয়।
• Authz: হ্যান্ডলার কয়ে accountId কুয়েরি স্ট্রিং থেকে বিশ্বাস করে এবং লগ-ইন করা ইউজারের সাথে মিল আছে কি না যাচাই করে না।
• ইনপুট ভ্যালিডেশন: displayName ট্রিম করা হয়, কিন্তু accountId ইন্ট হিসেবে ভ্যালিডেট করা হয় না।
• ইনজেকশন সারফেস: SQL স্ট্রিংভাবে বানানো হয় "... WHERE account_id=" + accountId এভাবে।

একটি ভাল রাইট-আপ কংক্রিট হবে:

• Severity: High (IDOR + সম্ভাব্য SQL injection)
• Evidence: একটি বৈধ লগইন নিয়ে অন্য অ্যাকাউন্ট পরিবর্তন করা যায় যখন accountId বদলানো হয়; SQL অনচিহ্নিত ইনপুট থেকে বানানো হচ্ছে
• Fix: ক্লায়েন্টের accountId উপেক্ষা করুন, সার্ভারে authenticated user's account id ব্যবহার করুন; কুয়েরি প্যারামিটারাইজ করুন
• Test: অন্য অ্যাকাউন্ট আপডেটের চেষ্টা করলে 403 প্রত্যাশা করুন; অ-নিউমেরিক accountId প্রত্যাখ্যান করুন

প্যাচ করার পরে দ্রুত পুনঃচেক করুন:

• একই রিকোয়েস্ট ভিন্ন accountId দিয়ে চালিয়েছেন তা ব্যর্থ হয় কিনা নিশ্চিত করুন।
• লগে দেখুন সার্ভার অথেনটিকেটেড আইডি ব্যবহার করছে, কুয়েরি প্যারাম সাজানো হয়েছে কি না।
• একটি নেগেটিভ টেস্ট রান করুন খারাপ ইনপুট (অক্ষর, অত্যধিক বড় নম্বর) জন্য।

স্পট-চেকগুলো যেগুলো আসল ইস্যু মিস করে এমন সাধারণ ফাঁদ

স্পট-চেক মিস করার দ্রুততম উপায় হলো UI-তে যা enforce করা হয় সেটার ওপর ভর করা। একটি বোতাম লুকানো বা নিষ্ক্রিয় থাকলেই সেটা পারমিশন চেক নয়। যদি সার্ভার রিকোয়েস্ট গ্রহণ করে, হ্যাক করবে সরাসরি API কলে।

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

একই নিয়ম AI আউটপুটেও প্রযোজ্য: রেফারেন্স ছাড়া দাবী গ্রহণ করবেন না। যদি একটি ফাইন্ডিংতে কংক্রিট কোড লোকেশন ও ট্রিগার স্টেপ না থাকে, সেটাকে প্রমাণহীন হিসেবে নিন।

দ্রুতভাবে স্পট-চেকগুলো রাস্তা থেকে বেরিয়ে যাওয়ার কারণগুলো

এই ফাঁদগুলো বারবার দেখা যায়:

• একটি পেজকে "অ্যাডমিন-ওনলি" ধরে নেওয়া কারণ এটা অ্যাডমিন পেজ, সার্ভার তা enforce করে না
• বিস্তৃত রিভিউ ফলাফল চাইলে কিভাবে সরাসরি X বাইপাস হবে তা ভেবে না বলে অপ্রতুল ফল পাওয়া
• "সম্ভাব্য SQL injection" মেনে নেয়া ছাড়া কুয়েরি গঠন পয়েন্ট ও ইনপুট পথ দেখার প্রয়োজন
• ওয়েবহুক, শিডিউল জব, ইম্পোর্ট টুল ও ইন্টারনাল অ্যাডমিন অ্যাকশন মত অপ্রচলিত এন্ট্রি পয়েন্টগুলো এড়িয়ে যাওয়া
• প্রতিটি নতুন এজ কভার করার জন্য ফিল্টার যোগ করা, অথচ রুট-কজ ভ্যালিডেশন বা অথরাইজেশন অনুপস্থিত থাকে

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

শিপ করার আগে দ্রুত চালাতে পারবেন এমন চেকগুলো

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

সেগুলো:

• Authn friction: ১০টি ভুল লগইন পাঠান। রেট লিমিট, লকআউট, বা কমপক্ষে ধীরতা আছে কি? একটি ইমেইল আছে কিনা আপনি এরর মেসেজ বা টাইমিং থেকে বুঝতে পারছেন?
• Authz by ID swap: একটি বাস্তব রিসোর্স বেছে নিন (অর্ডার, ইনভয়েস, প্রোফাইল)। URL, JSON বডি, বা GraphQL ভ্যারিয়েবল-এ ID বদলান। আপনি কি আপনার নয় এমন ডেটা পাচ্ছেন, এমনকি শুধু মেটাডেটাও?
• Input guardrails: গুরুত্বপূর্ণ ফিল্ডগুলোর (ইমেইল, নাম, সার্চ, ফাইল আপলোড) জন্য খুব লম্বা স্ট্রিং, অস্বাভাবিক ইউনিকোড, ও প্রত্যাশিত ধরনের বদলানোর চেষ্টা করুন। যেখানে দরকার দৈর্ঘ্য সীমা ও allowlist আছে কি না দেখুন।
• Secrets exposure: সাম্প্রতিক লগ ও ক্লায়েন্ট বান্ডলে টোকেন, API কী, JWT বা "Authorization: Bearer" খুঁজুন। এরর পেজও চেক করুন। "শুধু স্টেজিং-এ ছিল" প্রায়ই শিপ হয়ে যায়।
• Injection surfaces: SQL, ফিল্টার, টেমপ্লেট রেন্ডারিং, শেল কমান্ড, বা রিডিরেক্ট URL-এ স্ট্রিং কনক্যাট আছে কি না দেখুন। ইনপুট যদি এগুলোর কোথাও শক্তভাবে যাচাই না হয়, ঝুঁকি ধরে নিন যতক্ষণ না কোড দিয়ে প্রমাণ হয় না।

পরবর্তী সপ্তাহে যা শিপ করা যাবে তার শীর্ষ ৩টি ফিক্স লিখে রাখুন, ইচ্ছের তালিকা নয়। উদাহরণ: (1) লগইন ও পাসওয়ার্ড রিসেট-এ রেট লিমিট যোগ করুন, (2) "get by id" এন্ডপয়েন্টে সার্ভার-সাইড মালিকানা চেক জোরদার করুন, (3) সার্চ ফিল্ডের ইনপুট দৈর্ঘ্য কেটে দিন ও অনাকাঙ্ক্ষিত ক্যারেক্টার প্রত্যাখ্যান করুন।

পরবর্তী ধাপ: এই চেকলিস্টকে আপনার বিল্ড প্রসেসের অংশ করুন

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

প্রতিটি ফাইন্ডিংকে এমন একটি ব্যাকলগ আইটেমে পরিণত করুন যা বোঝা কঠিন না:

• Fix: কোড বা কনফিগে কী বদল হবে
• Test: কিভাবে প্রমাণ করবেন এটি ঠিক হয়েছে (একটি রিকোয়েস্ট, একটি ইউনিট টেস্ট, একটি QA ধাপ)
• Owner: একজন দায়ী ব্যক্তি
• Target date: পরবর্তী রিলিজ বা একটি নির্দিষ্ট দিন
• Evidence: ফাইল/এন্ডপয়েন্ট এবং যেই যথার্থ রিকোয়েস্ট বা পেলোড ইস্যু দেখিয়েছে

একটি ক্যাডেন্স পছন্দ করুন যা আপনার রিস্ক ও টিম সাইজের সঙ্গে মেলে। অনেক টিমের জন্য প্রতিটি রিলিজই ভালো। যদি রিলিজ ঘন হয়, তাহলে মাসিক ৩০–৬০ মিনিট রিভিউ এবং শিপের আগে একটি সংক্ষিপ্ত চেক করুন।

পুনরাবৃত্তি সহজ করতে একটি পুনঃব্যবহারযোগ্য প্রম্পট প্যাক ও চেকলিস্ট টেমপ্লেট তৈরি করুন। প্রম্পটগুলো কংক্রিট আউটপুটের দিকে ফোকাস রাখুন: রুট দেখান, গার্ড দেখান, ব্যর্থ রিকোয়েস্ট দেখান, এবং প্রত্যাশিত আচরণ বলুন। প্যাকটিকে আপনার দলের কাজের জায়গায় রাখুন যাতে এটি বাদ না পড়ে।

যদি আপনি চ্যাটের মাধ্যমে অ্যাপ বানান, প্লানিংয়ে এই চেকলিস্ট বেক করুন। authn/authz, ইনপুট, ও সিক্রেট নিয়ে ছোট "সিকিউরিটি অনুমান" নোট যোগ করুন, তারপর প্রথম কাজ করা ভার্সনের পরে স্পট-চেক চালান।

Platforms like Koder.ai (koder.ai) এই অভ্যাসে ভাল ফিট করতে পারে কারণ সেগুলো দ্রুত ইটারেট করতে দেয় এবং রিভিউ চেকপয়েন্ট রক্ষা করে। স্ন্যাপশট ও রোলব্যাক ঝুঁকিপূর্ণ পরিবর্তনের চারপাশে ব্যবহার করলে সিকিউরিটি ফিক্স শিপ করা সহজ হয় যখন কোন পরিবর্তন আচরণ ভাঙে।