ပရောဂျက်: Developer Security Baseline တစ်ခု

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

ဒီ capstone project ဟာ Advanced chapter ရဲ့ lesson လေးခု — authentication-vs-authorization-deep-dive, token-and-session-security, api-security-beyond-secrets, website-security-layers-review တို့ကို ပေါင်းစပ်ထားပါတယ်။ သီးခြားစီက mental checklist လေးခုကို production-ready baseline တစ်ခုတည်းအဖြစ် ပေါင်းစပ်ပေးပါတယ်။

Cybersecurity Basics ရဲ့ project တွေက OWASP Top 10 (SQL injection, XSS) input-handling flaw တွေကို ဗဟိုပြုခဲ့တယ်။ ဒီ baseline ကတော့ layer တစ်ခု အထက်မှာ ရှိတယ် — XSS ကို ပြင်ပေမယ့် authorization ကို per-resource မစစ်ရင် attacker တစ်ယောက် URL ID ပြောင်းရုံနဲ့ တခြားသူ data ဖတ်နိုင်သေးတယ်။

Authentication မှန်ကန်စွာ configure လုပ်ထားခြင်း
Login တစ်ခုတည်းမှာမဟုတ်ဘဲ authorization ကို per-resource စစ်ဆေးထားခြင်း
Token တွေကို log/commit/client-side expose မဖြစ်စေခြင်း
API မှာ rate limiting ကျင့်သုံးထားခြင်း
Secrets တွေကို source code မဟုတ်ဘဲ environment variables ထဲ ထားခြင်း
Dependency တွေကို up to date ထားခြင်း

text

DEVELOPER SECURITY BASELINE
---------------------------
DEVELOPER SECURITY BASELINE
------------------------------
AUTH          [PASS/FAIL]
  |
  v
AUTHZ         [PASS/FAIL]
  |
  v
TOKENS        [PASS/FAIL]
  |
  v
API           [PASS/FAIL]
  |
  v
SECRETS       [PASS/FAIL]
  |
  v
DEPENDENCIES  [PASS/FAIL]
  |
  v
ALL SIX PASS -> PRODUCTION-READY BASELINE MET

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

Baseline ကို project ဘယ်ခုမှာမဆို configuration အပေါ် run နိုင်မယ့် checklist တစ်ခု အနေနဲ့ ဆောက်ပါ။ Deadline ဖိအားအောက်မှာ ဘာမှ ကျန်မသွားအောင် category ၆ ခုကို fixed order အတိုင်း လုပ်ဆောင်ပါ။

Authentication

Password (သို့) passkey တွေကို မှန်ကန်စွာ hash / handle လုပ်ထားကြောင်းနဲ့ failed-login attempt တွေကို rate-limit လုပ်ထားကြောင်း သေချာအောင် စစ်ပါ။

Authorization

Record တစ်ခုချင်းစီကို ပြန်ပေး (သို့) ပြင်ဆင်တဲ့ endpoint တိုင်းက login ဝင်ထားသူလားပဲ မကြည့်ဘဲ တောင်းဆိုနေသူက အဲဒီ record ကို ပိုင်ဆိုင် (သို့) access ခွင့်ရှိကြောင်း တကယ် verify လုပ်ထားကြောင်း သေချာအောင် စစ်ပါ။

Tokens

Codebase နဲ့ log တွေထဲမှာ token plaintext အနေနဲ့ ပေါ်နေလားရှာပါ; version control ထဲ commit မဖြစ်ကြောင်းနဲ့ လိုအပ်ချက်မရှိဘဲ client-side JavaScript ကို မဖော်ကြောင်း သေချာအောင် စစ်ပါ။

API

API က sensitive endpoint တွေမှာ rate limiting ကျင့်သုံးထားကြောင်းနဲ့ response တွေက internal record အပြည့်မဟုတ်ဘဲ client တကယ်လိုအပ်တဲ့ field တွေပဲ ပြန်ပေးကြောင်း သေချာအောင် စစ်ပါ။

Secrets

Secrets — API key, database credential, signing key — တွေဟာ source ထဲ hard-code မဖြစ်ဘဲ environment variables (သို့) secrets manager ထဲ ရှိကြောင်း သေချာအောင် စစ်ပါ။

Dependencies

Dependency တွေဟာ အကန့်အသတ်မရှိ ရပ်တန့်မနေဘဲ maintained update cadence တစ်ခုပေါ်မှာ ရှိကြောင်း သေချာအောင် စစ်ပါ။

Secret အစစ်တွေ ဘယ်တော့မှ မထည့်ပါနှင့်

ဒီ checklist ကို ကိုယ့် project အပေါ် run ကြည့်တဲ့အခါ boolean နဲ့ တိုတိုဖော်ပြချက်တွေနဲ့ပဲ ဖော်ပြပါ — API key, token, credential အစစ်တွေကို ဒီ lesson ထဲ (သို့) AI tool ဘယ်ခုထဲမှ ဘယ်တော့မှ မထည့်ပါနှင့်။

အောက်က checker function ကို ဖော်ပြထားတဲ့ project configuration အပေါ် နှစ်ကြိမ် run ကြည့်ပါ — category အများကြီး fail ဖြစ်တဲ့ project တစ်ခုအတွက် တစ်ကြိမ်၊ ခြောက်ခုစလုံး pass ဖြစ်တဲ့ project တစ်ခုအတွက် တစ်ကြိမ် — ပြီးရင် report နှစ်ခုကို side by side နှိုင်းယှဉ်ကြည့်ပါ။

