OWASP Top 10 — web-এর ঝুঁকির মানচিত্র

১ · OWASP কী, আর এই তালিকা আসলে কী

ধরুন ঢাকার ট্রাফিক বিভাগ কয়েক বছরের দুর্ঘটনার খাতা ঘেঁটে শহরের সবচেয়ে বিপজ্জনক দশটি মোড়ের একটি মানচিত্র বানাল। নতুন চালকের জন্য এটি খুব কাজের। কোথায় সাবধান হতে হবে, তা তিনি আগেই জানলেন। কিন্তু এই মানচিত্র ট্রাফিক আইন নয়, গাড়ির ফিটনেস সনদও নয়। দশটি মোড় নিরাপদে পার হলেও এগারো নম্বর মোড়ে দুর্ঘটনা হতে পারে।

OWASP Top 10 ঠিক এমন একটি মানচিত্র, web application-এর জন্য। আর OWASP হলো Open Worldwide Application Security Project. আগে নামের “Worldwide” অংশে “Web” ছিল, পরে সেটি বদলানো হয়। এটি একটি উন্মুক্ত community আর অলাভজনক foundation, যার বেশিরভাগ কাজ করেন স্বেচ্ছাসেবকেরা। কোনো software কোম্পানির সাথে এর মালিকানার সম্পর্ক নেই, তাই এর নির্দেশিকা বিনামূল্যে সবার জন্য খোলা।

তালিকাটি প্রথম আসে ২০০৩ সালে। OWASP-এর হিসাবে ২০২৫ সংস্করণটি এর অষ্টম কিস্তি। এই পর্বের নাম, ক্রম আর সংখ্যা ২০২৬ সালের অক্টোবরে OWASP-এর নিজস্ব সাইট দেখে মেলানো। পড়ার সময় আপনিও সাইটে সর্বশেষ সংস্করণটি দেখে নিন।

২ · তালিকা কীভাবে বানানো হয় — data, survey আর গোড়ার কারণ

তালিকার পেছনে দুটি উৎস আছে। একটি হলো পরীক্ষার তথ্য, যা নিরাপত্তা প্রতিষ্ঠান, টুল নির্মাতা আর bug bounty প্ল্যাটফর্ম দান করে। অন্যটি হলো মাঠে কাজ করা মানুষের ভোট। ডাক্তারের ভাষায় একটি হলো হাসপাতালের রোগের রেজিস্টার, অন্যটি অভিজ্ঞ চিকিৎসকদের মত। কেন দুটোই লাগে, তা একটু পরে দেখবেন।

২০২৫ সংস্করণে OWASP জানিয়েছে, ২৮ লক্ষের বেশি application-এর তথ্য এসেছে। নাম জানা এক ডজনের মতো প্রতিষ্ঠান আর কয়েকজন বেনামি দাতা তথ্য দিয়েছেন। বিশ্লেষণে এসেছে ৫৮৯টি CWE, যা ২০২১ সালের প্রায় ৪০০-র চেয়ে অনেক বেশি। CWE মানে দুর্বলতার ধরন (পর্ব ৩২). দশটি বিভাগে মোট ২৪৮টি CWE বসেছে। গড়ে প্রতি বিভাগে প্রায় ২৫টি, সর্বনিম্ন ৫টি, আর সর্বোচ্চ সীমা ৪০টি।

গণনার নিয়মটিই আসল কথা: ঘটনা নয়, application

OWASP দেখে কতগুলো application-এ একটি CWE অন্তত একবার আছে। একই app-এ সেটি কতবার আছে, তা নয়। এই হারকে বলে incidence rate. তাই Top 10-এর ক্রম “কোন bug সবচেয়ে বেশিবার দেখা যায়” তার তালিকা নয়।

শুধু হার দিয়ে ঝুঁকি হয় না। প্রায় ১.৭৫ লক্ষ CVE রেকর্ড NVD থেকে CWE-র সাথে মিলিয়ে OWASP গড় exploit আর impact স্কোর বের করে, যা ঝুঁকির সমীকরণের বাকি অর্ধেক। স্কোরগুলো এসেছে CVSS v2 আর v3 থেকে। CVSS v4.0 ব্যবহার হয়নি, কারণ OWASP-এর ব্যাখ্যায় তার হিসাব থেকে exploit আর impact আলাদা করে পাওয়া যায় না।

