Web-এর নিরাপত্তা মডেল — same-origin policy, CORS আর browser-এর সীমা

১ · Web-এ কে কাকে বিশ্বাস করে

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

Web-এর নিরাপত্তা মডেল হলো কিছু নিয়ম, যা ঠিক করে কোন পক্ষ কতটা ক্ষমতা পাবে। পক্ষ মূলত চারটি। প্রত্যেকের ওপর বিশ্বাস আলাদা।

Client থেকে আসা সবকিছুই অবিশ্বস্ত

Form-এ required লেখা, JavaScript-এ দাম হিসাব করা, বোতাম লুকিয়ে রাখা: এসবই ব্যবহারকারীর যন্ত্রে ঘটে। ব্যবহারকারী developer tools খুলে সেগুলো বদলাতে পারেন। Browser ছাড়াই সরাসরি request পাঠাতে পারেন। তাই client-side validation ভালো অভিজ্ঞতার জন্য দরকারি, কিন্তু নিরাপত্তা হিসেবে এর মূল্য শূন্য।

এই নিয়মের মূলে আছে Saltzer ও Schroeder (১৯৭৫)-এর complete mediation: প্রতিটি প্রবেশে অনুমতি যাচাই (পর্ব ৩)। Client-এর দেওয়া দাম, role, user ID, hidden field, cookie-র মান, এমনকি Origin header: সবকিছু server-এর কাছে শুধু দাবি, প্রমাণ নয়।

২ · Origin আর site: ঠিকানার নিয়ম

Browser-কে তো জানতে হবে কোন পাতা কার। সেই পরিচয়ই origin: scheme, host আর port, এই তিনটির জোড়া (RFC 6454, ২০১১)। তিনটি হুবহু মিললে দুটি URL same-origin. একটি অক্ষরও না মিললে cross-origin. Path আর query গণনায় আসে না।

এর চেয়ে ঢিলা একটি সীমা আছে: site. Site মানে scheme আর registrable domain. shop.example.com আর api.example.com দুটি আলাদা origin, কিন্তু একই site, কারণ দুটিই example.com-এর অধীন। Port-এর এখানে ভূমিকা নেই।

“Registrable domain” কে ঠিক করে? Public Suffix List নামের একটি তালিকা। সেখানে আছে .com, .com.bd এর মতো সবার জন্য খোলা শেষাংশ। তাই a.com.bd আর b.com.bd একই site নয়। অনেক hosting সেবাও নিজেদের domain তালিকায় তোলে, যাতে দুই গ্রাহকের সাইট আলাদা site হয়।

নিচের খেলনা ফাংশন হাতের হিসাবটিই করে। সাতটি URL জোড়া মিলিয়ে দেখুন।

// Origin আর site তুলনা। খেলনা তথ্য আর খেলনা suffix তালিকা, কোনো request যায় না।
const DEFAULT_PORT = { "http:": "80", "https:": "443" };
const SUFFIXES = ["com", "org", "hosting.example"];

function originOf(u) {
  const x = new URL(u);
  return [x.protocol, x.hostname, x.port || DEFAULT_PORT[x.protocol]];
}
function sameOrigin(a, b) {
  const q = originOf(b);
  return originOf(a).every((part, i) => part === q[i]);
}
function siteOf(u) {
  const [scheme, host] = originOf(u);
  const labels = host.split(".");
  for (let i = 0; i < labels.length; i++) {          // লম্বাতম suffix আগে
    if (SUFFIXES.includes(labels.slice(i).join(".")))
      return scheme + "//" + labels.slice(Math.max(i - 1, 0)).join(".");
  }
  return scheme + "//" + host;
}
const A = "https://shop.example.com/cart";
const pairs = [
  [A, "https://shop.example.com/orders?id=7"],
  [A, "https://shop.example.com:443/"],
  [A, "http://shop.example.com/cart"],
  [A, "https://shop.example.com:8443/"],
  [A, "https://api.example.com/v1"],
  [A, "https://example.org/"],
  ["https://ali.hosting.example/", "https://rina.hosting.example/"],
];
for (const [a, b] of pairs) {
  console.log(sameOrigin(a, b) ? "same-origin " : "cross-origin",
    siteOf(a) === siteOf(b) ? "same-site " : "cross-site", b);
}

