API নিরাপত্তা — OWASP API Top 10, rate limit আর schema যাচাই

১ · API আলাদা কেন — দরজাটি সোজা ভাণ্ডারঘরে খোলে

একটি কাল্পনিক অনলাইন বাজারের কথা ভাবুন। ওয়েবসাইটে রিনা শুধু নিজের অর্ডার দেখেন। পর্দায় অন্য কারও অর্ডার দেখার কোনো বোতাম নেই। ডেভেলপার ভাবলেন, কাজ শেষ। কিন্তু রিনার ফোনের app যে পথে ডেটা আনে, সেই API কি এই সীমা জানে?

API-র ঝুঁকি তিন কারণে আলাদা:

• সরাসরি object-এ হাত। /orders/1042-এর মতো ঠিকানায় id নিজেই অনুরোধের অংশ। Client যেকোনো সংখ্যা পাঠাতে পারে।
• ওপাশে যন্ত্র, মানুষ নয়। Partner-এর server, script বা bot সেকেন্ডে বহু অনুরোধ পাঠাতে পারে। CAPTCHA বা “মানুষের গতি” ধরে নেওয়া এখানে চলে না।
• Mobile app খোলা বই। App ফোনে থাকে, তাই তার ভেতরের endpoint আর গোপন বলে লুকানো মান বের করা সম্ভব। App-এর ভেতরের যাচাই তাই বাড়তি সুবিধা, সুরক্ষা নয় (পর্ব ৩৫).

এই ছবির মূল বার্তা: gateway জানে “কে এসেছেন”, কিন্তু order ১০৪২ কার, সেটি জানে শুধু service. তাই gateway থাকলেই API নিরাপদ, এই ধারণা ভুল।

২ · OWASP API Security Top 10 — দশ ঝুঁকি, দশ প্রতিকার

OWASP-এর সাধারণ web তালিকা পাবেন পর্ব ৩৭-এ। API-র জন্য তাদের আলাদা তালিকা আছে: OWASP API Security Top 10. প্রথম সংস্করণ ২০১৯ সালে, দ্বিতীয়টি ২০২৩ সালে। ২০২৬ সালের অক্টোবরে প্রকল্পের নিজের site দেখে নতুন কোনো সংস্করণ পাইনি, তবে পড়ার সময় আবার মিলিয়ে নেবেন।

২০১৯ থেকে ২০২৩-এ কয়েকটি বদল লক্ষ্য করুন। SSRF, business flow আর unsafe consumption নতুন। ২০১৯-এর excessive data exposure আর mass assignment মিলে হয়েছে API3. Injection আর logging আলাদা item হিসেবে নেই, তবে এর মানে এগুলো গুরুত্বহীন নয়। Injection-এর নিয়ম পর্ব ৩৯-এ দেখবেন, আর log-এর কথা এই পর্বের অংশ ৯-এ।

৩ · Authorization-এর তিন স্তর — কাজ, object আর ঘর

তালিকার API1, API3 আর API5 আসলে একই প্রশ্নের তিন রূপ: “এই ব্যক্তি কি এটি করতে পারেন?” Authentication বলে আপনি কে। Authorization বলে আপনি কী পারেন। মডেলগুলো দেখেছেন পর্ব ১৯-এ, আর ওয়েবের দিক থেকে IDOR পাবেন পর্ব ৩৮-এ (Broken access control). API-তে এটি তিন স্তরে ভাঙে:

নিচের খেলনা API-তে দুটি handler আছে। unsafeGet শুধু দেখে token বৈধ কি না। safeGet মালিকানাও মেলায়। সবই memory-তে, কোনো network নেই।

// Toy in-memory API. No network, fake data only.
const orders = {
  1042: { owner: "rina",  item: "book",  amount: 500 },
  1043: { owner: "karim", item: "phone", amount: 9000 },
};
const tokens = { "example-token-rina": "rina", "example-token-karim": "karim" };