Survey কেন লাগে

Data সবসময় অতীতের কথা বলে। আর টুল যা সহজে পরীক্ষা করতে পারে, data-তে তাই বেশি আসে। রাতে রাস্তার বাতির নিচে হারানো চাবি খোঁজার মতো, আলো যেখানে সেখানেই খোঁজা হয়। তাই OWASP বলে, data থেকে আটটি নেওয়া হয়, কারণ তথ্য অসম্পূর্ণ। বাকি দুটি ঠিক করেন মাঠের মানুষ। ২০২৫ সালে A03 survey-তে সবচেয়ে উপরে ছিল, ঠিক অর্ধেক উত্তরদাতা একে এক নম্বরে রেখেছেন। A09 তৃতীয়বারের মতো survey থেকে তালিকায় এসেছে, কারণ এটি পরীক্ষা করা কঠিন।

আরেকটি পরিবর্তন লক্ষ করুন। OWASP যতটা সম্ভব লক্ষণ নয়, root cause ধরে বিভাগ বানাতে চায়। যেমন “তথ্য ফাঁস” একটি লক্ষণ, আর “ভুল cryptography” তার গোড়ার কারণ। গোড়া ধরলে সমাধানও পরিষ্কার হয়।

২০২১ থেকে ২০২৫ — কী বদলাল

৩ · বাজারের মানচিত্র — A01 থেকে A05

এখন একটি কাল্পনিক অনলাইন বাজার ধরুন, যেখানে মানুষ ঘরের জিনিস কেনেন। Browser কী করতে দেয় আর কী দেয় না, তা পর্ব ৩৬-এ দেখেছেন। এবার পুরো ব্যবস্থাটি দেখব। নিচের ছবিতে দেখুন, দশটি ঝুঁকি এই ব্যবস্থার কোথায় কোথায় বসে। লাল ড্যাশ দাগটি trust boundary (পর্ব ৪). তার ওপরের কিছুই বিশ্বাস করা যায় না।

প্রতিটি ঝুঁকি একই ছাঁচে দেখব: সহজ কথায় কী, বাজারে কেমন দেখায়, কীভাবে আটকাবেন, কীভাবে ধরবেন, আর কোন পর্বে গভীরে যাব। এখানে কোনো হামলার উপায় নেই। আপনার নিজের নয় এমন system পরীক্ষা করতে লিখিত অনুমতি লাগে। অনুমতি ছাড়া ঢোকা অপরাধ (পর্ব ৬).

A01:2025 · Broken Access Control — অনুমতির দেয়াল ভাঙা

Broken access control মানে একজন ব্যবহারকারী নিজের অনুমতির বাইরের কাজ করতে পারছেন। আবাসিক হোটেলের চাবি অন্য ঘরেও খুলে গেলে যা হয়, এটি তাই। IDOR, CSRF আর SSRF সবই এখন এই বিভাগের CWE-তে আছে।

• বাজারে: অর্ডারের পাতা শুধু order id দেখে তথ্য দেয়, সেটি কার অর্ডার তা যাচাই করে না।
• প্রতিরোধ: default deny, server-এ প্রতিটি request-এ মালিকানা যাচাই, একই access control কোড সবখানে ব্যবহার।
• ধরবেন কীভাবে: অস্বীকৃত request-এর log, একজনের অনেক অস্বীকৃতিতে alert, আর দুই test account দিয়ে স্বয়ংক্রিয় test.
• গভীরে: পর্ব ১৯, পর্ব ৩৮ (IDOR), পর্ব ৪১ (CSRF), পর্ব ৪২ (SSRF).

A02:2025 · Security Misconfiguration — ভুল সেটিং

Security misconfiguration মানে কোড ঠিক থাকলেও সাজানো ভুল। নতুন বাড়ির তালা ভালো, কিন্তু মিস্ত্রির দেওয়া পুরোনো চাবি এখনো চলে, আর পেছনের দরজা খোলা।

