নিরাপদ JavaScript — XSS, CSP, CORS আর CSRF ঠেকানো

১ · নিরাপত্তার ভাবনা — কে কী পাঠাতে পারে?

ধরুন আপনি shop.com.bd নামে একটি অনলাইন মুদি দোকান বানাচ্ছেন। পণ্যের পাতায় ক্রেতারা রিভিউ লেখেন, সার্চ বক্সে খোঁজেন, প্রোফাইলে নিজের ওয়েবসাইটের ঠিকানা দেন, আর লগইন করে বিকাশ বা কার্ডে টাকা দেন। এখন একটু অন্যভাবে ভাবুন: এই ঘরগুলোতে যে কেউ যা খুশি লিখতে পারেন। আর আপনার ক্রেতা লগইন অবস্থায় অন্য কোনো সাইট খুললে সেই সাইটের পাতাও তাঁর ব্রাউজারে JavaScript চালায়।

নিরাপত্তার কাজ শুরু হয় এই প্রশ্নগুলো দিয়ে: কে আক্রমণ করতে পারে? কোন পথে কী পাঠাতে পারে? কোন জিনিসটি রক্ষা করা সবচেয়ে জরুরি — ক্রেতার session, টাকা, ব্যক্তিগত তথ্য? এই লিখিত উত্তরের নাম threat model. ওয়েবে এর প্রথম সূত্রটি কঠিন কিন্তু সরল: ব্রাউজারে যা কিছু চলে, তা ব্যবহারকারীর নিয়ন্ত্রণে। তাই পর্ব ৩৯-এর ফর্ম-যাচাই ব্যবহারকারীর সুবিধার জন্য; দাম, অনুমতি আর ইনপুটের আসল যাচাই হয় সার্ভারে।

এই পর্বের সব প্রতিরক্ষা আসলে চারটি নীতির প্রয়োগ। (১) সব ইনপুট ডেটা — কখনো কোড নয়। (২) ডেটা যেখানে বসবে, সেই প্রসঙ্গের নিয়মে encode করুন। (৩) পাতায় কী চলতে পারবে তা সীমিত করুন (CSP). (৪) পরিচয়ের প্রমাণ (cookie) সাবধানে রাখুন, আর প্রতিটি সিদ্ধান্ত সার্ভারে আবার যাচাই করুন। একটি স্তর ব্যর্থ হলেও পরের স্তর যেন ক্ষতি থামায় — এই ধারণার নাম defense in depth.

২ · Same-origin policy — ব্রাউজারের মূল দেয়াল

পর্ব ৩৫-এ দেখেছেন, একটি origin হলো protocol + host + port-এর জোড়। https://shop.com.bd আর https://api.shop.com.bd আলাদা origin (host আলাদা); http://shop.com.bd আলাদা (protocol আলাদা); https://shop.com.bd:8443-ও আলাদা (port আলাদা)। Same-origin policy বলে: একটি origin-এর পাতার JavaScript অন্য origin-এর জিনিস পড়তে পারবে না। কিন্তু অন্য সাইটের জিনিস জুড়ে দেখানো (embed) ঠিকই চলে — নিয়মটি সূক্ষ্ম:

এখানে একটি সূক্ষ্ম কিন্তু জরুরি পার্থক্য আছে: same-origin আর same-site এক জিনিস নয়। “Site” মানে scheme আর registrable domain — যে নামটি আপনি টাকা দিয়ে নিবন্ধন করেন। .com.bd নিজে একটি public suffix, তাই shop.com.bd-ই registrable domain; ফলে api.shop.com.bd আর shop.com.bd cross-origin কিন্তু same-site. Cookie-র SameSite নিয়ম (অংশ ৭) চলে “site” ধরে, CORS চলে “origin” ধরে।

৩ · CORS — সার্ভারের দেওয়া নিয়ন্ত্রিত অনুমতি

বাস্তব অ্যাপে প্রায়ই পাতা আর API আলাদা origin-এ থাকে: পাতা https://shop.com.bd-এ, API https://api.shop.com.bd-এ। Same-origin policy অনুযায়ী পাতার JavaScript API-র উত্তর পড়তে পারার কথা নয়। CORS (Cross-Origin Resource Sharing) এই দেয়ালে একটি দরজা খোলে — কিন্তু চাবি সার্ভারের হাতে। ব্রাউজার প্রতিটি cross-origin অনুরোধে Origin: https://shop.com.bd header জুড়ে দেয়; সার্ভার উত্তরে Access-Control-Allow-Origin: https://shop.com.bd লিখলে ব্রাউজার উত্তরটি JavaScript-কে দেয়, না লিখলে দেয় না।

Simple অনুরোধ বনাম preflight

