অ্যাপের নিরাপত্তা তালিকা — CORS, CSRF, XSS, header আর dependency

১ · তালিকা ধরে অ্যাপের ভেতর দিয়ে হাঁটা

“বাজারঘর”-এর login, permission, order, সব তৈরি। শুক্রবার সকালে প্রথম বড় অফার। বৃহস্পতিবার রাতে একটিই প্রশ্ন: যা বানিয়েছি, তা কি নিরাপদ? “মনে হয়” এর উত্তর নয়। এখানে যাচাইয়ের মতো একটি তালিকা লাগে।

তত্ত্ব এখানে আবার শেখানো হবে না। ঝুঁকির পুরো মানচিত্র আছে OWASP Top 10 পর্বে, browser-এর নিয়ম Web-এর নিরাপত্তা মডেল পর্বে। আমরা শুধু নির্মাতার কাজটি করব: নিজের কোডে খোঁজা, সারানো, আবার মাপা। সব run নিজের লোকাল ল্যাবে, নিজের অ্যাপের ওপর। অন্যের সিস্টেমে অনুমতি ছাড়া পরীক্ষা করা অন্যায় আর বেআইনি হতে পারে।

OWASP-এর সাইটে লেখার সময়ের সর্বশেষ তালিকাটি Top 10:2025. প্রতিটি বিভাগ বাজারঘরের কোথায় পড়ে, দেখে নিন:

ল্যাবের অ্যাপ একটিই, দুটি রূপে। MODE=before-এ সাধারণ তাড়াহুড়োর কোড; MODE=after-এ শক্ত করা। এতে প্রতিটি সারানোর প্রভাব সরাসরি মাপা যায়। লেখার সময়ের version: Node 24.15.0, Express 5.3.0, React 19.3.1, Vite 8.3.5, helmet 8.3.0, cors 2.8.6, csrf-csrf 4.1.0, DOMPurify 3.4.17, express-rate-limit 8.7.2, pino 10.4.0, npm 11.12.1, Edge 156 (Playwright দিয়ে চালানো)। এগুলো বদলায়, তাই নিজের package.json মিলিয়ে নেবেন।

২ · React-এ XSS — JSX কী ঢাকে, কী ঢাকে না

পণ্যের নিচে ক্রেতার মন্তব্য, এই একটি ফিচারেই stored XSS-এর ঝুঁকি। XSS কীভাবে কাজ করে, তা XSS প্রতিরক্ষা পর্বে আছে। JSX-এর escaping-এর ভিত্তি দেখেছেন পর্ব ৮-এ। এখন নিরীক্ষকের চোখে দেখা যাক, একটি মন্তব্য database থেকে পর্দায় আসার পথে কোথায় কী ঘটে। নিচের মানগুলো ল্যাবের আসল run-এর। মন্তব্যের ভেতরের কোড ক্ষতিহীন: এটি শুধু পাতার শিরোনাম বদলানোর চেষ্টা করে।

{"text":"<img src=x onerror=\"…\"><b>ভালো চাল</b>"}

id │ text
 1 │ <img src=x onerror="…"><b>ভালো চাল</b>

[{"id":1,"text":"<img src=x onerror=\"…\">…"}]
browser এটিকে HTML হিসেবে পড়ে না

<p id="c">&lt;img src=x onerror="…"&gt;&lt;b&gt;ভালো চাল&lt;/b&gt;</p>
banner: বাজারঘর

<p id="c"><img src="x" onerror="…"><b>ভালো চাল</b></p>
banner: CHANGED

নিজের চোখে দেখুন। নিচের ব্লকে আসল React চলছে। একই লেখা দুই পথে দেখানো হলো। লেখাটি বদলে পরীক্ষা করতে পারেন।

<div id="root"></div>
<p id="status">অবস্থা: কিছু বদলায়নি</p>
<script src="../course-kit/vendor/react-lab.js"></script>
<script type="text/jsx">
// ক্ষতিহীন নমুনা: এটি শুধু নিচের লেখাটি বদলানোর চেষ্টা করে
const change = "document.getElementById('status').textContent='অবস্থা: লেখা বদলে গেছে'";
const comment = `<b>ভালো চাল</b><img src="data:,x" onerror="${change}">`;

function Shop() {
  useEffect(() => {
    const count = (id) => document.getElementById(id).children.length;
    console.log("JSX child elements:", count("safe"));
    console.log("dangerouslySetInnerHTML child elements:", count("raw"));
    setTimeout(() => console.log(document.getElementById("status").textContent), 60);
  }, []);
  return (
    <>
      <h4>JSX: {"{comment}"}</h4>
      <p id="safe">{comment}</p>
      <h4>dangerouslySetInnerHTML</h4>
      <p id="raw" dangerouslySetInnerHTML={{ __html: comment }} />
    </>
  );
}
createRoot(document.getElementById('root')).render(<Shop />);
</script>

HTML সত্যিই দেখাতে হলে: DOMPurify

ধরুন বিক্রেতা পণ্যের বিবরণে <b> ব্যবহার করতে পারবেন। তখন নিজে regex লিখবেন না। DOMPurify browser-এর নিজের parser দিয়ে HTML ভাঙে আর শুধু অনুমোদিত অংশ রাখে। Cure53 দলের এই library বহুল ব্যবহৃত। সংক্ষিপ্ত allowlist দিন:

import DOMPurify from 'dompurify';

const PURIFY = { ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p', 'br'], ALLOWED_ATTR: [] };

function RichText({ html }) {
  return <p dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(html, PURIFY) }} />;
}