same-origin  same-site  https://shop.example.com/orders?id=7
same-origin  same-site  https://shop.example.com:443/
cross-origin cross-site http://shop.example.com/cart
cross-origin same-site  https://shop.example.com:8443/
cross-origin same-site  https://api.example.com/v1
cross-origin cross-site https://example.org/
cross-origin cross-site https://rina.hosting.example/

৩ · Same-origin policy: পড়া আটকায়, পাঠানো নয়

Same-origin policy (SOP) হলো browser-এর মূল দেয়াল। এর কথা একটিই: এক origin-এর script অন্য origin-এর ডেটা পড়তে পারবে না। ১৯৯৫ সালে Netscape Navigator 2-এর সময়ে JavaScript-এর সঙ্গে সঙ্গেই এই ধারণা আসে, কারণ পাতায় কোড চললে পাশের পাতা পড়া ঠেকানোর দরকার পড়েছিল।

নবীনরা প্রায়ই ভাবেন, SOP cross-origin request-ই আটকে দেয়। তা নয়। নিচের ধাপগুলো দেখুন: request কোথায় যায়, আর আটকায় কোথায়।

tab ১: https://shop.example.com   (login করা)
tab ২: https://other.example      (অপরিচিত সাইট)
tab ২-এর script চায় /account-এর তথ্য পড়তে

GET /account HTTP/1.1
Host: shop.example.com
Origin: https://other.example

server handler চলল
request server-এ পৌঁছেছে, SOP তা থামায়নি

HTTP/1.1 200 OK
Content-Type: application/json
(Access-Control-Allow-Origin নেই)

{"name":"demo-user","balance":"demo"}

page origin : https://other.example
data origin : https://shop.example.com
CORS অনুমতি : নেই
ফল: script পায় শুধু একটি error, body নয়

পড়া     : আটকেছে
পাঠানো   : আটকায়নি
কাজ বদল করা request: server-এ কাজ হয়ে যেতে পারে
প্রতিরোধ: SameSite, CSRF token (পর্ব ৪১)

৪ · Cookie আর storage: দুই রকম সীমা

অনেকে ধরে নেন, cookie-ও origin মেনে চলে। চলে না। Cookie এসেছিল origin-এর ধারণার আগে, তাই তার নিয়ম আলাদা (পর্ব ১৭-এ flag-গুলো পড়েছেন)।

শেষ সারিটিই আসল ঝুঁকি। Cookie হলো ambient authority: request-এর সঙ্গে নিজে থেকেই পরিচয় চলে যায়, কে পাঠাল তা না দেখেই। তাই Domain=example.com দেওয়া cookie blog.example.com-এর দুর্বল পাতাতেও পৌঁছায়। এজন্য session cookie-তে __Host- নাম আর Domain ছাড়া রাখাই ভালো শুরু। SameSite ঠিক করে, অন্য site থেকে শুরু হওয়া request-এ cookie যাবে কি না।

Browser storage-এর বিভাজন

localStorage, sessionStorage আর IndexedDB প্রতিটি origin-এর জন্য আলাদা (JavaScript কোর্সের Web Storage পর্ব)। এক origin-এর script অন্য origin-এর storage দেখতে পায় না। তবে একই origin-এর সব script, বাইরের script-সহ, সবটা দেখতে পায়। তাই long-lived token সেখানে রাখা ঝুঁকিপূর্ণ।

আধুনিক browser আরও একটি স্তর যোগ করছে: storage partitioning. একই বাইরের widget দুটি ভিন্ন সাইটে বসলে তার storage আলাদা হয়, যাতে সে দুই সাইটের মধ্যে ব্যবহারকারীকে চিনতে না পারে। Browser ভেদে এর আচরণ আলাদা, তাই নির্দিষ্ট আচরণের ওপর নির্ভর করার আগে নিজের লক্ষ্য browser-এ যাচাই করে নেওয়া ভালো।

৫ · CORS: server-এর দেওয়া নিয়ন্ত্রিত ছাড়

SOP-এর সমস্যাও আছে। আপনার পাতা shop.example.com-এ, API api.example.com-এ। দুটি আলাদা origin, তাই SOP পড়তে দেবে না। অথচ দুটোই আপনার। এখানেই CORS (Cross-Origin Resource Sharing). এটি server-কে বলতে দেয়: “এই origin আমার response পড়তে পারে।” এখন এটি WHATWG-এর Fetch Standard-এর অংশ।

Simple request আর preflight

