Key ကာကွယ်ခြင်းထက် လွန်တဲ့ API Security

နားလည်ထားရမယ့် အချက်

Cybersecurity Basics course က API key ကိုယ်တိုင်ကို ကာကွယ်ခြင်းကို ရှင်းပြပြီးသားပါ။ ဒါက လိုအပ်ပေမယ့် လုံလောက်တာတော့ မဟုတ်ပါဘူး။

ကာကွယ်ထားတဲ့ key တစ်ခုက design ညံ့ဖျင်းတဲ့ API ရှေ့မှာ ရှိနေသေးရင် real gap တွေ ကျန်ရှိနေဆဲပါ။ ဒီ lesson က key ကို ကျော်လွန်တဲ့ API security ကို ဖော်ပြပါမယ်။

Authorization ကို resource၊ action တစ်ခုချင်းစီအလိုက် စစ်ဆေးရမယ်—valid key က caller ကို အသိအမှတ်ပြု client ဖြစ်ကြောင်းသာ သက်သေပြတယ်၊ ဒီ access တိကျတိကျ ခွင့်ပြုထားလားဆိုတာ ဘာမှမပြောဘူး။

Rate limiting က abuse၊ overload၊ credential-guessing၊ cost spike တွေကို ကာကွယ်ပေးတယ်—ဒါပေမယ့် ဒါက defense တစ်ခုတည်းသာဖြစ်ပြီး တခြားအရာတွေကို အစားထိုးလို့ မရပါ။

Request validation က type, length, required field, allowed value တွေကို စစ်ဆေးတယ်။ Response data minimization ဆိုတာ caller တကယ်လိုအပ်တဲ့ field တွေကိုသာ ပြန်ပေးခြင်းပါ—password hash (သို့) internal token ဘယ်တော့မှ မပါစေဘဲ။

API SECURITY PIPELINE (BEYOND THE KEY)
--------------------------------------
CLIENT
  |
  v
AUTHENTICATED REQUEST (valid key/token)
  |
  v
API
  +-- Authorization check (per resource/action)
  +-- Rate limit check
  +-- Input validation (type/length/required/allowed)
  |
  v
BUSINESS LOGIC
  |
  v
DATABASE
  |
  v
RESPONSE (minimized -- no password hash, no internal tokens)
  |
  v
CLIENT

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

အောက်က function က response data minimization ကို တိုက်ရိုက် ပြသတယ်—database query တစ်ခုကနေ ထွက်လာတဲ့ raw object ကိုယူပြီး ကြည်လင်ပြီးသား version၊ ဘယ်field ဖယ်ရှားခံရလဲဆိုတဲ့ list ကို ပြန်ပေးတယ်။

passwordHash, internalToken, internal note ပါတဲ့ raw user record တစ်ခုနဲ့ run ကြည့်ပါ—minimized output ထဲမှာ legitimate field သုံးခုသာ ကျန်တယ်။

• API key ကို ကာကွယ်ခြင်းက လိုအပ်ပေမယ့် မလုံလောက်ပါ—authorization, rate limiting, validation, minimization အားလုံးက ဒီထက်ပိုအရေးကြီးတယ်။
• Rate limiting က abuse နဲ့ cost spike ကို ကာကွယ်ပေးတဲ့ defense တစ်ခုပါ—authorization (သို့) validation ရဲ့ အစားထိုးမဟုတ်ပါ။
• caller လိုအပ်တာထက် data ပိုပြီး ဘယ်တော့မှ မပြန်ပေးပါနဲ့—response server ကနေ မထွက်ခင် password hash လို sensitive field တွေကို ဖယ်ရှားပါ။

API Security Checklist (Key ထက် လွန်တဲ့)

• Authorization ကို "key valid ဖြစ်လား" တစ်ခုတည်းမဟုတ်ဘဲ resource၊ action တစ်ခုချင်းစီအလိုက် စစ်ဆေးထားသည်။
• abuse၊ overload၊ cost spike တွေကို လျှော့ချဖို့ rate limiting ထားရှိထားသည်။
• request တိုင်းကို type, length, required field, allowed value အလိုက် validate လုပ်ထားသည်။
• Response တွေမှာ password hash၊ internal token လို မလိုအပ်တဲ့ sensitive field ဘယ်တော့မှ မပါသည်။
• Error message တွေက internal detail (stack trace, internal path, database error) ဘယ်တော့မှ မယိုစိမ့်သည်။

အတူတူ စမ်းရေးကြည့်မယ်

function minimizeResponse(apiResponse) {
  const sensitiveFields = ["passwordHash", "internalToken", "internalNotes", "securityAnswer"];
  const removed = [];
  const minimized = {};

  for (const [key, value] of Object.entries(apiResponse)) {
    if (sensitiveFields.includes(key)) {
      removed.push(key);
    } else {
      minimized[key] = value;
    }
  }

  return { minimized, removedFields: removed };
}

const rawUserResponse = {
  id: 42,
  username: "maria",
  email: "maria@example.com",
  passwordHash: "$2b$10$abcdefghijklmnopqrstuv",
  internalToken: "svc_9f8e7d6c5b4a",
  internalNotes: "flagged for manual review 2026-01-02",
};

const result = minimizeResponse(rawUserResponse);
console.log(JSON.stringify(result, null, 2));

{
  "minimized": {
    "id": 42,
    "username": "maria",
    "email": "maria@example.com"
  },
  "removedFields": [
    "passwordHash",
    "internalToken",
    "internalNotes"
  ]
}

OWASP API Security Project — Digital Privacy & Modern Security