• বাজারে: Public site-এ debug page খোলা, default admin account বেঁচে আছে, cookie-তে Secure আর HttpOnly নেই।
• প্রতিরোধ: স্বয়ংক্রিয় ও পুনরাবৃত্তিযোগ্য hardening, অপ্রয়োজনীয় feature বাদ, security header, আর hardcoded key-এর বদলে স্বল্পমেয়াদি credential.
• ধরবেন কীভাবে: প্রতিটি পরিবেশে configuration-এর স্বয়ংক্রিয় যাচাই, আর configuration drift-এর alert.
• গভীরে: পর্ব ৩০, পর্ব ৪৪.

A03:2025 · Software Supply Chain Failures — সরবরাহের শিকলে ভাঙন

Software supply chain failure মানে আপনার software যাঁদের কোড আর টুলের ওপর দাঁড়িয়ে, সেখানে গোলমাল। হোটেলের রান্না যত ভালোই হোক, পচা মাছ এলে খাবার নষ্ট। OWASP-এর data-য় এর উপস্থিতি কম, কারণ এটি পরীক্ষা করা কঠিন। তবু গড় exploit আর impact স্কোরে এটিই সবার ওপরে।

• বাজারে: কেউ জানে না checkout-এর ভেতরের একটি library-র ভেতরের library কোন version. একজনই কোড লিখে সরাসরি production-এ পাঠাতে পারেন।
• প্রতিরোধ: SBOM, transitive dependency-র হিসাব, অব্যবহৃত অংশ বাদ, দায়িত্বের বিভাজন, সই করা build আর ধাপে ধাপে release.
• ধরবেন কীভাবে: SCA দিয়ে নিয়মিত যাচাই, CVE ও OSV-র মতো উৎসে নজর, আর build pipeline-এর পরিবর্তনের log.
• গভীরে: পর্ব ৩২, পর্ব ৪৮.

A04:2025 · Cryptographic Failures — তালা-চাবির ভুল

Cryptographic failure মানে সংবেদনশীল তথ্য রক্ষার cryptography নেই, দুর্বল, বা ভুলভাবে ব্যবহার হচ্ছে। ব্যাংকের লকারের চাবি যদি লকারের ওপরেই ঝোলে, তালা থেকে কোনো লাভ নেই।

• বাজারে: ক্রেতার ঠিকানা আর ফোন গুদামের service-এ যায় plaintext HTTP-তে, অথবা password-এর hash দ্রুত ও salt-হীন।
• প্রতিরোধ: তথ্যের শ্রেণিবিন্যাস, অপ্রয়োজনীয় তথ্য না রাখা, TLS 1.2 বা নতুনতর, HSTS, প্রমাণিত library, আর password-এর জন্য Argon2-এর মতো ধীর hash.
• ধরবেন কীভাবে: TLS configuration আর certificate-এর নিয়মিত scan, repository-তে key খোঁজা, আর code review.
• গভীরে: পর্ব ১২, পর্ব ১৩, পর্ব ১৪.

A05:2025 · Injection — ডেটা যখন আদেশ হয়ে যায়

Injection মানে ইনপুট ডেটা হিসেবে থাকেনি, query বা command-এর গঠন বদলে দিয়েছে। পিয়নকে লিখে দিলেন “নাম খুঁজে আনুন”, আর কেউ নামের ঘরেই নতুন নির্দেশ লিখে দিলেন। পিয়ন দুটিই পালন করলেন। ওয়েবের XSS-ও এই বিভাগে। OWASP বলছে, এতে সবচেয়ে বেশি CVE আছে: XSS বেশি ঘটে কিন্তু প্রভাব কম, SQL injection কম ঘটে কিন্তু প্রভাব বেশি।

• বাজারে: Coupon খোঁজার কোড ইনপুট জুড়ে query বানায়, যেমন "... code='" + <user-input> + "'".
• প্রতিরোধ: parameterized query, server-এ allowlist যাচাই, প্রেক্ষাপট অনুযায়ী output encoding. হাতে escape করা ভঙ্গুর।
• ধরবেন কীভাবে: SAST, DAST, fuzzing আর code review. Production-এ database error-এর হঠাৎ বৃদ্ধিতে alert.
• গভীরে: পর্ব ৩৯, পর্ব ৪০, আর Database security.