function unsafeGet(req) {
  const user = tokens[req.token];
  if (!user) return { status: 401 };          // checks WHO you are
  const order = orders[req.id];
  return order ? { status: 200, order } : { status: 404 };
}

function safeGet(req) {
  const user = tokens[req.token];
  if (!user) return { status: 401 };
  const order = orders[req.id];
  // Same answer for "missing" and "not yours", so ids stay unconfirmed.
  if (!order || order.owner !== user) return { status: 404 };
  return { status: 200, order };
}

const tests = [
  { who: "rina, own order  ", token: "example-token-rina", id: 1042 },
  { who: "rina, karim order", token: "example-token-rina", id: 1043 },
  { who: "rina, no order   ", token: "example-token-rina", id: 9999 },
  { who: "no token         ", token: "", id: 1042 },
];
const show = r => r.status + (r.order ? " amount=" + r.order.amount : "");
for (const t of tests) {
  console.log(t.who, "| unsafe:", show(unsafeGet(t)).padEnd(15), "| safe:", show(safeGet(t)));
}

তিনটি অভ্যাস এই শর্ত ভুলে যাওয়া ঠেকায়। প্রথমত, মালিকানা ধরা থাকুক ডেটা আনার query-তেই, যেমন “এই id এবং এই owner”. দ্বিতীয়ত, user-এর পরিচয় নিন token থেকে, অনুরোধের body বা URL থেকে নয়। তৃতীয়ত, প্রতিটি endpoint-এ দুই ব্যবহারকারী দিয়ে স্বয়ংক্রিয় test লিখুন: A-এর token দিয়ে B-এর জিনিস চাইলে ব্যর্থ হতেই হবে।

BFLA ঠেকায় default deny: নতুন endpoint শুরুতে সবার জন্য বন্ধ, নির্দিষ্ট ভূমিকা খুললে তবেই খোলা। URL-এ /admin নেই বলে কোনো কাজ সাধারণ হয়ে যায় না। আর পর্দায় বোতাম লুকানো শুধু সাজসজ্জা; যাচাই হতে হবে server-এ।

৪ · Schema যাচাই আর response ফিল্টার — দুই দিকের চুক্তি

সরকারি ফরমে নির্দিষ্ট ঘর থাকে। কেউ ফরমের পাশে “আমার বেতন দ্বিগুণ করা হোক” লিখে দিলে কেরানি সেটি নথিতে তোলেন না। Schema validation ঠিক এই কেরানি। OpenAPI ফাইলে আপনি লিখে রাখেন কোন endpoint কী নেবে, কী দেবে। ভেতরের গঠনটি লেখা হয় JSON Schema-য়। এটিই positive security model: যা ঘোষিত, শুধু তা-ই চলবে।

openapi: 3.1.0
info: { title: Orders API, version: 2.0.0 }
paths:
  /v2/orders:
    post:
      security:
        - bearerAuth: [orders:write]
      requestBody:
        required: true
        content:
          application/json:
            schema: { $ref: '#/components/schemas/NewOrder' }
      responses:
        '201': { description: created }
        '400': { description: invalid input }
components:
  securitySchemes:
    bearerAuth: { type: http, scheme: bearer }
  schemas:
    NewOrder:
      type: object
      required: [item, qty]
      properties:
        item: { type: string, maxLength: 20 }
        qty: { type: integer, minimum: 1, maximum: 10 }
      additionalProperties: false

শেষের additionalProperties: false লাইনটিই সবচেয়ে দামি। এটি না থাকলে অজানা ঘর চুপচাপ ঢুকে পড়ে। আর কোড যদি পুরো body সরাসরি object-এ বসিয়ে দেয়, তখনই হয় mass assignment: ক্রেতা নিজেই price ঠিক করে দেন। নিচে JSON Schema-র ছোট একটি অংশ হাতে বানানো হয়েছে শুধু বোঝার জন্য। বাস্তবে পরীক্ষিত library ব্যবহার করবেন।