সত্যিকারের run (Edge 156, DOMPurify 3.4.17, একই ডেটা, তিনটি পথ):

== safe
  banner: বাজারঘর
  html: <p id="c">&lt;img src=x onerror="…"&gt;&lt;b&gt;ভালো চাল&lt;/b&gt;</p>
== raw
  banner: CHANGED
  html: <p id="c"><img src="x" onerror="…"><b>ভালো চাল</b></p>
== clean
  banner: বাজারঘর
  html: <p id="c"><b>ভালো চাল</b></p>

DOMPurify img ফেলে দিয়েছে, <b> রেখেছে। এটিই sanitize: বৈধ অংশ থাকে, বাকিটা যায়।

href="javascript:" — React 19 কী করে

দোকানের ওয়েবসাইট ঘরে কেউ javascript: দিয়ে শুরু হওয়া লেখা দিতে পারেন। JSX-এর escaping এখানে কাজ করে না, কারণ মানটি বৈধ attribute. Edge-এ আসল ফল:

== link  (<a href={c.website}>, React 19.3.1)
  href attr: javascript:throw new Error('React has blocked a javascript: URL as a security precaution.')
  click করার পর:
  pageerror: React has blocked a javascript: URL as a security precaution.
  banner: বাজারঘর
== safelink  (<a href={safeHref(c.website)}>)
  href attr: None
  banner: বাজারঘর

React 19 নিজেই মানটি বদলে দিল। পুরোনো version-এ এই সুরক্ষা ছিল না, শুধু development warning ছিল। তবু নিজের যাচাই রাখুন, কারণ location.href = url বা window.open(url)-এ React হাত দেয় না। আর allowlist সবচেয়ে পরিষ্কার পথ:

export function safeHref(raw) {
  try {
    const u = new URL(raw, location.origin);
    return ['http:', 'https:'].includes(u.protocol) ? u.href : undefined;
  } catch { return undefined; }
}

৩ · CSP — helmet, nonce আর Report-Only

ধরে নিন, সব মিলিয়েও একটি ভুল থেকে গেল। Content Security Policy হলো দ্বিতীয় দেয়াল: কোন script চলতে পারবে, সেটি browser-কে আগেই বলে দেওয়া। helmet এই header বসায়। Vite-এর build-এ script আলাদা ফাইলে, তাই 'self' অনেকটা কাজ সারে। কিন্তু পাতায় ছোট inline script থাকলে দরকার nonce, প্রতি response-এ নতুন একটি এলোমেলো মান।

app.use((req, res, next) => {
  res.locals.cspNonce = randomBytes(16).toString('base64');
  next();
});

app.use(helmet({
  contentSecurityPolicy: {
    reportOnly: MODE === 'reportonly',
    directives: {
      scriptSrc: ["'self'", (req, res) => `'nonce-${res.locals.cspNonce}'`],
      styleSrc: ["'self'"],
      imgSrc: ["'self'", 'data:'],
      connectSrc: ["'self'"],
      reportUri: ['/api/csp-report'],
    },
  },
}));

// নিজের static template-এর জানা জায়গায় nonce বসানো
app.get('/', (req, res) =>
  res.type('html').send(html.replaceAll('__CSP_NONCE__', res.locals.cspNonce)));

helmet-এর docs অনুযায়ী আপনার directives ডিফল্টের সাথে মেশে। তাই script-src-attr 'none', object-src 'none', base-uri 'self' নিজে থেকেই থাকে। আমরা ডিফল্টের ঢিলা style-src-ও কড়া করেছি। ল্যাব HTTP-তে চলে বলে upgrade-insecure-requests বন্ধ রাখা হয়েছিল; production-এ ডিফল্ট রাখুন। নিচে helmet ছাড়াই nonce-এর মূল কৌশলটি দেখুন।

const http = require("node:http");
const { randomBytes } = require("node:crypto");

const cspHeader = (nonce) => [
  "default-src 'self'",
  `script-src 'self' 'nonce-${nonce}'`,
  "script-src-attr 'none'",
  "object-src 'none'",
  "base-uri 'self'",
].join("; ");

const server = http.createServer((req, res) => {
  const nonce = randomBytes(16).toString("base64"); // প্রতি response-এ নতুন
  res.setHeader("Content-Security-Policy", cspHeader(nonce));
  res.end(`<script nonce="${nonce}">startShop()</script>`);
});