৪ · বাজারের মানচিত্র — A06 থেকে A10

A06:2025 · Insecure Design — নকশাতেই ফাঁক

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

• বাজারে: নতুন ক্রেতার ছাড়ের coupon একই মানুষ যত খুশি account খুলে নিতে পারেন, কারণ কেউ ভাবেননি “এক মানুষ” মানে কী।
• প্রতিরোধ: Threat modeling, secure SDLC, যাচাই করা নকশার ছাঁচ, user story-তে নিরাপত্তা, আর misuse case-এর test.
• ধরবেন কীভাবে: Scanner দিয়ে সাধারণত নয়। ধরা পড়ে design review-এ আর ব্যবসার metric-এ, যেমন coupon-এর অস্বাভাবিক খরচ।
• গভীরে: পর্ব ৪, পর্ব ৪৫, আর Security design.

A07:2025 · Authentication Failures — পরিচয় যাচাইয়ে ভুল

Authentication failure মানে “আপনি কে” প্রশ্নের উত্তর যাচাই দুর্বল। অফিসের দারোয়ান পরিচয়পত্র না দেখেই গেট খুলে দিলে যা হয়। OWASP মনে করে, প্রচলিত authentication framework ব্যবহারে এই শ্রেণির ভুল কমছে।

• বাজারে: Login-এ চেষ্টার সীমা নেই, logout করলেও পুরোনো session চলে, আর admin account-এ MFA নেই।
• প্রতিরোধ: গুরুত্বপূর্ণ জায়গায় MFA, ফাঁস হওয়া password-এর তালিকায় মিলিয়ে দেখা, rate limit, login-এর পর নতুন session ID, আর প্রমাণিত identity সমাধান।
• ধরবেন কীভাবে: ব্যর্থ login-এর ঢেউ, credential stuffing-এর ছাঁচ, নতুন দেশ বা যন্ত্র থেকে login-এর alert.
• গভীরে: পর্ব ১৫, পর্ব ১৬, পর্ব ১৭.

A08:2025 · Software or Data Integrity Failures — যাচাইহীন বিশ্বাস

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

• বাজারে: Checkout page একটি বাইরের CDN থেকে script আনে অখণ্ডতা যাচাই ছাড়া, অথবা client-এর পাঠানো সই-ছাড়া object সরাসরি deserialization করে।
• প্রতিরোধ: Digital signature বা hash দিয়ে উৎস ও অখণ্ডতা যাচাই, বিশ্বস্ত repository, আর CI/CD-তে access control.
• ধরবেন কীভাবে: Signature যাচাই ব্যর্থ হলে build থামানো ও alert, আর pipeline-এর পরিবর্তনের নিরীক্ষা।
• গভীরে: পর্ব ৯, পর্ব ১১, পর্ব ৪৮.

A09:2025 · Security Logging and Alerting Failures — নীরব পাহারা

Logging and alerting failure মানে ঘটনা ঘটছে, কিন্তু কেউ জানছেন না। মহল্লার পাহারাদার খাতায় সব লিখলেন, কিন্তু চোর এলে বাঁশি বাজালেন না। তাই নাম বদলে “Alerting” এসেছে।

• বাজারে: Refund আর ব্যর্থ login log হয় না, অথবা log আছে কিন্তু কেউ দেখেন না। আবার log-এ পুরো ফোন নম্বর আর token জমছে।
• প্রতিরোধ: সফল ও ব্যর্থ দুই ঘটনার log, পড়া সহজ এমন গঠন, log-এর এনকোডিং, সহজে বদলানো যায় না এমন সংরক্ষণ, আর প্রতিটি alert-এর জন্য লিখিত পদক্ষেপ।
• ধরবেন কীভাবে: মহড়া দিয়ে দেখুন alert বাজে কি না। Honeytoken কাজে লাগে, কারণ এটি ছোঁয়া মানেই সন্দেহ, তাই false positive কম।
• গভীরে: পর্ব ৫৫, পর্ব ৫৬.

A10:2025 · Mishandling of Exceptional Conditions — অস্বাভাবিক অবস্থায় ভুল আচরণ