কিছু অনুরোধ ব্রাউজার সরাসরি পাঠায়, কারণ এগুলো একটি সাধারণ HTML ফর্মও পাঠাতে পারে — এদের বলে simple request: method GET, HEAD বা POST; শুধু নিরাপদ তালিকার header; আর Content-Type হলে কেবল application/x-www-form-urlencoded, multipart/form-data বা text/plain. এর বাইরের যেকোনো কিছু — PUT, DELETE, Content-Type: application/json, Authorization header — পাঠানোর আগে ব্রাউজার সার্ভারকে জিজ্ঞেস করে নেয়। এই আগাম জিজ্ঞাসার নাম preflight request:

await fetch("https://api.shop.com.bd/cart/7", {
  method: "PUT",
  headers: { "Content-Type": "application/json" },
  credentials: "include",            // cookie পাঠাও
  body: JSON.stringify({ qty: 2 }),
});

OPTIONS /cart/7 HTTP/1.1
Host: api.shop.com.bd
Origin: https://shop.com.bd
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: content-type

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://shop.com.bd
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 600          ← ১০ মিনিট মনে রাখো
Vary: Origin

PUT /cart/7 HTTP/1.1
Origin: https://shop.com.bd
Cookie: session=…
Content-Type: application/json

{"qty":2}

উত্তরে Access-Control-Allow-Origin: https://shop.com.bd
  → res.ok, await res.json() — সব স্বাভাবিক
header নেই বা অন্য origin লেখা
  → fetch reject: TypeError: Failed to fetch
  → কারণ শুধু DevTools Console-এ লেখা থাকে

সবচেয়ে বিপজ্জনক ভুল কনফিগারেশন

CORS error দেখে বিরক্ত হয়ে অনেকে সার্ভারে যা খুশি বসিয়ে দেন। তিনটি ধরন সবচেয়ে বেশি দেখা যায়। (১) যেকোনো origin ফিরিয়ে দেওয়া: অনুরোধের Origin যা-ই হোক, হুবহু Access-Control-Allow-Origin-এ বসিয়ে দেওয়া, সাথে Allow-Credentials: true. এর মানে পৃথিবীর যেকোনো সাইট আপনার ক্রেতার cookie দিয়ে তাঁর অর্ডার আর ঠিকানা পড়তে পারবে। (২) "*" দিয়ে সব খুলে দেওয়া: পাবলিক, লগইন-ছাড়া ডেটার (যেমন পণ্যের দামের তালিকা) জন্য ঠিক আছে, অন্য কিছুর জন্য নয়। (৩) আলগা মিল: “origin-এ shop.com.bd শব্দটি আছে কি না” দেখা — তাহলে shop.com.bd.evil.example-ও পাস করে যায়। নিরাপদ পথ একটাই: অনুমোদিত origin-এর হুবহু তালিকা, আর null origin কখনো অনুমোদিত নয়।

ডেভেলপমেন্টে একটি বৈধ শর্টকাট আছে: dev proxy. Vite-এর মতো dev server (পর্ব ৪৬) নিজের /api পথের অনুরোধ পেছনে আসল API-তে পাঠিয়ে দিতে পারে; ব্রাউজারের চোখে তখন সব একই origin, তাই CORS প্রশ্নই ওঠে না।

এবার সত্যিকারের একটি সার্ভার দিয়ে দেখি। নিচের Node.js প্রোগ্রামে api.shop.com.bd-এর মতো একটি ছোট API শুধু https://shop.com.bd-কে অনুমতি দেয়। আমরা দুটি origin থেকে preflight পাঠাই, তারপর অননুমোদিত origin থেকে একটি সাধারণ GET:

const http = require("node:http");
const ALLOWED = new Set(["https://shop.com.bd"]);              // অনুমোদিত origin-এর তালিকা
const server = http.createServer((req, res) => {
  const origin = req.headers.origin, ok = ALLOWED.has(origin);  // হুবহু মিল চাই
  const h = { "Content-Type": "application/json", Vary: "Origin", Connection: "close" };
  if (ok) Object.assign(h, { "Access-Control-Allow-Origin": origin, "Access-Control-Allow-Credentials": "true" });
  if (req.method !== "OPTIONS") return res.writeHead(200, h).end(JSON.stringify({ items: 3 }));
  if (ok) Object.assign(h, { "Access-Control-Allow-Methods": "GET, POST",   // preflight-এর উত্তর
    "Access-Control-Allow-Headers": "Content-Type", "Access-Control-Max-Age": "600" });
  res.writeHead(204, h).end();
});
const show = (r, ...names) => names.map((n) => `${n}=${r.headers.get(n) ?? "(নেই)"}`).join(" ");
server.listen(0, "127.0.0.1", async () => {
  const api = `http://127.0.0.1:${server.address().port}/api/cart`;
  for (const origin of ["https://shop.com.bd", "https://evil.example"]) {
    const pre = await fetch(api, { method: "OPTIONS", headers: { Origin: origin,
      "Access-Control-Request-Method": "POST", "Access-Control-Request-Headers": "content-type" } });
    console.log(origin, pre.status, show(pre, "access-control-allow-origin", "access-control-allow-methods"));
  }
  const res = await fetch(api, { headers: { Origin: "https://evil.example" } });
  console.log("Node পড়ল:", res.status, await res.json(), show(res, "access-control-allow-origin"));
  server.close();
});