// A tiny subset of JSON Schema, for learning. Real services use a tested library.
const schema = {
  required: ["item", "qty"],
  additionalProperties: false,
  properties: {
    item: { type: "string", maxLength: 20 },
    qty:  { type: "number", minimum: 1, maximum: 10 },
    note: { type: "string", maxLength: 50 },
  },
};
function validate(data, s) {
  const errs = [];
  for (const k of s.required) if (!(k in data)) errs.push("missing " + k);
  for (const [k, v] of Object.entries(data)) {
    const rule = s.properties[k];
    if (!rule) { errs.push("unknown field " + k); continue; }
    if (typeof v !== rule.type) { errs.push(k + " must be " + rule.type); continue; }
    if (rule.maxLength && v.length > rule.maxLength) errs.push(k + " too long");
    if (rule.minimum !== undefined && v < rule.minimum) errs.push(k + " below minimum");
    if (rule.maximum !== undefined && v > rule.maximum) errs.push(k + " above maximum");
  }
  return errs;
}
const payloads = [
  { item: "book", qty: 2 },
  { item: "book", qty: 2, price: 1 },
  { item: "book", qty: "2" },
  { item: "book", qty: 500 },
  { qty: 1, note: "x".repeat(60) },
];
for (const p of payloads) {
  const errs = validate(p, schema);
  const shown = JSON.stringify(p).slice(0, 34);
  console.log(errs.length ? "400 " : "OK  ", shown, errs.join("; "));
}

Schema যা পারে না সেটিও জানা দরকার। qty-এর গঠন ঠিক থাকলেও অর্ডারটি রিনার কি না, schema বলতে পারে না। Injection-ও এতে পুরো ঠেকে না; তার জন্য parameterized query লাগে (পর্ব ৩৯). Schema প্রথম ছাঁকনি, শেষ সিদ্ধান্ত নয়।

উত্তরের দিকের ছাঁকনি

ইনপুট আটকালে অর্ধেক কাজ হয়। Excessive data exposure ঘটে উল্টো পথে: ডেটাবেসের পুরো row পাঠিয়ে ভাবা হয় app শুধু নাম দেখাবে। কিন্তু network-এর উত্তর যে কেউ নিজের ফোনেই পড়তে পারেন। তাই response filtering করতে হবে server-এ, allowlist দিয়ে:

// Name each field that may leave the server. Never send the raw row.
function toOrderView(row) {
  return { id: row.id, item: row.item, amount: row.amount };
}
// row also holds owner, cost_price and supplier_note: none of them go out.

নতুন ঘর ডেটাবেসে যোগ হলে এই পদ্ধতিতে সেটি আপনাআপনি বাইরে যায় না, কেউ ভেবে যোগ করলে তবেই যায়। সন্দেহ থাকলে উত্তরের schema-ও test-এ যাচাই করুন।

৫ · Rate limit, quota আর pagination — গতি, মোট আর আকার

ঈদের ট্রেনের টিকিটের ঘর ভাবুন। “একজন একবারে চারটির বেশি নয়” হলো কাজের সীমা। “জানালায় মিনিটে কতজন” হলো গতির সীমা। “আজ মোট কত” হলো quota. API-তেও তিনটি আলাদা জিনিস। Rate limit দেখে গতি, quota দেখে মোট পরিমাণ, আর pagination দেখে এক উত্তরের আকার। Algorithm-গুলোর গভীর আলোচনা আছে System Design-এর rate limiting পর্বে; এখানে দেখছি নিরাপত্তার দিক।

একটি স্তরে ভরসা নয়, কয়েকটি একসঙ্গে। Token bucket-এর ধারণা সহজ: বালতিতে কয়েকটি token, প্রতি অনুরোধে একটি খরচ, সময় গেলে ধীরে ধীরে ভরে। নিচের সিমুলেটরে প্রতি API key-র জন্য আলাদা বালতি, ধারণক্ষমতা ৩, প্রতি ১০ সেকেন্ডে একটি token, আর দিনের quota ৬. ঘড়ি নকল।

