Secret Management

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

API Tutorial က API key တစ်ခုကို request တစ်ခုပေါ် တပ်ဆင်ဖို့ သင်ပေးခဲ့ပါတယ်။ အဲဒီ key က ဘယ်မှာ တကယ် နေထိုင်သင့်လဲဆိုတာကို မပြောခဲ့ပါဘူး၊ ဒါက real-world security failure အများဆုံးတစ်ခုပါ။

`const apiKey = "sk_live_abc123"` ကို frontend (သို့) mobile app code ထဲမှာ တိုက်ရိုက် ရေးလိုက်ရင် key က user တစ်ယောက်စီရဲ့ device ပေါ် run နေတဲ့ JavaScript bundle (သို့) app binary ထဲ ပါသွားပါတယ်။ ဘယ်သူမဆို browser devtools ကို ဖွင့်ပြီး secret key ကို စက္ကန့်အနည်းငယ်အတွင်း ကူးယူနိုင်ပါတယ်။

မှန်ကန်တဲ့ architecture ကတော့ layer တစ်ခု ထပ်ထည့်ပါတယ် — browser က သင့်ကိုယ်ပိုင် backend server ကို ပြောဆိုပြီး၊ backend ကသာ real secret key ကို ကိုင်ဆောင်ကာ external API နဲ့ ပြောဆိုပါတယ်။ Backend ဟာ trusted boundary ဖြစ်လာပါတယ်။

Environment variable တွေက အဲဒီ secret ကို source file ထဲ hardcode မလုပ်ဘဲ backend ဆီ လက်ဆင့်ကမ်းပေးဖို့ standard နည်းလမ်းပါ။ `.env` file ကို `.gitignore` ထဲ ထည့်ထားရမှာပါ — Git ထဲ commit ဖြစ်သွားတဲ့ secret က line ဖျက်လိုက်ပါလည်း history ထဲမှာ အမြဲ ပြန်ရနိုင်နေဆဲပါ။

Secret

Access ရရှိစေတဲ့ API key, password, token စတဲ့ private value တစ်ခု — public ဖြစ်သွားရင် misuse ဖြစ်နိုင်တယ်။

Environment Variable

Codebase အပြင်ဘက်မှာ သိမ်းထားပြီး runtime မှာ process တစ်ခုဆီ ပေးအပ်တဲ့ configuration value — secret တွေကို hardcode မလုပ်ဘဲ ပေးဖို့ standard နည်းလမ်း။

SECRET KEY: GOOD PATH VS BAD PATH
---------------------------------
GOOD:
  Browser --> Your Backend --> [ Secret Key (env var) ] --> External API

BAD (do not do this):
  Browser --> [ Secret Key hardcoded in JS ] --> External API
          X-- anyone can read this in devtools --X

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

အောက်က scanner က ဂရုမစိုက်တတ်တဲ့ pattern အများအားဖြင့်တွေ့ရတဲ့ ပုံစံတစ်ခုကို ရှာဖွေပါတယ် — variable name ထဲမှာ "key", "secret", (သို့) "token" ပါတဲ့ declaration တစ်ခုကို string literal အနည်းဆုံး စာလုံး ၁၂ လုံးနဲ့ တိုက်ရိုက် assign လုပ်ထားခြင်းပါ။

Source snippet နှစ်ခုအပေါ် run ကြည့်ပါ။ Risky version က API key ကို `fetch` call တစ်ခုအပေါ်မှာ တိုက်ရိုက် hardcode ထားပြီး scanner က အဲဒီ line ကို အတိအကျ flag လုပ်ပေးပါတယ်။ Clean version ကတော့ key ကို `process.env.API_KEY` ကနေ ဖတ်ထားပြီး scanner က empty array ကို မှန်ကန်စွာ ပြန်ပေးပါတယ်။

ဒီလို tool တစ်ခုမျိုးဟာ real team တွေက pre-commit hook (သို့) CI pipeline ထဲ တပ်ဆင်လေ့ရှိတဲ့ check အတိအကျပါ — key တစ်ခု hardcode ဖြစ်နေတာကို shared Git history ဆီ မရောက်ခင် ဖမ်းယူနိုင်ပြီး၊ နောက်မှ ဖယ်ရှားရတာက ပထမကတည်းက commit မလုပ်ခြင်းထက် ပိုခက်ခဲပါတယ်။

• Frontend code ထဲက secret ဟာ devtools နဲ့ ဘယ်သူမဆို ဖတ်နိုင်တယ်
• Backend layer တစ်ခုကသာ secret key ကို ကိုင်ဆောင်သင့်တယ်
• Environment variable + .gitignore က standard architecture pattern ဖြစ်တယ်

Code Commit မလုပ်ခင်

• Source file ဘယ်ထဲမှာမှ secret literal string မပါ
• .env file က .gitignore ထဲ ပါပြီးသား
• Frontend bundle ထဲမှာ secret ဘာမှ မပါ
• Browser က inspect လုပ်နိုင်တဲ့ client-side network request ထဲမှာ secret မပါ
• Secret က least-privilege scope ရှိတယ် (လိုအပ်တာထက် ပို permission မပါ)

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

function scanForHardcodedSecrets(sourceCode) {
  const pattern = /(const|let|var)\s+(\w*(?:key|secret|token)\w*)\s*=\s*["']([A-Za-z0-9_\-]{12,})["']/gi;
  const findings = [];
  let match;
  while ((match = pattern.exec(sourceCode)) !== null) {
    findings.push({ variable: match[2], flagged: true, snippet: match[0] });
  }
  return findings;
}

const risky = `
const apiKey = "sk_live_51H8x9aBcDeFgHiJkLmNoP";
const userName = "guest";
fetch("https://api.example.com/charge", { headers: { Authorization: apiKey } });
`;

const clean = `
const apiKey = process.env.API_KEY;
const userName = "guest";
fetch("https://api.example.com/charge", { headers: { Authorization: apiKey } });
`;

console.log("Risky file findings:", scanForHardcodedSecrets(risky));
console.log("Clean file findings:", scanForHardcodedSecrets(clean));

Risky file findings: [{ variable: 'apiKey', flagged: true, snippet: 'const apiKey = "sk_live_51H8x9aBcDeFgHiJkLmNoP"' }]
Clean file findings: []
(Clean version က key ကို process.env ကနေ ဖတ်ထားလို့ scanner က ဘာမှ မတွေ့ပါ)

About secret scanning - GitHub Docs — API Integration & Webhooks