2 min read

Security Is Not a Feature

Learn the essential security practices for modern web applications, including authentication, authorization, input validation, rate limiting, secret management, HTTPS, security headers, dependency management, and defense in depth.

WebSecurityCyberSecurityApplicationSecurityWebDevelopment

Not a Feature — It’s a Process

လုံခြုံရေး (Security) ကို စနစ်တစ်ခု တည်ဆောက်ပြီးမှ သီးသန့်ထည့်သွင်းရတဲ့ အရာတစ်ခုအဖြစ် သဘောထားလေ့ရှိကြပါတယ်။ ကျတော်တို့ဟာ Code ရေးတယ်၊ Deploy လုပ်တယ်၊ ပြီးမှ Security အကြောင်းကို စဉ်းစားတတ်ကြပါတယ်။ အဲဒီလို ချဉ်းကပ်ပုံက အလွန်အန္တရာယ်များပါတယ်။

Security ဆိုတာ စတင်တည်ဆောက်ချိန်ကတည်းက ဒွန်တွဲပါဝင်နေရမယ့် အစိတ်အပိုင်းတစ်ခု ဖြစ်ပါတယ်။ ဖြစ်လာနိုင်တဲ့ အန္တရာယ်တွေကို ဖော်ထုတ်ခြင်း၊ တိုက်ခိုက်ခံရနိုင်ခြေရှိတဲ့ နေရာ (Attack Surfaces) တွေကို လျှော့ချခြင်းနဲ့ ကာကွယ်ရေးစနစ်တွေကို စဉ်ဆက်မပြတ် တိုးတက်အောင် ပြုလုပ်နေရတဲ့ လုပ်ငန်းစဉ် (Process) တစ်ခုလည်း ဖြစ်ပါတယ်။

Authentication Is Not Authorization

Authentication က "သင်ဟာ ဘယ်သူလဲ" ဆိုတာကို အတည်ပြုတာဖြစ်ပြီး၊ Authorization ကတော့ "သင့်မှာ ဘာလုပ်ပိုင်ခွင့် ရှိသလဲ" ဆိုတာကို စစ်ဆေးတာ ဖြစ်ပါတယ်။ Login ဝင်ထားရုံနဲ့ Resource အားလုံးကို အလိုအလျောက် သုံးစွဲခွင့်မရသင့်ဘဲ Server ဘက်ကနေ ပိုင်ခွင့် (Authorization) စစ်ဆေးဖို့ လိုအပ်ပါတယ်။ Frontend မှာ Admin button ဖျောက်ထားရုံနဲ့ လုံခြုံရေးပြည့်ဝပြီလို့ ပြောလို့မရပါ။

Never Trust Client Input

Client ဘက်က လာသမျှ Input အားလုံးကို မလုံခြုံနိုင်ဘူး (Untrusted) လို့ အမြဲသတ်မှတ်ထားရပါမယ်။ Frontend Validation ကို Attacker တွေက လွယ်ကူစွာ ကျော်ဖြတ်နိုင်တာကြောင့် Request Bodies, Query Parameters, Headers နဲ့ File Uploads စတာတွေကို Server ဘက်ကနေ မဖြစ်မနေ ထပ်မံ Validate လုပ်ရပါမယ်။

Rate Limiting Prevents Abuse

API တွေမှာ Rate Limiting မပါရင် Attackers တွေက Login အကြိမ်ကြိမ် ကြိုးစားတာ၊ Data တွေကို ခိုးယူတာ (Scrape) နဲ့ Automated System တွေသုံးပြီး စနစ်ကို ဝန်ပိအောင် ပြုလုပ်နိုင်ပါတယ်။ Authentication Endpoints တွေမှာ Request အကြိမ်ရေ ကန့်သတ်ချက် (Limits) ကို တင်းကျပ်စွာ သတ်မှတ်ပေးခြင်းဖြင့် မလိုလားအပ်တဲ့ Traffic မြင့်တက်မှုတွေကို ကာကွယ်နိုင်ပါတယ်။

Protect Passwords and Secrets

Password တွေကို စိတ်ချရတဲ့ Hashing Algorithms တွေနဲ့သာ သိမ်းဆည်းရပါမယ်။ API Keys, Database Credentials နဲ့ JWT Signing Keys တွေကို Code ထဲမှာ Hardcode မလုပ်ဘဲ Environment Variables သို့မဟုတ် Secret-Management Systems တွေကို သုံးပြီး Trusted Server ပေါ်မှာပဲ လုံခြုံစွာ သိမ်းဆည်းရပါမယ်။

HTTPS Should Be the Default

HTTPS ဟာ Client နဲ့ Server ကြား ဆက်သွယ်မှုတွေကို Encrypt လုပ်ပေးတာကြောင့် Passwords, Auth Tokens နဲ့ API Traffic တွေ ကြားဖြတ်ခိုးယူခံရခြင်းမှ ကာကွယ်ပေးပါတယ်။ ဒါကြောင့် Production Applications တိုင်းမှာ HTTPS ကို Default ဖွင့်ထားသင့်ပါတယ်။

Use Security Layers

CSP နဲ့ HSTS စတဲ့ Security Headers တွေကို Authentication, Authorization, Rate Limiting, Input Validation တို့နဲ့ ပေါင်းစပ်အသုံးပြုခြင်းဖြင့် Layer တစ်ခု ကျိုးပေါက်သွားခဲ့ရင်တောင် ကျန်တဲ့ Layers တွေက ဆုံးရှုံးနိုင်ခြေကို လျှော့ချပေးနိုင်ပါတယ်။

Monitor and Maintain

Security Logs တွေကတစ်ဆင့် မအောင်မြင်တဲ့ Login ဝင်ရောက်မှုတွေနဲ့ ပုံမှန်မဟုတ်တဲ့ API လှုပ်ရှားမှုတွေကို စောင့်ကြည့်ရပါမယ်။ ဒါပေမဲ့ Passwords နဲ့ Tokens တွေကိုတော့ Log မမှတ်မိပါစေနဲ့။ တခြား Third-party Dependencies တွေကိုလည်း ပုံမှန် Update လုပ်ပြီး Vulnerabilities တွေကို အမြဲ စောင့်ကြည့်နေရပါမယ်။

Final Thoughts

Security ဆိုတာ တစ်ကြိမ် တည်ဆောက်ပြီးရင် ပြီးသွားတဲ့ Feature မဟုတ်ပါ။ အန္တရာယ်များကို စဉ်ဆက်မပြတ် စစ်ဆေးပြီး ကာကွယ်ရေးစနစ်များကို အမြဲမပြတ် အဆင့်မြှင့်တင်နေရတဲ့ Process တစ်ခု ဖြစ်တာကြောင့် ပြဿနာ မဖြစ်ခင် ကတည်းက ကြိုတင်ပြင်ဆင် ရေးဆွဲရမှာ ဖြစ်ပါတယ်။