// Token bucket per API key, plus a daily quota. Simulated clock, no real time.
const CAPACITY = 3, REFILL_EVERY = 10, DAILY_QUOTA = 6;   // tokens, seconds, calls
const state = {};

function allow(key, now) {
  const b = state[key] ??= { tokens: CAPACITY, last: 0, used: 0 };
  const gained = Math.floor((now - b.last) / REFILL_EVERY);
  if (gained > 0) {
    b.tokens = Math.min(CAPACITY, b.tokens + gained);
    b.last += gained * REFILL_EVERY;
  }
  if (b.used >= DAILY_QUOTA) return "429 quota";
  if (b.tokens === 0) return "429 retry-after=" + (b.last + REFILL_EVERY - now) + "s";
  b.tokens--;
  b.used++;
  return "200";
}

const calls = [
  [0, "key-A"], [0, "key-A"], [1, "key-A"], [2, "key-A"], [2, "key-B"],
  [10, "key-A"], [14, "key-A"], [45, "key-A"], [46, "key-A"], [47, "key-A"],
  [90, "key-A"], [90, "key-B"],
];
for (const [t, key] of calls) {
  const r = allow(key, t);
  const b = state[key];
  console.log("t=" + String(t).padStart(2), key, r.padEnd(19), "tokens=" + b.tokens, "used=" + b.used);
}

Sliding window আরেকটি পথ: প্রতি মুহূর্তে ঠিক আগের ৬০ সেকেন্ডের অনুরোধ গোনা। এতে burst কম যায়, তবে হিসাব রাখার খরচ বেশি। বেছে নেওয়ার বিষয়, ঠিক-ভুলের নয়।

HTTP 429 (Too Many Requests, RFC 6585) ফেরানো আর Retry-After জানানো ভালো ব্যবহার। ভদ্র client এতে থামে। যিনি নিয়ম মানেন না, তাঁর জন্য সীমাটি server-এই বসানো।

হিসাব করে দেখুন

Rate limit BOLA সারায় না। ধরুন ১০,০০,০০০টি অর্ডার, আর API-তে BOLA আছে। প্রতি key-তে মিনিটে ৬০ অনুরোধ মানে সেকেন্ডে ১টি। সব পড়তে লাগে ১০,০০,০০০ ÷ ৮৬,৪০০ ≈ ১১.৬ দিন। ২০টি key থাকলে প্রায় ১৩.৯ ঘণ্টা। সীমা গতি কমায় আর সময় কেনে, ফুটো বন্ধ করে না।

Pagination-ও সীমা। ধরুন প্রতি row ২ KB. limit-এর উপরসীমা না থাকলে ১,০০,০০০ row-এর এক উত্তর ২০০ MB. উপরসীমা ১০০ হলে উত্তর ২০০ KB, মানে এক হাজার ভাগের এক ভাগ। তাই client যা-ই চান, server-এ limit কেটে দিন, আর পৃষ্ঠার গভীরে না যেতে cursor ব্যবহার করুন।

Sensitive business flow আলাদা করে ভাবতে হয়, কারণ এখানে প্রতিটি অনুরোধ বৈধ। ঈদের টিকিট যন্ত্র দিয়ে মুহূর্তে কিনে নেওয়া, বা নকল অ্যাকাউন্ট খুলে referral বোনাস তোলা, কোনোটিতেই কোড ভাঙে না। প্রতিকার ব্যবসার ভাষায়: এক ব্যক্তির কেনার সীমা, লাইন বা অপেক্ষার ব্যবস্থা, অস্বাভাবিক গতিতে বাড়তি যাচাই। আর পয়সার খরচে সীমা দিন: প্রতিটি SMS OTP-র জন্য টাকা লাগলে সীমাহীন endpoint সরাসরি বিলে আঘাত করে (economic denial of sustainability).