পুরোনো web-ও cross-origin form পাঠাতে পারত। তাই সেই ধরনের request-এ নতুন কোনো ঝুঁকি নেই, এগুলো সরাসরি যায়। এদের বলে simple request: method GET, HEAD বা POST, শুধু safelisted header, আর Content-Type শুধু form-ধরনের তিনটির একটি (application/x-www-form-urlencoded, multipart/form-data, text/plain).

বাকি সবকিছু, যেমন PUT, DELETE, JSON body বা নিজের header, পুরোনো server আশা করত না। তাই browser আগে একটি অনুমতি চায়: preflight request. এটি OPTIONS method-এর ছোট একটি প্রশ্ন, যাতে কোনো body বা cookie যায় না। নিচে আপনার নিজের সাইটের একটি request ধাপে ধাপে দেখুন।

method       : PUT                simple নয়
Content-Type : application/json   simple নয়
credentials  : include
সিদ্ধান্ত     : আগে preflight লাগবে

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

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://shop.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 600
Vary: Origin

origin হুবহু মিলেছে      : হ্যাঁ
PUT অনুমোদিত            : হ্যাঁ
content-type অনুমোদিত   : হ্যাঁ
credentials অনুমোদিত    : হ্যাঁ
ফল ৬০০ সেকেন্ড মনে রাখবে (browser-এর সীমা সাপেক্ষে)

PUT /cart/7 HTTP/1.1
Host: api.example.com
Origin: https://shop.example.com
Content-Type: application/json
Cookie: __Host-sid=example-token

{"qty":2}

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://shop.example.com
Access-Control-Allow-Credentials: true
Vary: Origin
পাতা এবার response পড়তে পারে

Credentials-এর নিয়ম

Cookie-সহ request-এর ক্ষেত্রে দুটি কঠিন নিয়ম। প্রথমত, পাতাকে নিজে credentials: "include" বলতে হয়। দ্বিতীয়ত, server-কে Access-Control-Allow-Credentials: true দিতে হয়, আর Access-Control-Allow-Origin-এ হুবহু origin লিখতে হয়। এখানে * চলে না। Browser তখন response পাতাকে দেয় না। এই নিয়ম ইচ্ছাকৃত: “সবাই পড়ুক” আর “ব্যবহারকারীর পরিচয়সহ পড়ুক” একসঙ্গে থাকা বিপজ্জনক।

৬ · CORS-এর সাধারণ ভুল configuration

CORS error দেখে অনেকে তাড়াহুড়ো করে এমন কিছু লেখেন, যা error সরিয়ে দেয়, কিন্তু দেয়ালও সরিয়ে দেয়। সবচেয়ে পরিচিত ভুল origin reflection: request-এর Origin যা-ই হোক, সেটিই ফিরিয়ে দেওয়া, সঙ্গে credentials-ও। তখন যেকোনো সাইটের পাতা লগইন করা ব্যবহারকারীর পরিচয়ে আপনার API পড়তে পারে।

নিচের খেলনা simulator তিনটি নীতি পাশাপাশি দেখায়। কোনো আসল request নেই। decide ফাংশনটি browser-এর সিদ্ধান্তের একটি সরল রূপ।

// খেলনা CORS সিদ্ধান্ত: real request নেই, শুধু ধারণার জন্য
const OK_LIST = ["https://shop.example.com"];
const METHODS = ["GET", "POST", "PUT"];
const policies = {
  reflect:   o => ({ acao: o, creds: true, methods: METHODS }),        // ভুল
  endsWith:  o => o.endsWith("example.com")                            // ভুল
    ? { acao: o, creds: true, methods: METHODS } : {},
  allowlist: o => OK_LIST.includes(o)                                  // ঠিক
    ? { acao: o, creds: true, methods: METHODS } : {},
};
const isSimple = r => ["GET", "HEAD", "POST"].includes(r.method) && !r.json;

function decide(req, policy) {
  const h = policy(req.origin);
  const match = h.acao === req.origin && (!req.creds || h.creds === true);
  if (!isSimple(req) && !(match && h.methods.includes(req.method))) {
    return "preflight failed: real request NOT sent";
  }
  const how = isSimple(req) ? "no preflight" : "preflight ok";
  return how + ": server ran, page " + (match ? "CAN read" : "cannot read");
}
const origins = ["https://shop.example.com", "https://evil.example",
                 "https://evilexample.com", "null"];