৪ · XSS — যখন ডেটা কোড হয়ে যায়

XSS (Cross-Site Scripting)-এর মূল কথা: অন্য কারও দেওয়া লেখা আপনার পাতায় HTML বা JavaScript হিসেবে পড়া হয়ে গেছে, আর সেটি চলছে আপনার origin-এর সব ক্ষমতা নিয়ে। Same-origin policy এখানে সাহায্য করে না, কারণ ঢোকানো কোড এখন আপনার পাতারই অংশ — সে ব্যবহারকারীর হয়ে অনুরোধ পাঠাতে বা নকল লগইন ফর্ম দেখাতে পারে। পরিচিত নিরীহ উদাহরণ হলো এই লেখাটি, যা আমরা এখানে শুধু লেখা হিসেবে দেখাচ্ছি: <img src=x onerror=alert(1)>. কোনো পাতা এটিকে HTML হিসেবে বসালে ব্রাউজার একটি ছবি বানাতে চেষ্টা করে, ছবি লোড ব্যর্থ হয়, আর onerror-এর ভেতরের কোড চলে। XSS তিন রূপে আসে:

যে API-তে লেখা দিলে তা HTML বা কোড হয়ে যায়, তাদের বলে sink. কোড রিভিউতে এই নামগুলো দেখলেই থামুন:

একটি চমকপ্রদ তথ্য: innerHTML দিয়ে বসানো <script> tag HTML5-এর নিয়মে চলে না. কিন্তু <img onerror>, <svg onload>-এর মতো event attribute ঠিকই চলে — তাই innerHTML-এ অবিশ্বস্ত লেখা দেওয়া সবসময়ই বিপজ্জনক। এবার দেখুন একটি stored XSS-এর পুরো জীবন, আর প্রতিটি ধাপে কোন প্রতিরক্ষা কাজ করে:

রিভিউ: "<img src=x onerror=alert(1)> চাল ভালো"
সার্ভার: দৈর্ঘ্য ≤ ১০০০? রেটিং ১–৫? ধরন string?
// “< থাকলে বাতিল” — তাহলে "ভাত < বিরিয়ানি" লেখা যায় না
// ইনপুট যাচাই ব্যবসার নিয়মের জন্য; XSS-এর মূল সমাধান নয়

db.run("INSERT INTO reviews (text) VALUES (?)", [text]);
// placeholder (?) — SQL injection নেই
// আগেই HTML-escape করে রাখবেন না: JSON API, মোবাইল অ্যাপ,
// ইমেইল — প্রতিটির প্রসঙ্গ আলাদা; encode হয় দেখানোর সময়

{ "user": "করিম", "text": "<img src=x onerror=alert(1)> চাল ভালো" }
// JSON-এর ভেতরে এটি একটি string মাত্র — এখনো কোনো বিপদ নেই
// বিপদ শুরু হবে কেবল যদি পাতা এটিকে HTML হিসেবে পড়ে

// ✗ li.innerHTML = r.text;   → img তৈরি হয়, onerror চলে
li.textContent = r.text;      // ✓ পর্দায় অক্ষরগুলোই দেখা যায়
// framework হলে: React-এর {r.text}, Vue-র {{ r.text }} — নিজে escape করে

Content-Security-Policy: script-src 'self' 'nonce-…'
→ inline event handler (onerror) চলবে না, Console-এ সতর্কবার্তা
Set-Cookie: session=…; HttpOnly; Secure; SameSite=Lax
→ ঢোকানো কোড চললেও session cookie পড়তে পারত না

৫ · XSS ঠেকানো — textContent, encoding, sanitization আর URL যাচাই

প্রথম নিয়ম: ডেটা দেখান ডেটা হিসেবে