Exceptional condition মানে স্বাভাবিক পথের বাইরের অবস্থা: timeout, ফাঁকা উত্তর, মেমরি শেষ, অনুমতি না পাওয়া। এই বিভাগের ভয় হলো “error হলে কী হবে” তা কেউ ঠিক করেননি। বিদ্যুৎ গেলে যদি ব্যাংকের লকার রুমের দরজা নিজে থেকেই খুলে যায়, সেটিই fail open. উল্টোটি fail secure.

• বাজারে: Payment gateway সাড়া দিল না, আর কোড ধরে নিল টাকা এসেছে। অর্ডার “paid” হয়ে গেল।
• প্রতিরোধ: Error যেখানে ঘটে সেখানেই ধরা, একটি global handler, এক লেনদেনের কোনো ধাপ ব্যর্থ হলে পুরোটা rollback, সীমা বা quota, আর ব্যবহারকারীকে পরিষ্কার কিন্তু ভেতরের তথ্যহীন বার্তা।
• ধরবেন কীভাবে: Error rate-এর হঠাৎ বৃদ্ধি, একই error-এর পুনরাবৃত্তি, আর stress test ও ব্যর্থতা ঢুকিয়ে দেখা test.
• গভীরে: পর্ব ৩, পর্ব ৪৪, পর্ব ৪৬.

৫ · একটি checkout, দশটি ঝুঁকি

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

তালিকার ক্রম বনাম আপনার কাজের ক্রম

একটি সাধারণ ভুল হলো ধরে নেওয়া, A01 মানেই আগে, A10 মানেই পরে। OWASP-এর ক্রম সারা বিশ্বের app-এর গড় ছবি। আপনার সিদ্ধান্ত হবে আপনার ক্ষতি আর খোলা পথ দেখে। Triage মানে ফলাফল বাছাই করে কোনটি আগে তা ঠিক করা, হাসপাতালের জরুরি বিভাগের মতো।

নিচের খেলনা প্রোগ্রামে সাতটি finding আছে। Impact আর reach ১ থেকে ৩ স্কেলে, আর প্রমাণ থাকলে স্কোর দ্বিগুণ। ওজনগুলো আমাদের নিজের, শেখার জন্য বানানো, OWASP-এর নয়।

// Toy triage for a fictional bazaar. The weights are ours, NOT from OWASP.
const findings = [
  { id: 'F1', what: 'order page has no owner check', cat: 'A01', impact: 3, reach: 3, proof: true },
  { id: 'F2', what: 'old report page open to all staff', cat: 'A01', impact: 1, reach: 1, proof: false },
  { id: 'F3', what: 'debug page on public site', cat: 'A02', impact: 2, reach: 3, proof: true },
  { id: 'F4', what: 'flawed library, code path unused', cat: 'A03', impact: 2, reach: 1, proof: false },
  { id: 'F5', what: 'coupon search joins text into query', cat: 'A05', impact: 3, reach: 2, proof: false },
  { id: 'F6', what: 'no alert on refund spike', cat: 'A09', impact: 2, reach: 2, proof: true },
  { id: 'F7', what: 'gateway timeout marks order paid', cat: 'A10', impact: 3, reach: 3, proof: true },
];
function score(f) { return f.impact * f.reach * (f.proof ? 2 : 1); }
function priority(s) { return s >= 12 ? 'P1' : s >= 6 ? 'P2' : 'P3'; }

const ranked = findings
  .map(f => ({ ...f, s: score(f), p: priority(score(f)) }))
  .sort((a, b) => b.s - a.s);

for (const f of ranked) {
  console.log(f.p, String(f.s).padStart(2), f.cat, f.id, f.what);
}
const count = { P1: 0, P2: 0, P3: 0 };
ranked.forEach(f => count[f.p]++);
console.log('summary:', JSON.stringify(count));

P1 18 A01 F1 order page has no owner check
P1 18 A10 F7 gateway timeout marks order paid
P1 12 A02 F3 debug page on public site
...
P3  1 A01 F2 old report page open to all staff
summary: {"P1":3,"P2":2,"P3":2}

৬ · CWE-তে নামা — বিভাগ থেকে নির্দিষ্ট দুর্বলতা