for (const [name, policy] of Object.entries(policies)) {
  console.log("--- policy:", name);
  for (const origin of origins) {
    console.log(origin.padEnd(26), decide({ method: "GET", creds: true, origin }, policy));
  }
}
console.log("--- policy: allowlist, other request types");
const evil = "https://evil.example";
const put = { method: "PUT", json: true, creds: true, origin: evil };
const form = { method: "POST", creds: true, origin: evil };
console.log("PUT + JSON ", decide(put, policies.allowlist));
console.log("simple POST", decide(form, policies.allowlist));

--- policy: reflect
https://shop.example.com   no preflight: server ran, page CAN read
https://evil.example       no preflight: server ran, page CAN read
https://evilexample.com    no preflight: server ran, page CAN read
null                       no preflight: server ran, page CAN read
--- policy: endsWith
https://shop.example.com   no preflight: server ran, page CAN read
https://evil.example       no preflight: server ran, page cannot read
https://evilexample.com    no preflight: server ran, page CAN read
null                       no preflight: server ran, page cannot read
--- policy: allowlist
https://shop.example.com   no preflight: server ran, page CAN read
https://evil.example       no preflight: server ran, page cannot read
https://evilexample.com    no preflight: server ran, page cannot read
null                       no preflight: server ran, page cannot read
--- policy: allowlist, other request types
PUT + JSON  preflight failed: real request NOT sent
simple POST no preflight: server ran, page cannot read

নিজের server-এ allowlist-এর একটি উদাহরণ নিচে। মানগুলো কাল্পনিক। Nginx-এ খালি মানের header পাঠানো হয় না, তাই তালিকার বাইরের origin কোনো CORS header পায় না।

# http block-এ: হুবহু মিললে তবেই মান বসে
map $http_origin $cors_origin {
    default                     "";
    "https://shop.example.com"  "https://shop.example.com";
}
map $cors_origin $cors_creds {
    default  "true";
    ""       "";
}

# server বা location block-এ
add_header Access-Control-Allow-Origin      $cors_origin always;
add_header Access-Control-Allow-Credentials $cors_creds always;
add_header Vary                             "Origin" always;

Detection: নিজের API-র response log বা automated test-এ দেখুন, অচেনা Origin পাঠালে Access-Control-Allow-Origin-এ সেটি ফেরত আসে কি না। অনুশীলন ৩-এ একটি নিরাপদ পরীক্ষা আছে।

৭ · Iframe, sandbox আর postMessage

Iframe হলো এক পাতার ভেতরে আরেকটি পাতা। Payment form, ভিডিও বা map প্রায়ই এভাবে বসে। ভিন্ন origin হলে SOP দুই পক্ষকে আলাদা রাখে। ঠিক এই কারণেই সংবেদনশীল অংশ iframe-এ রাখা একটি ভালো নকশা: card নম্বর থাকে payment সেবার origin-এ, দোকানের script সেখানে পৌঁছাতে পারে না।

আরও শক্ত করে আটকাতে চাইলে sandbox attribute. এটি দিলে iframe-এর সব ক্ষমতা বন্ধ থাকে: script, form, popup, top-level navigation. তার ওপর iframe পায় একটি opaque origin, যা অন্য কোনো origin-এর সঙ্গে মেলে না এমন নামহীন পরিচয়। তারপর যা দরকার, শুধু সেটুকু খুলে দেওয়া হয়। এটিই least privilege.

<!-- script চলবে, কিন্তু পাতাটি opaque origin-এ থাকবে -->
<iframe src="https://widgets.example.com/preview"
        sandbox="allow-scripts"
        title="Preview"></iframe>

postMessage: দুই origin-এর চিঠি

দুই origin-কে কথা বলতে হলে postMessage ব্যবহার হয়। Barth, Jackson ও Mitchell-এর ২০০৮ সালের গবেষণা এই ধরনের frame-যোগাযোগের নিরাপত্তা নিয়ে কাজ করেছিল। এখানে দায়িত্ব দুই পক্ষের:

• পাঠানোর সময়: দ্বিতীয় argument-এ নির্দিষ্ট target origin. "*" দিলে ভুল জায়গাতেও বার্তা পৌঁছাতে পারে।
• পাওয়ার সময়: event.origin হুবহু মিলিয়ে দেখা, তারপর ডেটার গঠন যাচাই। বার্তার ভেতরের কিছুকে কোড বা HTML হিসেবে চালানো যাবে না।