বেশিরভাগ ক্ষেত্রে সমাধান খুব সরল: লেখা দেখাতে textContent, attribute বসাতে setAttribute বা সরাসরি property (img.alt = name), আর কাঠামো বানাতে createElement + append. সার্চ পাতার উদাহরণে results.innerHTML = `“${q}”-এর জন্য ফল` না লিখে লিখুন title.textContent = `“${q}”-এর জন্য ফল` — reflected XSS শেষ। Template literal-এ HTML জোড়া দেওয়া (`<li>${r.text}</li>`) AI আর পুরোনো tutorial-এ সবচেয়ে বেশি দেখা XSS-এর উৎস।

প্রসঙ্গ বুঝে encoding

কখনো সার্ভারে HTML বানাতে হয়, বা পুরোনো কোডে string-এ HTML জোড়া এড়ানো যায় না। তখন লেখা বসানোর আগে encode করতে হয় — আর encode-এর নিয়ম প্রসঙ্গভেদে আলাদা। HTML লেখার ভেতরে < হবে <, & হবে &; attribute-এর ভেতরে quote-ও encode করতে হবে, আর attribute-এর মান সবসময় quote-এর ভেতরে রাখতে হবে; URL-এর query-তে encodeURIComponent বা URLSearchParams (পর্ব ৩৫); <script>-এর ভেতরে ডেটা বসাতে হলে JSON হিসেবে, আর তারও < escape করে। একটি প্রসঙ্গের encoding অন্য প্রসঙ্গে কাজ করে না: HTML-escape করা লেখাও href-এ বসালে javascript: URL ঠিকই চলবে।

HTML সত্যিই লাগলে — sanitization

ব্লগের মন্তব্যে bold বা link রাখতে দিতে চান? তখন textContent চলবে না; দরকার sanitization: অনুমোদিত tag আর attribute-এর তালিকা (allowlist) রেখে বাকি সব ছেঁটে ফেলা। নিজে regex দিয়ে sanitizer লিখবেন না — HTML-এর parse করার নিয়ম এত জটিল যে ব্রাউজার যেভাবে পড়বে, আপনার regex সেভাবে পড়বে না (পর্ব ৩০-এর সতর্কতা মনে করুন)। প্রচলিত পথ DOMPurify: el.innerHTML = DOMPurify.sanitize(comment). এটি ব্রাউজারের নিজের parser দিয়ে লেখাটি ভাঙে, তারপর allowlist-এর বাইরের সব — <script>, on… attribute, javascript: URL — সরিয়ে দেয়। ব্রাউজারে নিজস্ব HTML Sanitizer API (el.setHTML(input)) মানদণ্ড হওয়ার পথে, আর কিছু ব্রাউজারে আসতে শুরু করেছে; সব ব্রাউজারে না আসা পর্যন্ত প্রোডাকশনে DOMPurify-ই নির্ভরযোগ্য, আর ব্যবহারের আগে MDN-এ বর্তমান সমর্থন দেখে নিন।

Framework-এর স্বয়ংক্রিয় escape — আর তার পেছনের দরজা

React, Vue, Svelte, Angular (পর্ব ৫৪) ডিফল্টে লেখা escape করে বসায় — {review.text} বা {{ review.text }} নিরাপদ। কিন্তু প্রতিটির একটি ইচ্ছাকৃত পেছনের দরজা আছে, যার নামেই সতর্কবার্তা: React-এর dangerouslySetInnerHTML, Vue-র v-html, Svelte-এর {@html …}, Angular-এর bypassSecurityTrustHtml. এগুলোতে অবিশ্বস্ত ডেটা গেলে framework আপনাকে বাঁচাবে না। আর framework সাধারণত href-এর মান যাচাই করে না।

URL যাচাই আর Trusted Types

প্রোফাইলের “website” ঘরে কেউ লিখলেন javascript:alert(1). আপনি সেটি <a href>-এ বসালেন — যিনি link-এ চাপবেন, তাঁর পাতায় কোড চলবে। “javascript: দিয়ে শুরু হলে বাতিল” — এমন blocklist ফসকে যায় (বড় হাতের অক্ষর, শুরুতে ফাঁকা, মাঝে tab). সঠিক পথ allowlist: new URL() দিয়ে ব্রাউজারের নিজের নিয়মে parse করুন, তারপর protocol শুধু "https:" বা "http:" হলে গ্রহণ করুন। এর ওপরে আরেকটি স্তর আছে: Trusted Types. CSP-তে require-trusted-types-for 'script' দিলে innerHTML-এর মতো sink সাধারণ string নেওয়াই বন্ধ করে দেয় — শুধু আপনার অনুমোদিত policy-র (যেমন DOMPurify-চালিত) বানানো object নেয়। Chromium-ভিত্তিক ব্রাউজারে এটি ২০২০ সাল (Chrome 83) থেকে আছে; অন্য ব্রাউজারে সমর্থন পরে এসেছে বা আসছে।