Top 10-এর একটি বিভাগ যেন হাসপাতালের একটি বিভাগ, যেমন হৃদরোগ বিভাগ। আর CWE হলো নির্দিষ্ট রোগের নাম। স্ক্যানার সাধারণত CWE নম্বর দেয়, Top 10 বিভাগ নয়। তাই দুইয়ের মধ্যে যাতায়াত জানা দরকার।

নিচের প্রোগ্রাম তিনটি কাল্পনিক app-এর scan ফল থেকে রিপোর্ট বানায়। খেয়াল করুন, এটি OWASP-এর মতো দুইভাবে গোনে: মোট ঘটনা (hits) আর কতগুলো app-এ আছে। MAP টেবিলটি আসল mapping-এর ছোট অংশ।

// Toy scan for 3 fictional apps. MAP is a small excerpt, not the full mapping.
const MAP = { 22: 'A01', 352: 'A01', 639: 'A01', 862: 'A01', 918: 'A01',
  614: 'A02', 1004: 'A02', 1104: 'A03', 1395: 'A03', 319: 'A04', 327: 'A04',
  79: 'A05', 89: 'A05', 434: 'A06', 501: 'A06', 384: 'A07', 798: 'A07',
  494: 'A08', 502: 'A08', 532: 'A09', 778: 'A09', 209: 'A10', 636: 'A10' };
const apps = ['shop', 'seller', 'admin'];
const scan = [ ['shop', 79], ['shop', 79], ['shop', 79], ['shop', 79], ['shop', 79],
  ['shop', 614], ['seller', 639], ['seller', 1004], ['seller', 209],
  ['admin', 862], ['admin', 778], ['admin', 209], ['admin', 120] ];

const byCat = {};
const unmapped = [];
for (const [app, cwe] of scan) {
  const cat = MAP[cwe];
  if (!cat) { unmapped.push(app + ':CWE-' + cwe); continue; }
  byCat[cat] = byCat[cat] || { hits: 0, apps: new Set(), cwes: new Set() };
  byCat[cat].hits++;
  byCat[cat].apps.add(app);
  byCat[cat].cwes.add(cwe);
}
const rows = Object.entries(byCat).sort((a, b) =>
  b[1].apps.size - a[1].apps.size || a[0].localeCompare(b[0]));
console.log('cat  hits apps incidence cwes');
for (const [cat, r] of rows) {
  const pct = Math.round(r.apps.size / apps.length * 100);
  console.log(cat, String(r.hits).padStart(4), String(r.apps.size).padStart(4),
    String(pct).padStart(8) + '%', [...r.cwes].join(','));
}
console.log('not in this table:', unmapped.join(' '));

cat  hits apps incidence cwes
A01    2    2       67% 639,862
A02    2    2       67% 614,1004
A10    2    2       67% 209
A05    5    1       33% 79
A09    1    1       33% 778
not in this table: admin:CWE-120

৭ · মানচিত্রের পরে — ASVS, Proactive Controls, Cheat Sheet আর SAMM

মানচিত্র দিয়ে শুরু হয়, কিন্তু কাজ চালাতে আরও দলিল লাগে। ট্রাফিকের উদাহরণেই বলি: Top 10 হলো বিপজ্জনক মোড়ের মানচিত্র, ASVS গাড়ির ফিটনেস পরীক্ষার পূর্ণ তালিকা, Proactive Controls ড্রাইভিং স্কুলের প্রথম দশ অভ্যাস, Cheat Sheet মেরামতের ছোট গাইড, আর SAMM পুরো পরিবহন কোম্পানির মান মাপার পদ্ধতি।

ASVS 5.0.0 — যাচাইযোগ্য মান

ASVS মানে Application Security Verification Standard. স্থিতিশীল সংস্করণ 5.0.0 প্রকাশিত হয়েছে ২০২৫ সালের ৩০ মে। এতে মোট ৩৪৫টি requirement আছে। একটি requirement এমনভাবে লেখা, যা “হ্যাঁ” বা “না” দিয়ে যাচাই করা যায়। তাই OWASP বলে, মান হিসেবে গ্রহণ করতে চাইলে Top 10 নয়, ASVS নিন। v4.0.3-তে Level 1-এ ছিল ২৭৮টির মধ্যে ১২৮টি, প্রায় ৪৬%. v5.0.0-তে সেটি ৩৪৫টির মধ্যে ৭০টি, প্রায় ২০%. উদ্দেশ্য, শুরু করা সহজ করা।