// খেলনা message; সত্যিকারের window বা payment নেই
const PAY = "https://pay.example.com";
const TYPES = ["paid", "cancelled"];

function noCheck(ev) { return ev.data.type; }           // ভুল

function sloppy(ev) {                                   // ভুল
  return ev.origin.includes("pay.example.com") ? ev.data.type : "ignored";
}
function strict(ev) {                                   // ঠিক
  if (ev.origin !== PAY) return "ignored (origin)";
  const d = ev.data;
  if (typeof d !== "object" || !TYPES.includes(d.type)) return "ignored (shape)";
  if (!/^ord-[0-9]+$/.test(d.orderId)) return "ignored (shape)";
  return d.type + " -> ask server to confirm " + d.orderId;
}
const messages = [
  { origin: PAY, data: { type: "paid", orderId: "ord-1001" } },
  { origin: "https://evil.example", data: { type: "paid", orderId: "ord-1001" } },
  { origin: "https://pay.example.com.evil.example",
    data: { type: "paid", orderId: "ord-1001" } },
  { origin: "null", data: { type: "paid", orderId: "ord-1001" } },
  { origin: PAY, data: { type: "refund-all", orderId: "ord-1001" } },
  { origin: PAY, data: { type: "paid", orderId: "<user-input>" } },
];
for (const ev of messages) {
  console.log("from", ev.origin, "type", ev.data.type);
  console.log("  noCheck:", noCheck(ev));
  console.log("  sloppy :", sloppy(ev));
  console.log("  strict :", strict(ev));
}

from https://pay.example.com type paid
  noCheck: paid
  sloppy : paid
  strict : paid -> ask server to confirm ord-1001
from https://evil.example type paid
  noCheck: paid
  sloppy : ignored
  strict : ignored (origin)
from https://pay.example.com.evil.example type paid
  noCheck: paid
  sloppy : paid
  strict : ignored (origin)
from null type paid
  noCheck: paid
  sloppy : ignored
  strict : ignored (origin)
from https://pay.example.com type refund-all
  noCheck: refund-all
  sloppy : refund-all
  strict : ignored (shape)
from https://pay.example.com type paid
  noCheck: paid
  sloppy : paid
  strict : ignored (shape)

৮ · Third-party script: পাতার পুরো ক্ষমতা

Analytics, chat widget, বিজ্ঞাপন, font loader: অনেক পাতায় বাইরের কোড চলে। Third-party script সম্পর্কে একটি কথা মনে রাখলেই হয়: <script src> দিয়ে আনা কোড নিজের origin-এ নয়, আপনার পাতার origin-এ চলে। SOP তাকে আটকায় না, কারণ browser-এর চোখে সে এখন আপনারই।

বাস্তব শিক্ষা

২০২৪ সালে Sansec-এর প্রকাশিত প্রতিবেদন অনুযায়ী, polyfill.io নামের বহুল ব্যবহৃত script সেবার domain নতুন মালিকের হাতে যাওয়ার পরে সেখান থেকে ক্ষতিকর কোড পরিবেশিত হচ্ছিল। আক্রান্ত সাইটের সংখ্যা নিয়ে অনুমান ভিন্ন, প্রায়ই এক লাখের বেশি বলা হয়েছে। লক্ষণীয় হলো, সাইটগুলো নিজের কোডে কিছুই বদলায়নি। ২০১৮ সালে British Airways-এর ঘটনায় UK ICO-র প্রকাশিত প্রতিবেদন অনুযায়ী, সাইটের একটি JavaScript ফাইল বদলে দিয়ে গ্রাহকের card-এর তথ্য বাইরে পাঠানো হয়। সেখানে ফাইল পরিবর্তন শনাক্ত করার নজরদারি থাকলে ঘটনা আগে ধরা পড়তে পারত।

SRI একটি নির্দিষ্ট ফাইলের hash মিলিয়ে দেখে। ফাইল বদলালে browser সেটি চালায় না। নিচের hash মানটি কাল্পনিক। নিজের ফাইলের আসল hash বসাতে হবে।

<script src="https://cdn.widgets.example/widget-2.4.1.js"
        integrity="sha384-example-hash-value"
        crossorigin="anonymous"></script>

