⚡Shadow Academy
একাডেমি / অধ্যায় 66
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100
অধ্যায় 66 / ১০০গল্প · ল্যাব · কুইজ

অধ্যায় 66: NoSQL & Deserialization Safety

Query construction, type validation ও safe serialization.

এই অধ্যায়ে কী শিখবে

⏱ আনুমানিক সময়: ১৫–২০ মিনিট · পূর্বশর্ত: আগের অধ্যায়ের ধারণা

০ / ১০০ অধ্যায়চালিয়ে যাও: অধ্যায় 67

অগ্রগতি এই browser-এ স্থানীয়ভাবে সংরক্ষিত হবে।

গল্প: অধ্যায় 66: NoSQL & Deserialization Safety

জাদুঘরের form JSON হওয়ায় সবাই নিরাপদ ভেবেছিল। ইমরান দেখল, type ও field যাচাই না করলে query structure বদলাতে পারে; সে strict schema, typed API ও safe serialization-এর review করল। বৃষ্টি ম্যাম বললেন, “সৌরভ সোনা, আগে সমস্যাটাকে ছোট করে বুঝি—কোন সম্পদ, কার অনুমতি, আর কোন সীমার মধ্যে কাজ?” সৌরভ বোর্ডে একটি data-flow এঁকে সম্ভাব্য ভুলের জায়গা চিহ্নিত করল। তারা বাস্তব কোনো account বা website-এ হাত না দিয়ে synthetic উদাহরণে hypothesis যাচাই করল।

বৃষ্টি ম্যাম জিজ্ঞেস করলেন, “সৌরভ, গল্পের চরিত্রটি কোন সীমা পেরোতে দিচ্ছিল?” তারা বোর্ডে asset, actor, trust boundary আর expected outcome লিখল। ভুলটি শুধু একটি tool-এর সমস্যা নয়; server কী অনুমতি দিচ্ছে, আর সেই সিদ্ধান্ত যাচাই করা যায় কি না—সেটিই মূল প্রশ্ন।

তারপর তারা বাস্তব service ছুঁয়ে না দেখে synthetic record-এ একই decision অনুশীলন করল। প্রথমে স্বাভাবিক অনুমোদিত flow, তারপর ভুল পরিচয়/invalid state, শেষে fix-এর পর retest। বৃষ্টি ম্যাম বললেন, “সোনা, নিরাপদ শেখা মানে কেবল সমস্যা দেখানো নয়—সীমা মেনে প্রতিরক্ষা প্রমাণ করাও।”

বৃষ্টি ম্যাম সহজ করে বলছে

সমস্যা: operator injection authorization bypass বা data exposure ঘটাতে পারে।

মূল নিয়ম: fixed query schema ও value-only parameter binding; unsafe operator deny। এই নিয়মটি Query construction, type validation ও safe serialization.-এর সঙ্গে মিলিয়ে threat boundary-তে enforce করো; শুধু UI, client-side check বা model instruction-এ ভরসা কোরো না। প্রত্যাখ্যানের কারণ user-কে নিরাপদভাবে জানাও, আর diagnosis-এর জন্য সীমিত redacted event রাখো।

নিরাপদ defensive উদাহরণ

নিচের snippet-টি illustrative pseudocode। এটি কোনো বাইরের target-এ পরীক্ষা চালায় না; control কীভাবে server-side-এ বসে তা দেখায়।

query = {'email': validated_email}
collection.find_one(query)

Review checklist: explicit scope, least privilege, malformed/unauthorized negative case, privacy-safe logging এবং post-fix retest।

আজকের অনুশীলন

NoSQL filter-এ user input operator হিসেবে ব্যাখ্যা হচ্ছে। safe design? কেবল isolated mock বা লিখিত অনুমতিপ্রাপ্ত lab-এ চেষ্টা করো। expected result এবং deny case লিখে রাখো।

প্রতিরক্ষা checkpoint

fixed query schema ও value-only parameter binding; unsafe operator deny Typed schemas, safe query APIs, signed/versioned serialization. remediation-এর owner ও retest ফলাফলও নথিভুক্ত করো।

Review: owner, telemetry, failure behavior ও retest ফলাফল নথিভুক্ত করো।

Portfolio note

Scope, synthetic setup, পর্যবেক্ষণ, ঝুঁকি, remediation ও retest লিখে রাখো। secret বা ব্যক্তিগত তথ্য যোগ কোরো না।

বিশ্বস্ত reference

আরও পড়ার জন্য প্রতিষ্ঠিত security standards ও guidance দেখো; প্রতিটি lab অনুমোদিত বা synthetic environment-এ করো।