৩৪৫ × ০.৭০ ≈ ২৪১, তাই “প্রায় ২৪০” একটি আন্দাজ, OWASP-এর সঠিক সংখ্যা নয়। ASVS-এ level চাপিয়ে দেওয়া হয় না। প্রতিষ্ঠান নিজের ঝুঁকি দেখে ঠিক করে। ব্যাংকের উদাহরণ দিয়ে ASVS বলে, Level 3-এর কম কেন, তা গ্রাহককে বোঝানো কঠিন হবে। নিচের ধাপে দেখুন আমাদের বাজার কীভাবে সিদ্ধান্ত নিচ্ছে।

বাকি তিনটি দলিল

Proactive Controls: ২০২৪ সংস্করণে দশটি প্রতিরোধমূলক কাজ, যেমন C1 Implement Access Control, C4 Address Security from the Start, C9 Implement Security Logging and Monitoring. Top 10 সমস্যা বলে, আর এটি অভ্যাস বলে। প্রকল্পের সাইট আরও নতুন সংস্করণ নিয়ে কাজ চলার ইঙ্গিত দেয়, তাই দেখে নিন।

Cheat Sheet Series: নির্দিষ্ট বিষয়ে ছোট, হাতে-কলমের গাইড। Top 10 আপনাকে বলবে A07 দেখুন, আর Cheat Sheet বলবে session কীভাবে সামলাবেন। ASVS-এর সাথেও এর একটি সূচি আছে।

SAMM: Software Assurance Maturity Model. এটি কোড নয়, প্রতিষ্ঠান মাপে। পাঁচটি business function আছে: Governance, Design, Implementation, Verification, Operations. প্রতিটিতে তিনটি করে, মোট ১৫টি security practice. দল নিজের অবস্থান মেপে পরের লক্ষ্য ঠিক করে। ASVS বলে “এই app কেমন”, আর SAMM বলে “যে প্রতিষ্ঠান app বানায় সেটি কেমন”।

৮ · দল তালিকাটি কীভাবে কাজে লাগায়

Code review-এর চেকলিস্ট — একটি খেলনা স্কোর

নিচের প্রোগ্রাম একটি কাল্পনিক code review-এর তথ্য নিয়ে স্কোর বের করে। প্রশ্নগুলোর ওজন আছে, আর কিছু প্রশ্ন “blocker”, মানে সেটি ব্যর্থ হলে স্কোর যত ভালোই হোক, কোড মিশবে না। Reviewer নিজে উত্তর দেন, প্রোগ্রাম শুধু হিসাব রাখে।

// Toy pull request "add coupon API". A reviewer records facts, then scores.
function review(pr) {
  const list = [ // risk, question, weight, blocker, passed
    ['A01', 'server checks who owns the object', 3, true, pr.ownerCheck],
    ['A05', 'queries use parameters', 3, true, pr.parameterized],
    ['A07', 'endpoint requires login', 3, true, pr.loginRequired],
    ['A02', 'no secret in the diff', 3, true, !pr.secretInDiff],
    ['A10', 'failure stops the action', 3, true, pr.failsClosed],
    ['A03', 'new dependency pinned, reviewed', 2, false, pr.depPinned],
    ['A06', 'misuse case has a test', 2, false, pr.misuseTest],
    ['A09', 'sensitive action is logged', 1, false, pr.logged],
    ['A02', 'error hides internal detail', 1, false, pr.quietError],
  ];
  const total = list.reduce((sum, c) => sum + c[2], 0);
  const got = list.reduce((sum, c) => sum + (c[4] ? c[2] : 0), 0);
  const failed = list.filter(c => !c[4]);
  const blocked = failed.some(c => c[3]);
  console.log('score', got + '/' + total, Math.round(got / total * 100) + '%');
  failed.forEach(c => console.log('  fail', c[0], c[1], c[3] ? '[BLOCKER]' : ''));
  console.log('  verdict:', blocked ? 'CHANGES REQUESTED' : 'OK TO MERGE, human review still needed');
}
const v1 = { ownerCheck: false, parameterized: true, loginRequired: true,
  secretInDiff: false, failsClosed: true, depPinned: true,
  misuseTest: true, logged: true, quietError: true };