৬ · Gateway আর পরিচয় — API key বনাম OAuth token

API gateway হলো অফিসের রিসেপশন। সবাই এখানে দিয়েই ঢোকেন। পরিচয়পত্র দেখা, খাতায় নাম তোলা, ঠিক কক্ষে পাঠানো, ভিড় সামলানো, এসব একই জায়গায় হয়। প্রতিটি কক্ষে আলাদা করে করতে হয় না। মূল প্রযুক্তিটি System Design-এর gateway পর্বে আছে।

Gateway-র ভালো কাজগুলো হলো TLS termination, token যাচাই, rate limit, আকারের সীমা, schema যাচাই, routing আর অভিন্ন log. কিন্তু object-এর মালিকানা ব্যবসার ডেটা, তাই সে সিদ্ধান্ত service-এর। Service-কে সরাসরি internet থেকে আসা অনুরোধও নিতে দেবেন না, নইলে gateway এড়িয়ে যাওয়া যায়। ভেতরে mTLS বা network নিয়ম দিয়ে এটি নিশ্চিত করা হয়, আর service নিজেও token-এর মূল দাবি আবার দেখে নেয় (zero trust, পর্ব ৭৪)।

নিচে রিনার একটি বৈধ অনুরোধ ধাপে ধাপে দেখুন। প্রতিটি ধাপে কী মেলানো হলো আর ব্যর্থ হলে কী উত্তর যেত, দুটোই খেয়াল করুন।

GET /v2/orders/1042
Authorization: Bearer
  example-token-rina
X-Request-Id: req-7f31

TLS 1.3        ok
header size    1.2 KB <= 8 KB  pass
body size      0 <= 1 MB       pass
fail -> 431 or 413

signature  valid
exp        not expired
aud        orders-api
scope      orders:read
sub        rina
fail -> 401

limit      60 per minute
used       2
now        3 <= 60  pass
fail -> 429 + Retry-After

route   /v2/orders/{id}  declared
id      1042  integer    pass
query   none             pass
fail -> 400 or 404

role     customer
action   order.read
policy   customer may read  pass
fail -> 403

order 1042 owner = rina
token sub        = rina
equal  pass
fail -> 404

db row: id item amount owner
        cost_price supplier_note
reply : id item amount
log   : req-7f31 rina order=1042
        200 (token not logged)

API key নাকি OAuth token

দুটোকে অনেকে একই ভাবেন, কিন্তু প্রশ্ন আলাদা। API key বলে “কোন app বা প্রকল্প ডাকছে”. Access token বলে “কোন app, কার হয়ে, কী করার অনুমতি নিয়ে, কতক্ষণের জন্য”. Session আর token-এর ভেতরের কথা আছে পর্ব ১৭-এ, আর OAuth পর্ব ১৮-এ.

Key-তেও ভালো অভ্যাস চলে: একটি key শুধু একটি কাজ, দরকারি অনুমতির বেশি নয়, server-এ শুধু hash রেখে দেওয়া, চিনতে সুবিধার জন্য স্পষ্ট prefix, আর নিয়মিত rotation. Machine-to-machine-এ client credentials বা workload identity থাকলে স্বল্পায়ু token পাওয়া যায়, তাই দীর্ঘস্থায়ী key-এর দরকার কমে।

৭ · Webhook আর বাইরের API — অন্যের কথাও যাচাই করুন

এতক্ষণ অনুরোধ আসছিল ব্যবহারকারীর কাছ থেকে। Webhook-এ উল্টো: বাইরের কোম্পানি আপনার URL ডেকে জানায় “টাকা এসেছে”. URL জানলে যে কেউ এই ঠিকানায় অনুরোধ পাঠাতে পারেন। পর্ব ৯-এ আপনি HMAC দিয়ে এই বার্তা যাচাই আর constant-time তুলনা দেখেছেন। এখানে তিনটি বাস্তব সমস্যা যোগ হচ্ছে: সময়ের মধ্যে একই বার্তা আবার আসা, বৈধ পুনঃপ্রেরণ, আর key বদলের দিন দুটি key.