server.listen(0, "127.0.0.1", async () => {
  const url = `http://127.0.0.1:${server.address().port}/`;
  const seen = [];
  for (let i = 1; i <= 2; i++) {
    const r = await fetch(url);
    const header = r.headers.get("content-security-policy");
    const inHeader = header.match(/nonce-([^']+)/)[1];
    const inHtml = (await r.text()).match(/nonce="([^"]+)"/)[1];
    seen.push(inHeader);
    console.log(`#${i} match: ${inHeader === inHtml}, length: ${inHeader.length}`);
    if (i === 1) console.log(header.replace(inHeader, "<nonce>"));
  }
  console.log("same nonce twice:", seen[0] === seen[1]);
  server.close();
});

এবার Edge-এ একই মন্তব্য, কাঁচা পথে (view=raw), কিন্তু CSP চালু। ইচ্ছা করেই ভুল কোড রাখা হয়েছে, দেয়াল পরীক্ষার জন্য। সত্যিকারের console (লম্বা অংশ ছোট করা):

MODE=after, enforce
  console: log nonce script ran
  console: error Executing inline event handler violates the following Content Security Policy directive 'script-src-attr 'none''. … The action has been blocked.
  banner: বাজারঘর

MODE=reportonly
  console: log nonce script ran
  console: info Executing inline event handler violates the following Content Security Policy directive 'script-src-attr 'none''. … The policy is report-only, so the violation has been logged but no further action has been taken.
  banner: CHANGED

তিনটি জিনিস লক্ষ করুন। nonce script ran: বৈধ inline script চলেছে। DOM-এ img ঢুকেছিল, অর্থাৎ React-এর ভুলটি রয়ে গেছে; CSP শুধু কোড চলা থামিয়েছে। আর Report-Only-এ কিছুই থামে না, শিরোনাম বদলে গেছে, শুধু খবর আসে। তাই এটি মাপার যন্ত্র, সুরক্ষা নয়। Rollout-এর কৌশল আছে XSS পর্বের ৮ নম্বর অংশে।

ব্যস্ত দিনে এমন একটি বার্তা এলে কীভাবে পড়বেন? নিচের ধাপে ল্যাবের আসল বার্তা আর আসল report.

Executing inline event handler violates the
following Content Security Policy directive
'script-src-attr 'none''. …
The action has been blocked.

{"csp-report":{
 "document-uri":"http://localhost:47510/?view=raw",
 "violated-directive":"script-src-attr",
 "disposition":"report",
 "blocked-uri":"inline", …}}

"source-file":"http://localhost:47510/assets/
  index-vowwMYDM.js",
"line-number":9, "column-number":1792

script-src-attr 'unsafe-inline'   ✗ দেয়াল ভাঙা
dangerouslySetInnerHTML + DOMPurify  ✓
অথবা শুধু {c.text}                ✓

৪ · CSRF — SameSite, token আর Fetch Metadata

Cookie-ভিত্তিক login (পর্ব ৪৫) থাকলে browser নিজে থেকে cookie পাঠায়। CSRF-এর মূল সমস্যা এটিই; তত্ত্ব আছে CSRF আর cookie সুরক্ষা পর্বে। প্রশ্ন একটিই: SameSite=Lax দিলেই কি হয়ে গেল? ল্যাবে মেপে দেখি। বাজারঘরে login করা একটি Edge-এ, অন্য একটি লোকাল পাতার সাধারণ HTML form নিজের ল্যাবের wishlist-এ POST করল। ল্যাবে 127.0.0.1 থেকে localhost হলো অন্য site, আর localhost-এর অন্য port হলো একই site, আলাদা origin; যেমন blog.bazarghar.test আর shop.bazarghar.test.

সত্যিকারের run-এর log থেকে দ্বিতীয় সারি (Edge 156):

{"level":"info","event":"form_post","cookieSent":false,"site":"cross-site","msg":"form post"}
{"level":"info","event":"form_post","cookieSent":true,"site":"same-site","msg":"form post"}

OWASP-এর CSRF cheat sheet-ও বলে, SameSite defense in depth হিসেবে ভালো, তবে বেশিরভাগ deployment-এ আসল প্রতিরক্ষার বদলি নয়। তাহলে CSRF token কখন বাদ দেওয়া যায়? শুধু Authorization: Bearer header-এ login চললে, cookie নেই বলে browser কিছু নিজে পাঠায় না, তাই CSRF প্রযোজ্য নয়। Cookie থাকলেই token বা Fetch Metadata রাখুন।

Token-এর কৌশল: server HMAC দিয়ে session-এর সঙ্গে বাঁধা একটি মান বানায়। পাতার JavaScript সেটি header-এ পাঠায়, যা অন্য site পড়তে বা বসাতে পারে না। node:http-এ পুরো কৌশলটি:

const http = require("node:http");
const { createHmac, timingSafeEqual } = require("node:crypto");
const SECRET = "example-secret-not-real";
const sign = (sid, random) =>
  createHmac("sha256", SECRET).update(`${sid}!${random}`).digest("hex");
const makeToken = (sid, random) => `${sign(sid, random)}.${random}`;
function validToken(sid, token = "") {
  const [tag, random] = token.split(".");
  if (!tag || !random) return false;
  const a = Buffer.from(tag), b = Buffer.from(sign(sid, random));
  return a.length === b.length && timingSafeEqual(a, b);
}

const server = http.createServer((req, res) => {
  const sid = (req.headers.cookie ?? "").replace("sid=", "");
  const ok = validToken(sid, req.headers["x-csrf-token"]);
  res.statusCode = ok ? 201 : 403;
  res.end(ok ? "added" : "invalid csrf token");
});

server.listen(0, "127.0.0.1", async () => {
  const url = `http://127.0.0.1:${server.address().port}/wishlist`;
  async function send(label, sid, token) {
    const headers = { cookie: `sid=${sid}`, ...(token && { "x-csrf-token": token }) };
    const r = await fetch(url, { method: "POST", headers });
    console.log(label.padEnd(24), r.status, await r.text());
  }
  const mine = makeToken("sess-rahim", "r4nd0m");
  console.log("token:", mine.slice(0, 16) + "..." + mine.slice(-7));
  await send("no token", "sess-rahim");
  await send("wrong token", "sess-rahim", "abc.r4nd0m");
  await send("token of other session", "sess-karim", mine);
  await send("own token", "sess-rahim", mine);
  server.close();
});

POST /wishlist
cookie: sid=sess-rahim
x-csrf-token: 97f0a2b6c2b3ea48….r4nd0m

tag    = 97f0a2b6c2b3ea48…
random = r4nd0m

HMAC(SECRET, "sess-rahim!r4nd0m")
= 97f0a2b6c2b3ea48…

tag === হিসাব → 201 added

cookie: sid=sess-karim
HMAC(SECRET, "sess-karim!r4nd0m") ≠ 97f0a2b6c2b3ea48…
→ 403 invalid csrf token

বাস্তবে: csrf-csrf আর Fetch Metadata

পুরোনো csurf package এখন archived, npm-এ লেখা আছে এটি আর রক্ষণাবেক্ষণ হয় না। csrf-csrf তার একটি পরিচিত বিকল্প, যা signed double-submit cookie করে (লেখার সময় 4.1.0). README বলে, পুরো session-নির্ভর app-এ লেখকের csrf-sync (synchronizer token) বেশি মানায়; JWT বা stateless হলে এটি। হাতে লেখা কোড শেখার জন্য ভালো, production-এ পরীক্ষিত library নিন।

import { doubleCsrf } from 'csrf-csrf';

const { doubleCsrfProtection, generateCsrfToken } = doubleCsrf({
  getSecret: () => config.CSRF_SECRET,
  getSessionIdentifier: (req) => req.sessionId ?? '',
  cookieName: '__Host-bazarghar.csrf',
  cookieOptions: { sameSite: 'lax', secure: true, path: '/' },
});

function fetchMetadataGuard(req, res, next) {
  if (['GET', 'HEAD', 'OPTIONS'].includes(req.method)) return next();
  const site = req.get('sec-fetch-site');
  const origin = req.get('origin');
  // header না এলে Origin-এ ফেরা (পুরোনো browser, curl)
  const ok = site ? site === 'same-origin' : (!origin || origin === APP_ORIGIN);
  if (ok) return next();
  log.warn({ event: 'csrf_rejected', site, origin, path: req.path }, 'blocked');
  res.status(403).json({ error: 'cross_site_blocked' });
}

app.get('/api/csrf-token', (req, res) =>
  res.json({ csrfToken: generateCsrfToken(req, res) }));
app.post('/api/wishlist', fetchMetadataGuard, doubleCsrfProtection, addToWishlist);

Sec-Fetch-Site browser নিজে বসায়, পাতার JavaScript বদলাতে পারে না। এটি খুব সস্তা একটি প্রথম ছাঁকনি। OWASP-এর cheat sheet শুধু আধুনিক browser-এর জন্য এর ওপর নির্ভরের অনুমতি দেয়, তবে Origin-এ fallback বাধ্যতামূলক রেখে। মনে রাখবেন, এই header শুধু নিরাপদ context-এ আসে, মানে HTTPS বা localhost. উপরের কোডের __Host- prefix আর secure: true হলো HTTPS-এর রূপ, যা README-র পরামর্শ। লোকাল HTTP-তে ল্যাব সাধারণ নাম আর secure: false-এ চলেছে, তাই এই দুটি মান এখানে run করা হয়নি। আর XSS থাকলে CSRF-এর সব দেয়াল অর্থহীন, কারণ কোড তখন আপনার origin থেকেই চলে। Next.js Server Action-এর নিজস্ব সুরক্ষা পর্ব ৫৪-তে আসবে।

৫ · CORS আর security header — আগে ও পরে

CORS-এর পুরো গল্প পর্ব ২৬-এ। এখানে শুধু নিরীক্ষা। সবচেয়ে বিপজ্জনক ভুলটি origin: true আর credentials: true একসাথে, যা যেকোনো origin-কে ফিরিয়ে দেয়। সত্যিকারের run, অচেনা Origin পাঠিয়ে:

# আগে
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://other.example
Access-Control-Allow-Credentials: true

# পরে
HTTP/1.1 200 OK
(Access-Control-Allow-Origin নেই)

“পরে”-তেও status 200! CORS server-এ request আটকায় না, শুধু browser-কে বলে উত্তরটি পাতাকে পড়তে দেবে কি না। তাই CORS কখনো অনুমতির বিকল্প নয়।

এবার helmet-এর আসল প্রভাব। একই অ্যাপ, curl -sI দিয়ে দুবার:

# আগে (নিরাপত্তার কিছু নেই, বরং পরিচয় জানানো)
HTTP/1.1 200 OK
X-Powered-By: Express
Vary: Origin
Access-Control-Allow-Credentials: true
Content-Type: text/html; charset=utf-8
…

# পরে (helmet 8.3.0, CSP ছোট করা)
HTTP/1.1 200 OK
Content-Security-Policy: default-src 'self';base-uri 'self';…;script-src 'self' 'nonce-QFJ3ZW21f1v+vJyqecq2Tg==';script-src-attr 'none';…
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Origin-Agent-Cluster: ?1
Referrer-Policy: no-referrer
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 0
Vary: Origin
…

১২টি header যোগ হলো, আর X-Powered-By গেল। প্রতিটির অর্থ আছে Web hardening পর্বে। তিনটি খেয়াল রাখুন। X-XSS-Protection: 0 ভুল নয়; পুরোনো browser-এর ত্রুটিপূর্ণ ফিল্টারটি ইচ্ছা করেই বন্ধ। Cross-Origin-Resource-Policy: same-origin অন্য origin থেকে আপনার ছবি লোড আটকাবে; CDN বা আলাদা frontend থাকলে এটি বদলাতে হতে পারে। আর header শুধু browser-কে দেওয়া নির্দেশ; API-তে curl চালালে এগুলো কিছুই আটকায় না।

HSTS — একবার দিলে ফেরা কঠিন

Strict-Transport-Security browser-কে বলে: এই site-এ শুধু HTTPS. max-age=31536000 মানে 31,536,000 ÷ 86,400 = ৩৬৫ দিন। RFC 6797 (২০১২) অনুযায়ী browser HTTP-তে পাওয়া এই header উপেক্ষা করে, তাই লোকাল ল্যাবে এর প্রভাব দেখা যায় না, শুধু header-টি যাচাই হয়। এটি যাচাই করতে হয় আসল HTTPS domain-এ। ঝুঁকি হলো, includeSubDomains-এ একটি subdomain HTTP-তে থাকলে সেটি এক বছর ভেঙে থাকবে। তাই ছোট মান (যেমন ৫ মিনিট) দিয়ে শুরু করে ধাপে বাড়ান। TLS-এর গভীরে যেতে Computer Networks কোর্স দেখুন।

৬ · SSRF — “URL দিয়ে ছবি” ফিচার

বিক্রেতা চান, ছবি upload না করে একটি URL দেবেন, আর বাজারঘর সেখান থেকে ছবি এনে নেবে। সহজ ফিচার, কিন্তু এখন server অন্যের কথায় বাইরে যাচ্ছে। Server নিজে ভেতরের নেটওয়ার্কে বসে থাকে, তাই সে এমন ঠিকানায় পৌঁছায়, যেখানে বাইরের কেউ পৌঁছায় না। একেই বলে SSRF, আর OWASP 2025-এ এটি A01-এর ভেতরে।

ল্যাবে 127.0.0.1:47513-এ একটি নকল “ভেতরের সেবা” রাখা হলো। “আগে”-র কোড শুধু fetch(url). সত্যিকারের run:

# আগে: ছবির ফিচার ভেতরের সেবার উত্তর ফিরিয়ে দিল
http://127.0.0.1:47513/ => {"status":200,"type":"application/json","preview":"{\"service\":\"internal-admin\",…"} [200]
http://127.0.0.1:47514/moved.png => {"status":200,"type":"application/json","preview":"{\"service\":\"internal-admin\",…"} [200]

# পরে
http://127.0.0.1:47513/ => {"error":"image_url_refused","reason":"bad_scheme"} [400]
https://img.bazarghar.test.evil.example/a.png => {…,"reason":"host_not_allowed"} [400]
http://127.0.0.1:47514/ok.png => {"ok":true,"type":"image/png","bytes":70} [200]
http://127.0.0.1:47514/moved.png => {…,"reason":"redirect_refused"} [400]
http://127.0.0.1:47514/page.html => {…,"reason":"bad_type"} [400]
http://127.0.0.1:47514/big.png => {…,"reason":"too_large"} [400]

দ্বিতীয় সারিটি দেখুন: একটি ছবির ঠিকানা redirect হয়ে ভেতরে চলে গেল। তাই শুরুর URL যাচাই যথেষ্ট নয়। 47514 ল্যাবের নকল CDN; শুধু এই একটি origin-এ ল্যাবের কোডে HTTPS আর host-এর শর্ত শিথিল ছিল। নিচের ব্লক আসল DNS বা network ছাড়াই যাচাইয়ের নিয়ম দেখায়; fakeDns একটি সাধারণ object.

const net = require("node:net");
const ALLOWED_HOSTS = new Set(["img.bazarghar.test", "img2.bazarghar.test"]);
const blocked = new net.BlockList();
for (const [ip, bits] of [["127.0.0.0", 8], ["10.0.0.0", 8], ["172.16.0.0", 12],
  ["192.168.0.0", 16], ["169.254.0.0", 16]]) blocked.addSubnet(ip, bits, "ipv4");

// নকল DNS: কোনো network call নেই। 203.0.113.0/24 শুধু উদাহরণের ঠিকানা
const fakeDns = { "img.bazarghar.test": "203.0.113.10", "img2.bazarghar.test": "10.0.0.5" };

function check(raw) {
  let url;
  try { url = new URL(raw); } catch { return "REFUSE bad_url"; }
  if (url.protocol !== "https:") return "REFUSE bad_scheme";
  if (url.username || url.password) return "REFUSE userinfo";
  const host = url.hostname.replace(/[[\]]/g, "");
  if (net.isIP(host)) return `REFUSE ip_literal (${host})`;
  if (!ALLOWED_HOSTS.has(host)) return "REFUSE host_not_allowed";
  const ip = fakeDns[host];
  if (blocked.check(ip, "ipv4")) return `REFUSE blocked_address (${ip})`;
  return `ALLOW ${ip}`;
}

for (const u of [
  "https://img.bazarghar.test/chal.png",
  "http://img.bazarghar.test/chal.png",
  "https://127.0.0.1/admin",
  "https://2130706433/admin",
  "https://[::1]/admin",
  "https://img.bazarghar.test@other.example/a.png",
  "https://img.bazarghar.test.other.example/a.png",
  "https://img2.bazarghar.test/a.png",
  "file:///etc/hosts",
]) console.log(u.padEnd(47), check(u));

একটি সূক্ষ্ম ফাঁক বাকি। নাম যাচাইয়ের সময় DNS এক ঠিকানা দিল, আর সংযোগের সময় আরেকটি। একে DNS rebinding বলে। সমাধান হলো যাচাইকে সংযোগের মুহূর্তে আনা: node:http-এর lookup option-এ নিজের ফাংশন দিন।

// socket সংযোগের ঠিক আগে এটি ডাকে, তাই যাচাই করা ঠিকানাতেই সংযোগ
function safeLookup(host, options, cb) {
  dns.lookup(host, { ...options, all: true }, (err, list) => {
    if (err) return cb(err);
    if (list.some((a) => isBlocked(a.address))) {
      return cb(new SsrfError('blocked_address', host));
    }
    if (options.all) return cb(null, list);
    cb(null, list[0].address, list[0].family);
  });
}

const req = https.get(url, { lookup: safeLookup, timeout: 3000 }, (res) => {
  if (res.statusCode >= 300 && res.statusCode < 400) {
    res.destroy();
    return reject(new SsrfError('redirect_refused', url.hostname));
  } // এরপর content-type-এর allowlist আর ২ MB সীমা
});

সত্যিকারের run: localhost-কে সাময়িকভাবে তালিকায় রেখে চালালে উত্তর এলো allowlisted name, loopback answer => blocked_address. net.BlockList ::ffff:127.0.0.1-কেও ধরল। ভালো ব্যবস্থা আরও একটি স্তর চায়: server-এর বাইরে যাওয়ার পথে firewall, আর ছবিগুলো নতুন করে encode করা (পর্ব ৩০)। সবচেয়ে সহজ পথ হলো ফিচারটিই না রাখা; বিক্রেতার browser থেকে সরাসরি upload.

৭ · Client bundle-এ secret আর SQL injection

Browser-এ যা যায়, তা সবার। পর্ব ৫-এ দেখেছিলেন, VITE_ prefix-ওয়ালা মান build-এ ঢুকে যায়। এটি ফাঁকি নয়, Vite-এর নকশা। একজন তাড়াহুড়ো করে payment key এভাবে লিখলে কী হয়? .env-এ দুটি নকল মান রেখে আসল build:

$ cat .env
VITE_PAYMENT_SECRET=example-secret-gateway-key-0001
PAYMENT_SERVER_KEY=example-server-only-key-0002

$ npx vite build
$ grep -rlE 'example-secret|example-server-only' dist
dist/assets/index-BoiqcFIz.js
$ grep -oE '.{30}example-secret[a-z0-9-]*.{10}' dist/assets/*.js
),window.__g={url:`/api`,key:`example-secret-gateway-key-0001`,server:v
$ grep -c 'example-server-only' dist/assets/*.js
0

# VITE_ মানটি সরিয়ে, payment-এর কাজ server-এ নিয়ে আবার build
$ grep -rlE 'example-secret|example-server-only' dist
$ echo $?
1

Prefix-ওয়ালা মান minify হওয়া ফাইলেও খোলা। Prefix ছাড়া PAYMENT_SERVER_KEY ঢোকেনি। grep-এর exit code 1 মানে কিছু মেলেনি, আর CI-তে এই একটি লাইনই build থামাতে পারে। Source map production-এ দিলে পুরো মূল কোডও পাঠানো হয়। Secret-এর মানগুলো পর্ব ৭৮-এ আরও গুছিয়ে আসবে। মনে রাখবেন, ফাঁস হওয়া key মুছলেই শেষ নয়; নতুন key বানিয়ে পুরোনোটি বাতিল করুন (পর্ব ৩১)। VITE_-এ রাখা যায় শুধু যা প্রকাশ্য, যেমন API-র URL.

SQL injection — আগেই সামলানো

SQL injection-এর সমাধান নতুন করে লাগে না, শুধু যাচাই লাগে। ORM আর parameterized query আছে পর্ব ৩৮-এ, আর filter-এর allowlist পর্ব ৩৪-এ। নিরীক্ষায় খুঁজুন $queryRawUnsafe, $executeRawUnsafe আর SQL-এর ভেতরে string জোড়া। Sort-এর কলামের নাম placeholder-এ বসে না, তাই সেখানে allowlist. তত্ত্ব আছে Injection প্রতিরক্ষা পর্বে।

৮ · Dependency — অন্যের কোডের হিসাব

ল্যাবের ছোট অ্যাপেই npm ls --all ২২১ লাইন দেখাল। এর বেশিরভাগ কোড আপনি কখনো পড়েননি। A03 Software Supply Chain Failures ২০২৫ সালের তালিকায় তিন নম্বরে। প্রথম কাজ npm audit: এটি আপনার lockfile-এর version-গুলো পরিচিত দুর্বলতার তালিকার সাথে মেলায়। পুরোনো package রেখে একটি আলাদা ফোল্ডারে আসল run:

$ npm audit
# npm audit report

esbuild  <=0.24.2
Severity: moderate
esbuild enables any website to send any requests to the development server and read the response - https://git…
fix available via `npm audit fix --force`
Will install vite@5.4.21, which is outside the stated dependency range
node_modules/esbuild
  vite  <=6.4.3
  Depends on vulnerable versions of esbuild
  node_modules/vite

lodash  <=4.17.23
Severity: high
Command Injection in lodash - https://github.com/advisories/GHSA-35jh-r3h4-6jhm
…
minimist  1.0.0 - 1.2.5
Severity: critical
Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h
…

4 vulnerabilities (1 moderate, 2 high, 1 critical)
$ echo $?
1

কীভাবে পড়বেন? esbuild-এর সমস্যা dev server-এর, যা production-এ চলে না। Production-এর ছবি দেখায় npm audit --omit=dev. আর --audit-level=high ঠিক করে কোন মাত্রায় CI ব্যর্থ হবে। “critical” মানে সবসময় “আপনার অ্যাপে এখনই বিপদ” নয়; দুর্বল ফাংশনটি আপনি ডাকেন কি না, সেটিও দেখতে হয়। আবার অন্ধভাবে npm audit fix --force চালালে major version লাফ দিতে পারে, অ্যাপ ভাঙতে পারে। আমরা তিনটি package নিয়ন্ত্রিতভাবে বদলালাম (lodash@4.18.1, minimist@1.2.8, vite@8.3.5), তারপর found 0 vulnerabilities. আর মূল ল্যাবে:

$ npm audit
found 0 vulnerabilities
$ npm audit signatures
107 packages have verified registry signatures
22 packages have verified attestations

Lockfile আর npm ci

Lockfile ঠিক কোন version আর hash, তা লিখে রাখে (পর্ব ৫)। CI আর production-এ npm install নয়, npm ci: এটি lockfile মেনে চলে, না মিললে থেমে যায়। আসল run, package.json-এ একটি নতুন package হাতে যোগ করে:

$ npm ci
npm error code EUSAGE
npm error `npm ci` can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. …
npm error Missing: dayjs@1.11.13 from lock file

Supply chain — যখন package নিজেই ক্ষতিকর

npm audit জানা দুর্বলতা খোঁজে। কিন্তু কেউ যদি জনপ্রিয় package-এর নতুন version-এ ক্ষতিকর কোড ঢোকায়? প্রকাশিত কয়েকটি ঘটনা:

• event-stream, ২০১৮: দায়িত্ব নতুন একজনের হাতে যাওয়ার পর যুক্ত dependency-তে একটি নির্দিষ্ট cryptocurrency wallet-কে লক্ষ্য করা কোড পাওয়া যায়।
• Shai-Hulud, ২০২৫: GitHub-এর ব্লগ অনুযায়ী তারা ১৪ সেপ্টেম্বর খবর পায়। দখল হওয়া maintainer account দিয়ে post-install script ছড়ানো এই worm-এর কারণে ৫০০-র বেশি package সরানো হয়।
• axios, ২০২৬: Datadog Security Labs-এর বিশ্লেষণ অনুযায়ী ৩১ মার্চ maintainer account থেকে দুটি ক্ষতিকর version বের হয়, যা নতুন একটি dependency-র postinstall চালাত। প্রায় তিন ঘণ্টা পরে npm সেগুলো সরায়। পেছনে কে ছিল, এ নিয়ে বিভিন্ন সংস্থার মূল্যায়ন আছে; চূড়ান্ত কিছু ধরে নেবেন না।

React নিজেও বাইরে নয়। React-এর blog অনুযায়ী ২০২৫ সালের ডিসেম্বরে Server Components-এ CVE-2025-55182 প্রকাশ পায়, CVSS 10.0; সংশোধন আসে 19.0.1, 19.1.2 আর 19.2.1-এ। Client-only অ্যাপ এতে আক্রান্ত ছিল না, তবে শিক্ষা হলো: জরুরি patch দ্রুত নেওয়ার পথ তৈরি রাখুন।

ঘটনাগুলোর একটি মিল: postinstall আর “মাত্র বের হওয়া version”. প্রতিরক্ষাও সেখানেই। দুটিই আসল run:

# একটি ক্ষতিহীন নিজের package, যার postinstall একটি লাইন ছাপে
$ npm i ../pkg/lab-postinstall-1.0.0.tgz --foreground-scripts
postinstall script ran
$ npm i ../pkg/lab-postinstall-1.0.0.tgz --ignore-scripts --foreground-scripts
added 1 package, and audited 2 packages in 544ms

# ৭৭ দিন আগের সর্বশেষ dayjs 1.11.23; অপেক্ষার নিয়ম ১০০ দিন
$ npm i dayjs --package-lock-only --min-release-age=100
$ node -p "require('./package-lock.json').packages['node_modules/dayjs'].version"
1.11.21

min-release-age দিনের হিসাবে একটি cooldown (npm 11.12.1-এ পরীক্ষিত)। Datadog-এর লেখাতেও কয়েক দিনের এই বিরতির পরামর্শ আছে। ignore-scripts কিছু package ভেঙে দিতে পারে, যেগুলো install-এর সময় native কোড বানায়, তাই নিজের প্রকল্পে পরীক্ষা করে নিন। আর update হাতে না করে Dependabot বা Renovate-এর মতো টুল PR খোলে, দুটিতেই ঠান্ডা হওয়ার সময় ঠিক করা যায় (Dependabot-এ cooldown, যা তার docs অনুযায়ী security update-এ খাটে না; Renovate-এ minimumReleaseAge). পুরো ছবি আছে Supply chain পর্বে; CI-তে বসানো পর্ব ৮১-তে।

৯ · Rate limit, log, পাস-ফেল তালিকা আর threat model

Rate limit

Rate limit-এর middleware দেখেছেন পর্ব ২৬-এ, আর login-এর দিক পর্ব ৪৯-এ। নিরীক্ষায় প্রমাণ চাই। ১৫ মিনিটে ৫টি চেষ্টা, আসল run (express-rate-limit 8.7.2):

HTTP/1.1 401 Unauthorized RateLimit: "5-in-15min"; r=4; t=900
HTTP/1.1 401 Unauthorized RateLimit: "5-in-15min"; r=3; t=900
HTTP/1.1 401 Unauthorized RateLimit: "5-in-15min"; r=2; t=900
HTTP/1.1 401 Unauthorized RateLimit: "5-in-15min"; r=1; t=900
HTTP/1.1 401 Unauthorized RateLimit: "5-in-15min"; r=0; t=899
HTTP/1.1 429 Too Many Requests RateLimit: "5-in-15min"; r=0; t=899 Retry-After: 899

এবার হিসাব। প্রতি ঠিকানায় ১৫ মিনিটে ৫টি মানে দিনে ৯৬ × ৫ = ৪৮০টি চেষ্টা। ধরে নেওয়া সংখ্যা: কেউ ১,০০০টি ঠিকানা থেকে চেষ্টা করলে দিনে ৪,৮০,০০০টি। ৬ অঙ্কের OTP-র ১০,০০,০০০টি সম্ভাবনার প্রায় অর্ধেক একদিনে! তাই ঠিকানার সাথে account অনুযায়ী সীমাও লাগে, আর OTP-র মেয়াদ ছোট রাখতে হয়। Proxy-র পেছনে trust proxy ঠিক না হলে সবাই এক ঠিকানা হয়ে যায়। একাধিক server থাকলে গণনা Redis-এর মতো ভাগ করা store-এ রাখুন, নইলে প্রতি server আলাদা গোনে।

নিরাপত্তার ঘটনার log

পর্ব ৩১-এর pino-তে একটি event field যোগ করলেই চলে। Password বা token নয়, শুধু কী ঘটল। আসল লাইন (সময় বাদ দিয়ে):

{"level":"warn","event":"login_rate_limited","ip":"127.0.0.1","msg":"too many logins"}
{"level":"warn","event":"csrf_rejected","reason":"fetch_metadata","site":"cross-site","origin":"http://127.0.0.1:47511","path":"/form/wishlist","msg":"blocked"}
{"level":"warn","event":"ssrf_blocked","reason":"bad_scheme","host":"127.0.0.1","msg":"image url refused"}
{"level":"warn","event":"csp_violation","directive":"script-src-attr","blocked":"inline","disposition":"enforce","sample":"","msg":"csp report"}

A09 শুধু log নয়, alert-ও চায়। একটি ঠিকানা থেকে অনেক login_failed, বা হঠাৎ csrf_rejected-এর ঢেউ, এমন নিয়মে কারও ফোনে খবর যাবে। তত্ত্ব আছে Security logging পর্বে।

চূড়ান্ত পাস-ফেল তালিকা

হাতে মেলানো তালিকা বাসি হয়ে যায়। তাই ১৬টি যাচাইকে একটি script করা হলো, যা চলমান লোকাল অ্যাপে request পাঠায়, dist পড়ে আর npm audit চালায়। একই script, দুই রূপে, আসল ফল:

সততার সাথে পড়ুন। “আগে”-র bundle আর dependency পাস করেছে, কারণ এই দুটি আমরা ৭ ও ৮ অংশে আলাদা ফোল্ডারে দেখিয়ে আগেই সারিয়েছি। A04, A06 আর A08-এর কোনো সারি নেই; সেগুলো script দিয়ে সহজে মাপা যায় না। “bad JSON” সারিতে “আগে” Express-এর ডিফল্ট পাতা ফাইলের পূর্ণ path-সহ stack trace দেখিয়েছিল, কারণ NODE_ENV=development; “পরে” শুধু {"error":"bad_request"} (পর্ব ২৮)। Script-টি শুধু লোকাল বা নিজের staging-এ চালান, আর এটি পর্ব ৮১-র CI-তে বসানো যায়।

এক পাতার threat model

Threat model তালিকার ফাঁক ধরে। Threat modeling পর্বের চারটি প্রশ্নের একটি ছোট রূপ: কী বানাচ্ছি, কী ভুল হতে পারে, কী করছি, কাজটি ভালো হলো কি? STRIDE-এর অক্ষর মনে করিয়ে দেয় কী কী ভাবতে হবে। বাজারঘরের এক পাতা:

শেষ কলামটিই আসল। যেখানে প্রমাণ নেই, সেখানে “বাকি” লিখে রাখা সবচেয়ে সৎ কাজ। ব্যবসার নিয়মের ভুল, যেমন কুপন, কোনো header ধরে না। এই পাতাটি প্রতিটি বড় ফিচারের আগে আধা ঘণ্টায় আবার দেখুন।

১০ · AI-এর যুগে অ্যাপের নিরাপত্তা

AI-এর লেখা কোড চলে, আর নিরাপত্তার ভুল চলার সময় চোখে পড়ে না। CORS-এর error এলে AI প্রায়ই origin: true দিয়ে “সমাধান” করে। CSP-র বার্তা এলে 'unsafe-inline' যোগ করে। অর্থাৎ সে error থামায়, ঝুঁকি নয়। নিচের ভুলগুলো খেয়াল রাখুন।

AI-এর লেখা কোড মেলানোর চেকলিস্ট

• Diff-এ dangerouslySetInnerHTML, unsafe-inline, origin: true খুঁজেছি
• ক্ষতিহীন HTML নমুনা পাঠিয়ে Edge বা Chrome-এ DOM দেখেছি
• Token ছাড়া POST 403 দিয়েছে, token-সহ POST কাজ করেছে
• dist-এ secret-এর নাম আর নকল মান দিয়ে grep চালিয়েছি
• নতুন package-এর নাম, deprecation আর lockfile-এর diff নিজে দেখেছি
• নিরীক্ষার script চালিয়েছি, আর যা মাপা যায়নি তা threat model-এ “বাকি” লিখেছি