console.log('PR version 1');
review(v1);
console.log('PR version 2');
review({ ...v1, ownerCheck: true, logged: false });

PR version 1
score 18/21 86%
  fail A01 server checks who owns the object [BLOCKER]
  verdict: CHANGES REQUESTED
PR version 2
score 20/21 95%
  fail A09 sensitive action is logged
  verdict: OK TO MERGE, human review still needed

একটি finding থেকে fix আর test

দল তালিকাটি সবচেয়ে ভালো কাজে লাগায়, যখন একটি finding শেষ হয় একটি test-এ। তাহলে একই ভুল আর ফেরে না। নিচে F1 finding-টি ধাপে ধাপে দেখুন। কাজটি হচ্ছে কোম্পানির নিজের staging পরিবেশে, নিজের দুটি test account দিয়ে।

F1: test_a logged in, opened an order of test_b.
Page showed name, address and phone of test_b.

CWE     : CWE-639
Category: A01:2025
Score   : 3 x 3 x 2 = 18
Priority: P1
Owner   : orders team

function getOrder(session, orderId) {
  return db.orders.find(orderId);
  // who is asking was never checked
}

function getOrder(session, orderId) {
  const order = db.orders.find(orderId);
  if (!order || order.ownerId !== session.userId) {
    log.warn('order_denied', { user: session.userId });
    return notFound();
  }
  return order;
}

test('buyer reads own order', () => {
  expect(api.as('test_b').get(orderOfB).status).toBe(200);
});
test('buyer cannot read other order', () => {
  expect(api.as('test_a').get(orderOfB).status).toBe(404);
});

event = order_denied
group by user, window 5m
count >= 20  ->  alert security on-call

[x] test fails on old code, passes on new
[x] same pattern searched in other handlers
[x] fix verified on staging, then production
[x] past logs checked for misuse
Status: closed

৯ · আরও তালিকা — API, LLM আর অন্যরা

Top 10 নামটি একটি পরিবারের মতো হয়ে গেছে। মূল তালিকার পাশে নির্দিষ্ট প্রযুক্তির জন্য আলাদা তালিকা আছে, কারণ একই গোড়ার ভুল সেখানে অন্য চেহারায় আসে।

একটি প্রকল্পে একাধিক তালিকা একসাথে প্রযোজ্য হতে পারে। আমাদের বাজারে যদি AI সহায়ক chatbot থাকে, তাহলে web-এর জন্য মূল তালিকা, mobile app-এর API-র জন্য API Top 10, আর chatbot-এর জন্য LLM Top 10 দেখতে হবে। তালিকা বেশি হওয়া সমস্যা নয়। প্রতিটির ওপরের কয়েকটি ঝুঁকি আপনার threat model-এ আছে কি না দেখাই আসল কাজ।

১০ · AI-এর যুগে Top 10

AI এখন প্রচুর web কোড লেখে আর review করে। Top 10 এখানে ভালো একটি ছাঁকনি। তবে AI নিজেই পুরোনো সংস্করণ মনে রাখে, আর আত্মবিশ্বাসে ভুল বলে।

AI-এর উত্তর ব্যবহারের আগে

• বিভাগের নাম আর ক্রম OWASP-এর সাইটের সাথে মিলিয়েছি
• প্রতিটি CVE, CWE আর ASVS নম্বর মূল উৎসে খুঁজে পেয়েছি
• Prompt-এ কোনো secret, key বা গ্রাহকের তথ্য দিইনি
• প্রস্তাবিত fix-এর পুরো diff পড়েছি, কোনো যাচাই বন্ধ হয়নি
• নিজের পরীক্ষা পরিবেশে test চালিয়ে দেখেছি, আর ব্যবহারকারীর ওপর প্রভাব ফেলে এমন সিদ্ধান্ত মানুষ নিয়েছেন