SRI-র সীমাও আছে: version বাঁধা ফাইলে এটি চলে, কিন্তু নিজে থেকে বদলাতে থাকা script-এ চলে না। Script-এর গণিতও সহজ। ধরি প্রতিটি বাইরের script বছরে দখল হওয়ার সম্ভাবনা ১% (অনুমিত সংখ্যা, মাপা তথ্য নয়), আর ঘটনাগুলো স্বাধীন। ২০টি script-এ অন্তত একটি দখল হওয়ার সম্ভাবনা ১ − ০.৯৯^২০ ≈ ১৮.২%. ৫টিতে ≈ ৪.৯%. বাস্তবের সংখ্যা ভিন্ন হবে, কিন্তু চেহারাটা একই: প্রতিটি নতুন script মোট ঝুঁকি বাড়ায়। Dependency-র বড় ছবি আসবে পর্ব ৪৮-এ।

৯ · Browser-এর দেয়াল, secure default আর এই মডিউলের মানচিত্র

Process আর site isolation

Origin-এর দেয়াল প্রথমে ছিল শুধু একটি software নিয়ম, একই process-এর ভেতরে। ২০১৮ সালে Spectre দেখাল, CPU-র speculative execution-এর পার্শ্বপ্রতিক্রিয়া দিয়ে একই process-এর মেমরি অনুমান করা যেতে পারে। তাই Chromium site isolation চালু করে: ভিন্ন site-এর পাতা ভিন্ন OS process-এ চলে (Reis, Moshchuk ও Oskov, USENIX Security ২০১৯)। Firefox-ও পরে একই ধরনের ব্যবস্থা আনে। এখানে মনে রাখার কথা, সীমাটি site-ভিত্তিক, origin-ভিত্তিক নয়। আবার browser-এর ভেতরের দুর্বলতা হলে সব নিয়ম ভেঙে পড়তে পারে, তাই browser আপডেট রাখা নিজেই একটি প্রতিরক্ষা (পর্ব ২৯)।

HTTPS হলো ভিত্তি

Origin-এর পুরো মডেল দাঁড়িয়ে আছে একটি ধারণার ওপর: যে পাতা https://shop.example.com থেকে এসেছে, সেটি সত্যিই সেখান থেকে এসেছে। HTTPS ছাড়া পথের কেউ পাতার ভেতরে নিজের script ঢোকাতে পারে, আর সেটি আপনার origin-এর পুরো ক্ষমতা পায়। তাই বিধি সহজ: সব পাতা HTTPS-এ, সঙ্গে HSTS (পর্ব ১২)।

Secure default-এর দিকে

পুরোনো web-এর default ছিল “সবকিছু চলে”। নতুন ধারা উল্টো: ডিফল্টে বন্ধ, দরকার হলে খোলা।

Set-Cookie: __Host-sid=example-token; Secure; HttpOnly; SameSite=Lax; Path=/
Strict-Transport-Security: max-age=31536000; includeSubDomains
Permissions-Policy: camera=(), microphone=(), geolocation=(self)

এই মডিউলের ঝুঁকির মানচিত্র

এই মডেল বুঝলে পরের পর্বগুলো কোথায় বসে, তা পরিষ্কার হয়। প্রতিটি ঝুঁকি কোনো না কোনো সীমার ব্যর্থতা।

১০ · AI-এর যুগে web-এর নিরাপত্তা মডেল

CORS error নিয়ে AI-কে জিজ্ঞেস করলে একটি সাধারণ উত্তর আসে: Access-Control-Allow-Origin: * বসান, বা origin ফিরিয়ে দিন। এতে error যায়, ঝুঁকি আসে। AI লক্ষ্য হিসেবে “error সরানো” ধরে নেয়, “কে পড়তে পারবে” নয়। যাচাই আপনার হাতে রাখতে হবে।

• AI-এর দেওয়া CORS কোডে হুবহু মিলের allowlist আছে, * বা reflection নেই
• নিজের staging server-এ অচেনা Origin দিয়ে যাচাই করেছি
• প্রতিটি client-side যাচাইয়ের সমান যাচাই server-এ আছে
• নতুন বাইরের script যোগ করার আগে মালিক, দরকার আর বিকল্প দেখেছি
• AI-এর উল্লেখ করা standard বা CVE মূল উৎসে নিজে খুঁজে পেয়েছি
• Prompt-এ কোনো আসল secret বা গ্রাহকের তথ্য দিইনি, আর শেষ সিদ্ধান্ত মানুষের হাতে রেখেছি