Authentication က identity ကို confirm လုပ်တယ်; authorization ကိုတော့ resource တစ်ခုချင်းစီအတွက် အချိန်တိုင်း သီးခြား စစ်ဆေးရပါမယ်
Category အများစုမှာ တိတ်တဆိတ် fail ဖြစ်နေတဲ့ baseline တစ်ခုဟာ ရှင်းရှင်းလင်းလင်း မပြီးသေးတယ်ဆိုတာထက် ပိုအန္တရာယ်များပါတယ်
Input-handling bug (XSS လိုမျိုး) တွေကို ပြင်တာက authorization, token, API design gap တွေကို အလိုအလျောက် ပြင်မပေးပါဘူး

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

javascript

function checkDeveloperSecurityBaseline(project) {
  const checks = [
    {
      category: "Authentication",
      pass: project.auth.passwordsHashedCorrectly && project.auth.loginRateLimited,
      detail: "Passwords/passkeys hashed correctly and failed logins are rate-limited",
    },
    {
      category: "Authorization",
      pass: project.authz.checkedPerResource,
      detail: "Every endpoint verifies the caller owns/may access the specific resource, not just that they are logged in",
    },
    {
      category: "Tokens",
      pass: project.tokens.neverLogged && project.tokens.neverCommitted && !project.tokens.exposedToClient,
      detail: "Tokens are never logged, never committed to version control, and not needlessly exposed to client-side code",
    },
    {
      category: "API",
      pass: project.api.rateLimited && project.api.responsesMinimized,
      detail: "Sensitive endpoints are rate-limited and responses return only the fields a client actually needs",
    },
    {
      category: "Secrets",
      pass: project.secrets.inEnvVars,
      detail: "API keys, DB credentials, and signing keys live in environment variables, not source code",
    },
    {
      category: "Dependencies",
      pass: project.dependencies.upToDate,
      detail: "Dependencies are on a maintained update cadence, not frozen indefinitely",
    },
  ];

  const failed = checks.filter((c) => !c.pass);
  return {
    project: project.name,
    passed: checks.length - failed.length,
    total: checks.length,
    overallPass: failed.length === 0,
    checks: checks.map((c) => ({ category: c.category, status: c.pass ? "PASS" : "FAIL", detail: c.detail })),
  };
}

// Described CONFIGURATION only -- booleans, never real keys/tokens/credentials.
const failingProject = {
  name: "Example Project A (needs work)",
  auth: { passwordsHashedCorrectly: true, loginRateLimited: false },
  authz: { checkedPerResource: false },
  tokens: { neverLogged: true, neverCommitted: false, exposedToClient: true },
  api: { rateLimited: false, responsesMinimized: true },
  secrets: { inEnvVars: true },
  dependencies: { upToDate: false },
};

const passingProject = {
  name: "Example Project B (baseline met)",
  auth: { passwordsHashedCorrectly: true, loginRateLimited: true },
  authz: { checkedPerResource: true },
  tokens: { neverLogged: true, neverCommitted: true, exposedToClient: false },
  api: { rateLimited: true, responsesMinimized: true },
  secrets: { inEnvVars: true },
  dependencies: { upToDate: true },
};

for (const project of [failingProject, passingProject]) {
  const report = checkDeveloperSecurityBaseline(project);
  console.log(`\n${report.project}: ${report.passed}/${report.total} checks passed, overall ${report.overallPass ? "PASS" : "FAIL"}`);
  for (const c of report.checks) {
    console.log(`  [${c.status}] ${c.category} -- ${c.detail}`);
  }
}

You should see

Project A ဟာ check ၆ ခုထဲက ၅ ခု fail ဖြစ်ပြီး (Secrets တစ်ခုတည်းပဲ pass) overallPass: false လို့ report ထုတ်ပေးတယ်; Project B ကတော့ check ၆ ခုလုံး pass ဖြစ်ပြီး overallPass: true လို့ report ထုတ်ပေးတယ် — အထက်က console output မှာ category တစ်ခုချင်းစီအတွက် PASS/FAIL စာရင်းနဲ့ ကိုက်ညီပါတယ်။

၅ မိနစ် စမ်းကြည့်

Code ထဲက category ၆ ခု boolean တွေအတိုင်း ကိုယ့်ရဲ့ project အစစ် (သို့) fictional project တစ်ခုကို (production secrets အစစ်ကို ဘယ်တော့မှ မထည့်ဘဲ) ဖော်ပြပြီး checkDeveloperSecurityBaseline ကို run ကြည့်ပါ။ report ထဲက FAIL တစ်ခုချင်းစီအတွက် တိကျတဲ့ ပြင်ဆင်ရမယ့် အဆင့် တစ်ခုစီ ရေးပါ။

သတိလေးတစ်ချက်

'User login ဝင်ထားတယ်' ဆိုတာကို 'user authorized ဖြစ်တယ်' နဲ့ အတူတူလို့ သဘောထားခြင်း — authentication နဲ့ authorization ဟာ check မတူပါဘူး

Endpoint အသစ်, dependency အသစ်, integration အသစ်တစ်ခုက ပြီးခဲ့သည့် pass ဖြစ်ခဲ့တဲ့ category တစ်ခုကို တိတ်တဆိတ် ပြန်ဖွင့်ပေးနိုင်ပေမယ့်၊ launch မတိုင်ခင် baseline ကို တစ်ကြိမ်တည်းပဲ run ပြီး နောက်ထပ် ဘယ်တော့မှ မ run တော့ခြင်း

OWASP API Security Top 10 — Digital Privacy & Modern Security