এবার তিনটি নিরাপদ কৌশল একসাথে চালিয়ে দেখুন: রিভিউয়ের “ক্ষতিকর” লেখাটি textContent দিয়ে বসানো, একটি escapeHTML function, আর website ঘরের জন্য safeURL:

const review = '<img src=x onerror=alert(1)> চাল ভালো';   // আক্রমণকারীর "রিভিউ"
const website = "javascript:alert(1)";                         // প্রোফাইলের "website" ঘর

const li = document.createElement("li");
li.textContent = review;                                       // HTML নয়, শুধু লেখা
document.querySelector("#reviews").append(li);
console.log("element তৈরি হলো?", li.children.length, "| দেখাচ্ছে:", li.textContent);

const escapeHTML = (s) => s.replace(/[&<>"']/g, (c) =>
  ({ "&": "&amp;", "<": "&lt;", ">": "&gt;", '"': "&quot;", "'": "&#39;" })[c]);
console.log(escapeHTML(review));

function safeURL(input) {
  try {
    const u = new URL(input, "https://shop.com.bd");
    return ["https:", "http:"].includes(u.protocol) ? u.href : null;
  } catch { return null; }
}
for (const w of [website, " JavaScript:alert(1)", "https://rahim.com.bd", "/about", "data:text/html,hi"])
  console.log(JSON.stringify(w), "→", safeURL(w));

৬ · CSP — পাতায় কী চলতে পারবে, তার তালিকা

Content Security Policy হলো সার্ভারের পাঠানো একটি response header, যা ব্রাউজারকে বলে: এই পাতায় কোন উৎসের script, style, ছবি, frame চলতে পারবে। XSS-এর বাগ থেকে গেলেও ঢোকানো কোড চালানো তখন কঠিন হয়ে যায়। একটি আধুনিক, কড়া CSP দেখতে এরকম:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-r4nd0mB4se64';
  object-src 'none';
  base-uri 'none';
  frame-ancestors 'self';
  report-to csp-endpoint

লাইন ধরে পড়ুন। default-src 'self': আলাদা করে না বলা সব কিছু শুধু নিজের origin থেকে। script-src 'self' 'nonce-…': script চলবে নিজের origin-এর ফাইল থেকে, আর সেই inline script, যার tag-এ ঠিক এই nonce লেখা আছে — <script nonce="r4nd0mB4se64">. Nonce প্রতিটি response-এ সার্ভার নতুন করে এলোমেলোভাবে বানায়; আক্রমণকারী আগে থেকে জানে না, তাই তার ঢোকানো script-এ সঠিক nonce থাকে না। Nonce-এর বিকল্প হলো hash: 'sha256-…' লিখে একটি নির্দিষ্ট inline script-এর বিষয়বস্তুকে অনুমোদন দেওয়া — static পাতার জন্য সুবিধাজনক। object-src 'none' পুরোনো plugin বন্ধ করে; base-uri 'none' ঢোকানো <base> tag দিয়ে আপেক্ষিক script ঠিকানা ঘুরিয়ে দেওয়া আটকায়; frame-ancestors ঠিক করে কে আপনার পাতাকে frame-এ দেখাতে পারবে (অংশ ৭)। report-to নিয়ম ভাঙার খবর আপনার সার্ভারে পাঠায় (পুরোনো রূপ report-uri).

Content-Security-Policy: script-src 'self' 'nonce-Xy7q'; object-src 'none'
// এই response-এর জন্য নতুন nonce: Xy7q (পরের response-এ অন্যটি)

<script src="/app.js"></script>              ← 'self' ✓
<script nonce="Xy7q">initCart();</script>  ← nonce মিলেছে ✓

রিভিউয়ের ভেতর থেকে: <img src=x onerror=alert(1)>
→ inline event handler, nonce নেই → চলবে না
Console (Edge/Chrome, সংক্ষেপে):
Refused to execute inline event handler because it violates
the following Content Security Policy directive: "script-src …"

ব্রাউজার report পাঠায় → আপনার /csp-report
{ "blockedURL": "inline", "effectiveDirective": "script-src-attr", … }
// এখন আপনি জানেন কোন পাতায় innerHTML-এর বাগ আছে — সেটি ঠিক করুন

পুরোনো সাইটে হঠাৎ কড়া CSP চালু করলে নিজের পাতাই ভেঙে যেতে পারে — কোথাও inline onclick, কোথাও তৃতীয় পক্ষের script. তাই শুরু করুন report-only মোডে: Content-Security-Policy-Report-Only header ব্রাউজারকে নিয়ম মানতে নয়, শুধু ভাঙার রিপোর্ট পাঠাতে বলে। কয়েক সপ্তাহ রিপোর্ট দেখে নিজের কোড ঠিক করুন, তারপর আসল header চালু করুন। <meta> tag দিয়েও CSP দেওয়া যায়, কিন্তু তাতে frame-ancestors আর report-only কাজ করে না।

৭ · CSRF, clickjacking আর cookie-র নিরাপত্তা

CSRF-এ আক্রমণকারী আপনার পাতায় ঢোকে না — বাইরে থেকেই ব্যবহারকারীর নামে কাজ করিয়ে নেয়। মূল কারণ পর্ব ৪০-এর cookie-র স্বভাব: কোনো সাইটের cookie থাকলে ব্রাউজার সেই সাইটে যাওয়া অনুরোধে cookie জুড়ে দেয় — অনুরোধ কোন পাতা থেকে শুরু হলো, ঐতিহ্যগতভাবে তা না দেখেই। আর অংশ ২-এর টেবিলে দেখেছেন: অন্য সাইট ফর্ম পাঠাতে পারে, উত্তর পড়তে না পারলেও। একটি ব্যাংকের টাকা পাঠানোর ফর্ম দিয়ে পুরো ঘটনা আর প্রতিরক্ষা দেখুন:

bank.com.bd → Set-Cookie: session=a1b2…; HttpOnly; Secure; SameSite=Lax
আসল ফর্মে লুকানো ঘর: <input type="hidden" name="csrf" value="9fK2…">

“আপনি পুরস্কার জিতেছেন!” — prize.example
পাতার ভেতরে লুকানো একটি ফর্ম, গন্তব্য:
POST https://bank.com.bd/transfer  (to=…, amount=…)
// পাতাটি ব্যাংকের উত্তর পড়তে পারবে না — শুধু পাঠাতে পারে

ব্রাউজার ভাবে: অনুরোধ prize.example থেকে শুরু, যাচ্ছে bank.com.bd-এ
→ এটি একটি cross-site POST
প্রশ্ন: session cookie কি সাথে যাবে?

SameSite=Lax: cross-site POST-এ cookie যায় না
ব্যাংকের সার্ভার: “কে আপনি?” → 401 — টাকা গেল না
// Lax-এ শুধু ওপরের স্তরের GET navigation-এ (link চাপা) cookie যায়

ধরুন cookie কোনোভাবে গেল (পুরোনো ব্রাউজার, বা same-site subdomain থেকে):
csrf ঘর নেই / ভুল → 403
Origin: https://prize.example ≠ https://bank.com.bd → 403

আরও দুটি নিয়ম CSRF-কে সহজে আটকায়। কখনো GET দিয়ে অবস্থা বদলাবেন না — GET /cart/delete?id=7 থাকলে একটি <img src> দিয়েই কাজটি করিয়ে নেওয়া যায়, আর Lax cookie-ও GET navigation-এ যায় (পর্ব ৩৫-এর “GET safe” নিয়মটি এখানে নিরাপত্তার নিয়মও)। আর যে API শুধু Authorization header-এ পরিচয় নেয়, সেখানে CSRF-এর ঝুঁকি কম, কারণ ব্রাউজার এই header নিজে থেকে জোড়ে না।

Clickjacking — অদৃশ্য পাতার ওপর ক্লিক

Clickjacking-এ অন্য সাইট আপনার পাতাকে একটি স্বচ্ছ <iframe>-এ নিজের পাতার ওপর বসায়। ব্যবহারকারী দেখেন “ভিডিও চালান”, কিন্তু চাপেন নিচে লুকানো আপনার “অ্যাকাউন্ট মুছুন” বোতাম। প্রতিরক্ষা হলো ব্রাউজারকে বলে দেওয়া, কে আপনার পাতাকে frame-এ দেখাতে পারবে: CSP-র frame-ancestors 'none' (কেউ না) বা 'self' (শুধু নিজে), আর পুরোনো ব্রাউজারের জন্য X-Frame-Options: DENY বা SAMEORIGIN. দুটি থাকলে আধুনিক ব্রাউজার frame-ancestors মানে।

Cookie-র তিনটি flag, আর token কোথায় রাখবেন

পর্ব ৪০-এ cookie-র গঠন দেখেছেন; নিরাপত্তার দিক থেকে session cookie-তে তিনটি flag দরকার: HttpOnly (JavaScript-এর document.cookie পড়তে পারে না — XSS হলেও cookie চুরি হয় না), Secure (শুধু HTTPS-এ যায়), আর SameSite=Lax বা Strict (CSRF কমায়)।

লগইনের token কোথায় রাখবেন? localStorage-এ রাখা সহজ, আর CSRF-এর ঝুঁকি নেই (ব্রাউজার নিজে পাঠায় না)। কিন্তু একই origin-এর যেকোনো JavaScript সেটি পড়তে পারে — একটি XSS বা দূষিত npm package মানে token চুরি। HttpOnly cookie-তে রাখলে JavaScript token দেখতেই পায় না; তবে CSRF-এর প্রতিরক্ষা (SameSite + token) লাগে। তবে XSS হলে ঢোকানো কোড দুই ক্ষেত্রেই পাতা খোলা থাকা পর্যন্ত ব্যবহারকারীর হয়ে অনুরোধ পাঠাতে পারে — HttpOnly চুরি থামায়, সব ক্ষতি নয়। তাই অধিকাংশ ওয়েব অ্যাপের জন্য প্রস্তাবিত পথ: HttpOnly + Secure + SameSite session cookie, স্বল্পমেয়াদি session, আর আগে XSS ঠেকানো।

৮ · আপনার কোডের বাইরের ঝুঁকি — গোপন key, supply chain, HTTPS আর security header

গোপন key front-end-এ থাকে না

পর্ব ৩৫-এর নিয়মটি আবার: ব্রাউজারে পাঠানো সব কোড প্রকাশ্য। Minify করা bundle-ও পড়া যায়, আর .env ফাইলের মান build-এর সময় bundle-এ ঢুকে গেলে (যেমন Vite-এর VITE_ উপসর্গের মান) সেটিও প্রকাশ্য। পেমেন্টের secret, AI সেবার API key, ডেটাবেসের পাসওয়ার্ড — সব থাকবে সার্ভারে; ব্রাউজার ডাকবে আপনার নিজের API, আর সেটি key ব্যবহার করবে।

Supply chain — আপনি যার ওপর নির্ভর করেন

একটি সাধারণ React প্রকল্পে শত শত, কখনো হাজারের বেশি npm package থাকে (পর্ব ৪৬) — আর প্রতিটির কোড আপনার পাতায় আপনার origin-এর পূর্ণ ক্ষমতা নিয়ে চলে। আক্রমণকারী তাই প্রায়ই সরাসরি আপনার কোডে নয়, আপনার নির্ভরতায় হাত দেয় — একে বলে supply-chain attack. ২০১৮ সালের event-stream ঘটনা (ভাবনার প্রশ্ন ৫) এর পরিচিত উদাহরণ। ২০২৪ সালে পুরোনো ব্রাউজারের জন্য polyfill দেওয়া জনপ্রিয় CDN সেবা polyfill.io-র domain নতুন মালিকের হাতে যায়, এবং জুন মাসে দেখা যায় সেখান থেকে কিছু দর্শকের কাছে ক্ষতিকর কোড পাঠানো হচ্ছে, যা তাঁদের অন্য সাইটে পাঠিয়ে দিত।

প্রতিরক্ষার অভ্যাসগুলো সরল, কিন্তু নিয়মিত পালন করতে হয়:

• Lockfile commit করুন (package-lock.json), আর CI-তে npm install নয়, npm ci — ঠিক একই version আর hash ইনস্টল হবে; কেউ নতুন version প্রকাশ করলেও আপনার build নিজে থেকে বদলাবে না।
• npm audit নিয়মিত চালান (বা GitHub-এর Dependabot-এর মতো স্বয়ংক্রিয় ব্যবস্থা); নতুন package যোগের আগে দেখুন কে রক্ষণাবেক্ষণ করেন, কত পুরোনো, আসলেই দরকার কি না — ছোট কাজে নিজের ছোট function অনেক সময় নিরাপদ।
• CDN থেকে script নিলে SRI দিন: <script src="https://cdn…/lib.min.js" integrity="sha384-…" crossorigin="anonymous">. ব্রাউজার ফাইলের hash মেলায়; এক byte বদলালেও ফাইলটি চলে না। SRI-র সীমা: যে সেবা ব্রাউজারভেদে আলাদা ফাইল পাঠায় (polyfill.io ঠিক এমন ছিল), সেখানে স্থির hash দেওয়াই যায় না — তখন ফাইলটি নিজের সার্ভারে রাখাই নিরাপদ।

আগের পর্বের দুটি ঝুঁকি, নিরাপত্তার চোখে

Prototype pollution (পর্ব ১৮ আর ২৫): বাইরের JSON-এর __proto__ key দিয়ে কোনো merge function Object.prototype-এ মান বসিয়ে দিলে পুরো অ্যাপের প্রতিটি object-এ সেই property দেখা দেয় — কখনো isAdmin-এর মতো যাচাই ভেঙে যায়। প্রতিরক্ষা: বাইরের key-এর জন্য Map বা Object.create(null), আর বিশ্বস্ত, হালনাগাদ merge library. ReDoS (পর্ব ৩০): দুর্বল regex-এ একটি লম্বা ইনপুট main thread বা Node সার্ভারকে মিনিটের পর মিনিট আটকে রাখতে পারে — ইনপুটের দৈর্ঘ্য সীমিত করুন আর nested quantifier এড়ান। আর eval — কখনো বাইরের ডেটায় নয়।

HTTPS সবখানে, আর HSTS

HTTPS ছাড়া উপরের সবকিছু অর্থহীন: পাবলিক Wi-Fi-তে পথের যে কেউ http পাতায় নিজের script ঢুকিয়ে দিতে বা cookie পড়ে নিতে পারে। Service worker-এর মতো অনেক আধুনিক Web API (পর্ব ৪৪) শুধু HTTPS-এ চলে। কিন্তু প্রথমবার কেউ shop.com.bd লিখলে ব্রাউজার http:// দিয়ে শুরু করতে পারে, আর সেই প্রথম অনুরোধটি পথে আটকানো যায়। HSTS header (Strict-Transport-Security: max-age=31536000; includeSubDomains) ব্রাউজারকে বলে: এক বছর ধরে এই সাইটে শুধু HTTPS.

Security header-এর চেকলিস্ট

এই security header-গুলো বসে সার্ভার, CDN বা hosting-এর কনফিগারেশনে (যেমন Apache-র .htaccess, Nginx, বা Express-এর helmet middleware — পর্ব ৫০)। পুরোনো পরামর্শে আরেকটি header দেখবেন — X-XSS-Protection. এটি ব্রাউজারের পুরোনো “XSS auditor” চালু করত, যা Chrome ২০১৯ সালে সরিয়ে দিয়েছে; আজ এর কোনো উপকার নেই, CSP-ই উত্তরসূরি।

OWASP Top 10 — front-end-এর চোখে

OWASP Top 10 হলো ওয়েব অ্যাপের প্রধান ঝুঁকির বহুল ব্যবহৃত তালিকা। এর ২০২১ সংস্করণের কয়েকটি বিভাগ এই পর্বের সাথে সরাসরি মেলে: Injection (XSS এখানে অন্তর্ভুক্ত) → অংশ ৪–৫; Broken Access Control → “client-কে বিশ্বাস নয়”, অনুমতি-যাচাই সার্ভারে, CORS ভুল কনফিগারেশন; Security Misconfiguration → CORS-এ *, দুর্বল CSP, header না থাকা; Vulnerable and Outdated Components আর Software and Data Integrity Failures → npm, CDN, SRI, lockfile; Cryptographic Failures → HTTPS, HSTS. পরের সংস্করণে software supply chain-এর ঝুঁকি আরও গুরুত্ব পেয়েছে; owasp.org-এ সর্বশেষ সংস্করণটি দেখে নিন।

৯ · AI-এর যুগে — AI-এর লেখা কোডে নিরাপত্তার ফাঁক

AI-কে “রিভিউ দেখানোর একটি অংশ বানাও” বললে কোড চমৎকার চলবে — পরীক্ষায় কেউ তো <img onerror> লেখেন না। নিরাপত্তার বাগ ডেমোতে দেখা যায় না; দেখা যায় যখন কেউ ইচ্ছা করে খোঁজেন। আর AI শিখেছে ইন্টারনেটের পুরোনো, অসাবধান কোড থেকেও। যে ভুলগুলো বারবার দেখা যায়:

AI-এর লেখা কোড — নিরাপত্তা যাচাইয়ের চেকলিস্ট

• কোডে innerHTML, outerHTML, insertAdjacentHTML, document.write, eval, new Function খুঁজেছি; প্রতিটিতে কোন ডেটা যায় তা জানি
• ব্যবহারকারীর দেওয়া URL new URL() দিয়ে যাচাই, শুধু http:/https:; framework-এর dangerouslySetInnerHTML/v-html-এ শুধু sanitize করা HTML
• CORS-এ *-এর সাথে credentials নেই, origin হুবহু ফেরত দেওয়া নেই — অনুমোদিত তালিকা আছে
• CSP-তে 'unsafe-inline'/'unsafe-eval' নেই; inline onclick নেই
• Session cookie HttpOnly; Secure; SameSite; অবস্থা-বদলানো কাজ GET-এ নয়, CSRF token বা Origin যাচাই আছে
• কোনো secret front-end bundle বা প্রকাশ্য env-এ নেই; নতুন npm package-এর প্রয়োজন আর রক্ষণাবেক্ষণ দেখেছি; CDN script-এ SRI
• নিজে পরীক্ষা করেছি: রিভিউ, সার্চ আর website ঘরে <b>x</b> ও javascript: লিখে দেখেছি — লেখা হিসেবেই দেখায়