Timestamp একা replay ঠেকায় না, ৫ মিনিটের মধ্যে একই বার্তা আবার পাঠানো যায়। তাই signature-এর ভেতরে event id রাখা হয়, আর গ্রহণকারী দেখা id-গুলো জমা রাখেন। নিচের কোডে Python-এর আসল hmac চলছে। Key নকল, ঘড়ি নকল, network নেই।

import hashlib, hmac

KEYS = [b"example-new-key", b"example-old-key"]   # fake; two live during rotation
MAX_AGE = 300                                     # seconds
NOW = 1767225700                                  # simulated clock
seen = set()                                      # real systems: shared store with expiry

def sign(event_id, ts, body, key):
    msg = f"{event_id}.{ts}.".encode() + body
    return hmac.new(key, msg, hashlib.sha256).hexdigest()

def receive(event_id, ts, body, tag):
    if abs(NOW - ts) > MAX_AGE:
        return "400 outside time window"
    if not any(hmac.compare_digest(sign(event_id, ts, body, k), tag) for k in KEYS):
        return "401 bad signature"
    if event_id in seen:
        return "200 duplicate, ignored"     # say OK so the sender stops retrying
    seen.add(event_id)
    return "200 processed"

ts = 1767225600
body = b'{"order":1042,"amount":500,"status":"paid"}'
tag = sign("evt_1", ts, body, KEYS[0])
print("tag      :", tag[:16] + "...")
print("first    :", receive("evt_1", ts, body, tag))
print("again    :", receive("evt_1", ts, body, tag))
print("edited   :", receive("evt_2", ts, body.replace(b"500", b"900"), sign("evt_2", ts, body, KEYS[0])))
print("new id   :", receive("evt_3", ts, body, tag))
print("old key  :", receive("evt_4", ts, body, sign("evt_4", ts, body, KEYS[1])))
print("wrong key:", receive("evt_5", ts, body, sign("evt_5", ts, body, b"other-key")))
old = ts - 3600
print("too old  :", receive("evt_6", old, body, sign("evt_6", old, body, KEYS[0])))
print("seen     :", sorted(seen))

id   = evt_1
ts   = 1767225600
msg  = id + "." + ts + "." + body
tag  = HMAC-SHA256(key, msg)
     = a9abb62054af5d3d...

header id  : evt_1
header ts  : 1767225600
header tag : a9abb62054af5d3d...
raw body   : 43 bytes, untouched
clock NOW  : 1767225700

NOW - ts
 = 1767225700 - 1767225600
 = 100 seconds
100 <= 300  pass

computed = a9abb62054af5d3d...
received = a9abb62054af5d3d...
compare_digest  ->  equal

seen before: { }
evt_1 not in seen  new
seen after : { evt_1 }
action     : mark order 1042 paid
reply      : 200 processed

seen       : { evt_1 }
evt_1 in seen  duplicate
action     : none
reply      : 200 duplicate, ignored

বাইরের API-কে কতটা বিশ্বাস

API10-এর মূল কথা সহজ: partner-এর API থেকে আসা ডেটাও ইনপুট। সেই কোম্পানি হ্যাক হতে পারে, ভুল ডেটা পাঠাতে পারে, বা অন্য ঠিকানায় redirect করতে পারে। তাই উত্তরের schema যাচাই করুন, আকারের সীমা ও timeout দিন, redirect অন্ধভাবে অনুসরণ করবেন না, আর ব্যবহারকারী-দেওয়া URL fetch করতে হলে SSRF-এর নিয়ম মেনে চলুন (পর্ব ৪২, SSRF আর file handling).

৮ · GraphQL — এক দরজায় অসংখ্য অনুরোধ

REST-এ প্রতিটি কাজের আলাদা URL থাকে। GraphQL-এ সাধারণত একটিই endpoint, আর client query লিখে বলে দেয় ঠিক কী চাই। রেস্তোরাঁর নির্দিষ্ট মেনু বনাম “যা খুশি বলুন” ধরনের রান্নাঘর ভাবুন। সুবিধা বিশাল, তবে নিরাপত্তার হিসাব বদলে যায়: এক অনুরোধের কাজের পরিমাণ আর আগে থেকে জানা নেই। তাই “অনুরোধ গোনা” rate limit এখানে যথেষ্ট নয়।

হিসাবটি দেখুন। Query-র তিন স্তরে তালিকা: ১০ জন ক্রেতা, প্রত্যেকের ১০টি অর্ডার, প্রতি অর্ডারে ১০টি পণ্য। সর্বোচ্চ node = ১০ + ১০ × ১০ + ১০ × ১০ × ১০ = ১০ + ১০০ + ১,০০০ = ১,১১০. প্রতিটি সীমা ১০০ হলে একই গঠনে ১০০ + ১০,০০০ + ১০,০০,০০০ = ১০,১০,১০০. এক অনুরোধ, অথচ কাজ এক হাজার গুণের কাছাকাছি।

OWASP-এর GraphQL cheat sheet introspection আর development-এর playground public production-এ বন্ধ রাখতে বলে, আর সেই সঙ্গে সতর্ক করে যে এতে schema পুরো লুকায় না। সবচেয়ে বড় কথা, authorization থাকতে হবে প্রতিটি field-এর resolver বা business layer-এ। একটি পথ দিয়ে order সুরক্ষিত, অন্য nested পথে খোলা, GraphQL-এ এই ভুল সহজেই হয়।

৯ · Inventory, version, log আর contract test

পুরোনো বাড়ির কথা ভাবুন। সামনের গেটে দারোয়ান, ক্যামেরা, খাতা সব আছে। কিন্তু পেছনে একটি গলির গেট, বহু বছর আগে বসানো, যার কথা নতুন কেয়ারটেকার জানেনই না। Shadow API হলো সেই গেট, যা চলছে কিন্তু তালিকায় নেই। Zombie API হলো যে গেট “বন্ধ” বলে ঘোষণা হয়েছিল, অথচ তালা আসলে কেউ লাগায়নি।

Versioning দরকার, কারণ পুরোনো mobile app সবাই তখনই বদলান না। কিন্তু প্রতিটি পুরোনো version একটি বাড়তি দরজা, আর নতুন প্রতিকার সেখানে প্রায়ই পৌঁছায় না। তাই inventory-তে প্রতিটি API-র জন্য লিখে রাখুন: মালিক, version, পরিবেশ, কারা ব্যবহার করেন, কোন ডেটা, আর কবে বন্ধ হবে। Spec-কে সত্য ধরবেন না; মিলিয়ে দেখবেন বাস্তব প্রমাণের সঙ্গে।

GET  /v2/orders/{id}
POST /v2/orders
GET  /v2/profile
POST /v2/webhooks/payment
total: 4 routes

/v2/*  -> orders-service
/v1/*  -> legacy-service
/internal/* -> blocked
note: /v1 has no owner tag

GET /v2/orders/{id}    812,040
POST /v2/orders         96,115
GET /v2/profile        230,772
POST /v2/webhooks/pay..   4,018
GET /v1/customers/{id}   1,940

in spec, in log   : 4
in spec, no log   : 0
no spec, in log   : 1
  GET /v1/customers/{id}
  owner: unknown

auth        shared API key
object check none
rate limit  none
reply       full row, NID field
callers     1 old partner key

today : temporary limit + alert
week 1: owner named, partner told
week 2: Deprecation + Sunset headers
week 6: 410 Gone, route removed
CI    : route not in spec = fail

Log আর anomaly alert

Authorization-এর ফুটো প্রায়ই error দেখায় না; উত্তর 200-ই আসে। তাই সাধারণ error alert এটি ধরে না। API-র log-এ প্রতি অনুরোধে রাখুন: সময়, request id, user, key-এর id (key নয়), route, object id, status, উত্তরের আকার আর সময়। Token, password আর ব্যক্তিগত ডেটা log-এ নয় (পর্ব ৫৫).

যে আচরণ দেখতে হয়: একজন user অল্প সময়ে অনেক আলাদা object ছুঁচ্ছেন, 403 বা 404-এর হঠাৎ বৃদ্ধি, অস্বাভাবিক বড় উত্তর, পুরোনো version-এ হঠাৎ চলাচল, রাতের বেলা একটি key-র ব্যবহার। নিচে নিজের API log-এর জন্য একটি Sigma-ধাঁচের নিয়ম।

# Sigma-style idea for your own API logs; field names are examples
title: Denied order lookups
name: orders_denied
status: experimental
logsource:
  product: orders-api
  category: application
detection:
  selection:
    route: '/v2/orders/{id}'
    status:
      - 403
      - 404
  condition: selection
level: low
---
title: One user denied on many different orders
correlation:
  type: value_count
  rules:
    - orders_denied
  group-by:
    - user_id
  timespan: 10m
  condition:
    field: object_id
    gte: 50
level: medium

সীমা ৫০ এখানে অনুমান; নিজের ট্র্যাফিক দেখে ঠিক করবেন, নইলে false positive বাড়বে। ব্যর্থতার পাশাপাশি “একজন user-এর সফল object-সংখ্যা”ও বেসলাইন ধরে দেখুন, কারণ BOLA থাকলে ব্যর্থতা হয়তো আসবেই না।

Contract test

Contract test spec আর বাস্তবকে একসঙ্গে রাখে। CI-তে নকল ডেটা নিয়ে আসল service-কে ডাকা হয়, আর দেখা হয় উত্তর spec মানছে কি না। নিরাপত্তার জন্য এতে কয়েকটি নেতিবাচক test যোগ করুন: অজানা ঘর দিলে 400, token ছাড়া 401, অন্যের object-এ 403 বা 404, অতিরিক্ত limit কেটে যাওয়া, উত্তরে ঘোষণার বাইরের ঘর না থাকা। শুধু “সফল পথ” পরীক্ষা করলে নিরাপত্তার কিছুই প্রমাণ হয় না। আরও পাবেন পর্ব ৪৯-এ।

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

AI কয়েক সেকেন্ডে পুরো CRUD API লিখে দেয়। দেখতে সুন্দর, test-ও চলে। কিন্তু তার সাধারণ ভুলগুলো ঠিক এই পর্বের ঝুঁকিগুলোই: id দিয়ে সরাসরি row আনা, পুরো body ডেটাবেসে বসানো, পুরো row উত্তরে পাঠানো, আর CORS-এ সব খুলে দেওয়া। কোড “চলছে” দেখে এগুলো ধরা পড়ে না, কারণ সুখী পথে কোনো ব্যর্থতা নেই।

AI-এর লেখা API মেনে নেওয়ার আগে

• প্রতিটি endpoint-এ function আর object দুই স্তরের যাচাই নিজের চোখে দেখেছি
• অজানা ঘর বাতিল হয়, আর উত্তরে allowlist-এর বাইরের কিছু নেই, test দিয়ে প্রমাণিত
• Rate limit, আকারের সীমা, limit-এর উপরসীমা আর timeout আছে
• Webhook-এ raw body, constant-time তুলনা, সময়ের সীমা আর event id আছে
• AI-কে কোনো আসল key, token বা গ্রাহকের ডেটা দিইনি
• AI-এর উল্লেখ করা প্রতিটি মান ও নম্বর মূল উৎসে মিলিয়েছি; যেসব সিদ্ধান্ত মানুষকে প্রভাবিত করে, সেগুলো মানুষই নিয়েছেন