ഡെവലപ്പർമാർ എപ്പോഴും സ്പ്രിന്റ് ഡെഡ്ലൈനുകളുടെയും ഫീച്ചർ റിക്വസ്റ്റുകളുടെയും സമ്മർദ്ദത്തിലാണ് കഴിയുന്നത്. പെർഫോമൻസ് ട്യൂണിംഗും UI പോളിഷിംഗും കൂടുതൽ ശ്രദ്ധിക്കപ്പെടുന്നു. സെക്യൂരിറ്റി സാധാരണയായി ബാക്ക്ലോഗിൽ വയ്ക്കാറുണ്ട്, അതിന്റെ ഊഴത്തിനായി കാത്തിരിക്കുന്നു. ആ കാത്തിരിപ്പ് ഒരു തെറ്റാണ്. ഓട്ടോമേറ്റഡ് ബോട്ടുകൾ ഇന്റർനെറ്റിൽ നിരന്തരം സ്കാൻ ചെയ്തുകൊണ്ടിരിക്കുന്നു, ലീക്ക് ആയ കീകൾക്കും (leaked keys), ഇൻജക്ഷൻ പോയിന്റുകൾക്കും, ദുർബലമായ ഓതന്റിക്കേഷനും വേണ്ടി അവ തിരയുന്നു. ഡാറ്റാ ബ്രീച്ചുകൾ (Data breaches) സാങ്കേതിക വാർത്തകളിൽ ഒരു സാധാരണ കാര്യമായി മാറിയിരിക്കുന്നു, എന്നാൽ ഉത്തരവാദിത്തപ്പെട്ട ടീമിനെ സംബന്ധിച്ചിടത്തോളം അതിന്റെ പരിഹാരം വളരെ കഠിനമാണ്. നല്ല വാർത്ത എന്തെന്നാൽ, സുരക്ഷിതമായ കോഡ് എഴുതാൻ ക്രിപ്റ്റോഗ്രാഫിയിൽ പിഎച്ച്ഡി ആവശ്യമില്ല. നിങ്ങളുടെ ദൈനംദിന പ്രവർത്തനങ്ങളിൽ ചില ശക്തമായ ശീലങ്ങൾ ഉൾപ്പെടുത്തിയാൽ മതി. നിങ്ങളുടെ ഉപയോക്താക്കളെയും സിസ്റ്റങ്ങളെയും യഥാർത്ഥത്തിൽ സംരക്ഷിക്കുന്ന അഞ്ച് രീതികൾ താഴെ പറയുന്നവയാണ്.
നിങ്ങളുടെ ഓതന്റിക്കേഷൻ സുരക്ഷിതമാക്കുക
പല ടീമുകളും സ്വന്തമായി ഒരു ലോഗിൻ സിസ്റ്റം നിർമ്മിക്കാൻ പ്രലോഭിക്കപ്പെടാറുണ്ട്. ഒരു users table, ഒരു password column, ഒരു JWT generator എന്നിവയുമായി ഇത് തുടങ്ങുന്നു. സെഷൻ മാനേജ്മെന്റ് (session management), ടോക്കൺ റൊട്ടേഷൻ (token rotation), ബ്രൂട്ട്-ഫോഴ്സ് പ്രൊട്ടക്ഷൻ (brute-force protection), സുരക്ഷിതമായ പാസ്വേഡ് റീസെറ്റുകൾ എന്നിവയെല്ലാം ഇനി നിങ്ങളുടെ ഉത്തരവാദിത്തമാണെന്ന് തിരിച്ചറിയുന്നത് വരെ ഇത് ലളിതമായി തോന്നും. മിക്ക ടീമുകളും ഇത് പൂജ്യത്തിൽ നിന്ന് നിർമ്മിക്കുന്നത് ഒഴിവാക്കണം. OAuth 2.0 അല്ലെങ്കിൽ OpenID Connect വഴി അംഗീകൃത ഐഡന്റിറ്റി പ്രൊവൈഡർമാരെ (identity providers) ഓതന്റിക്കേഷനായി ഏൽപ്പിക്കുന്നത് നിങ്ങളുടെ കോഡ്ബേസിലെ വലിയൊരു വിഭാഗം റിസ്കുകൾ ഒഴിവാക്കുന്നു. ആയിരക്കണക്കിന് എഞ്ചിനീയർമാർ പരീക്ഷിച്ചതും സുരക്ഷാ വിദഗ്ധർ പരിശോധിച്ചതുമായ പ്രോട്ടോക്കോളുകൾ നിങ്ങൾക്ക് ഇതിലൂടെ ലഭിക്കുന്നു.
എന്നിരുന്നാലും, പാസ്വേഡുകൾ നിങ്ങൾ തന്നെ കൈകാര്യം ചെയ്യേണ്ടി വരികയാണെങ്കിൽ, അവ വളരെ ശ്രദ്ധയോടെ കൈകാര്യം ചെയ്യുക. bcrypt അല്ലെങ്കിൽ Argon2 ഉപയോഗിച്ച് ഓരോ പാസ്വേഡും ഹാഷ് (hash) ചെയ്യുക. ഈ അൽഗോരിതങ്ങൾ മനഃപൂർവ്വം സാവധാനത്തിൽ പ്രവർത്തിക്കുന്നവയാണ്. ഡാറ്റാബേസ് മോഷ്ടിച്ച് പാസ്വേഡുകൾ ഓഫ്ലൈനായി ക്രാക്ക് ചെയ്യാൻ ശ്രമിക്കുന്ന അറ്റാക്കർമാരെ തടയാൻ ഈ സാവധാനത സഹായിക്കുന്നു. പാസ്വേഡുകൾ ഒരിക്കലും പ്ലെയിൻ ടെക്സ്റ്റ് (plain text) ആയി സൂക്ഷിക്കരുത്. ലോഗുകളിലോ (logs), ക്രാഷ് റിപ്പോർട്ടുകളിലോ മറ്റൊരിടത്തും പാസ്വേഡുകൾ വെളിപ്പെടുത്തരുത്.
മൾട്ടി-ഫാക്ടർ ഓതന്റിക്കേഷൻ (Multi-factor authentication) ഇനി ഒരു ഓപ്ഷൻ മാത്രമല്ല, അത് അനിവാര്യമാണ്. പാസ്വേഡുകൾ ചോരാം, ഫിഷിംഗ് (Phishing) ആക്രമണങ്ങൾ നടക്കാം. ഒരു TOTP ആപ്പോ അല്ലെങ്കിൽ ഹാർഡ്വെയർ കീയോ പോലുള്ള രണ്ടാമതൊരു ഘടകം (second factor) ഉപയോഗിക്കുന്നത് അക്കൗണ്ട് ഹാക്ക് ചെയ്യപ്പെടാനുള്ള സാധ്യത ഗണ്യമായി കുറയ്ക്കുന്നു.
നിങ്ങൾ സെഷൻ ടോക്കണുകളോ JWT-കളോ നൽകുന്നുണ്ടെങ്കിൽ, അവ HttpOnly, Secure കുക്കികൾക്കുള്ളിൽ (cookies) സൂക്ഷിക്കുക. HttpOnly ഫ്ലാഗ് ജാവാസ്ക്രിപ്റ്റിനെ കുക്കികൾ വായിക്കുന്നതിൽ നിന്ന് തടയുന്നു, ഇത് പല ക്രോസ്-സൈറ്റ് സ്ക്രിപ്റ്റിംഗ് (cross-site scripting) ആക്രമണങ്ങളെയും പ്രതിരോധിക്കുന്നു. Secure ഫ്ലാഗ് ബ്രൗസർ HTTPS വഴി മാത്രം ഡാറ്റ കൈമാറുന്നുവെന്ന് ഉറപ്പാക്കുന്നു. JWT-കൾ localStorage-ൽ സൂക്ഷിക്കരുത്. അത് എളുപ്പമാണെന്ന് തോന്നാമെങ്കിലും, നിങ്ങളുടെ സൈറ്റിലെ ഏതെങ്കിലും XSS സുരക്ഷാ വീഴ്ചയിലൂടെ അറ്റാക്കർക്ക് ഉപയോക്താക്കളുടെ ടോക്കണുകൾ ഉടൻ തന്നെ കൈക്കലാക്കാൻ സാധിക്കും.
OWASP Top 10 നിങ്ങളുടെ അടിസ്ഥാന മാനദണ്ഡമായി കാണുക
OWASP Top 10 എന്നത് വെറുമൊരു തിയറി പരീക്ഷാ സിലബസ് അല്ല. വെബ് ആപ്ലിക്കേഷനുകൾ ആക്രമിക്കപ്പെടാൻ സാധ്യതയുള്ള ഏറ്റവും സാധാരണമായ വഴികളുടെ ഒരു പട്ടികയാണിത്. നിങ്ങളുടെ പ്രതികരണശേഷിയിൽ വിശ്വസിച്ച് ട്രാഫിക് നിയമങ്ങൾ അവഗണിക്കുന്നത് പോലെയാണ് ഇത് അവഗണിക്കുന്നത്.
SQL injection ആദ്യമായി കണ്ടെത്തി പതിറ്റാണ്ടുകൾ കഴിഞ്ഞിട്ടും ഇപ്പോഴും പ്രൊഡക്ഷൻ ഡാറ്റാബേസുകളെ ഭീഷണിപ്പെടുത്തുന്നു. ഇതിനുള്ള പരിഹാരം ലളിതമാണ്, പക്ഷേ അതിന് അച്ചടക്കം ആവശ്യമാണ്. യൂസർ ഇൻപുട്ടുകൾ ഒരിക്കലും ഒരു ക്വറി സ്ട്രിംഗിലേക്ക് (query string) നേരിട്ട് ചേർക്കരുത്. പാരാമീറ്ററൈസ്ഡ് ക്വറികൾ (parameterized queries) അല്ലെങ്കിൽ എസ്കേപ്പിംഗ് (escaping) സ്വയം കൈകാര്യം ചെയ്യുന്ന Prisma പോലുള്ള ഒരു ORM ഉപയോഗിക്കുക. ഡാറ്റാബേസ് ഡ്രൈവർ കോഡിനെയും ഡാറ്റയെയും വേർതിരിക്കുന്നു, അതിനാൽ ഒരു ദുരുദ്ദേശ്യ ഇൻപുട്ടിനും നിങ്ങളുടെ ക്വറി ലോജിക് മാറ്റാൻ കഴിയില്ല.
ക്രോസ്-സൈറ്റ് സ്ക്രിപ്റ്റിംഗ് (XSS), അൺഫിൽട്ടർ ചെയ്ത യൂസർ ഇൻപുട്ടുകളെ ഉപയോഗപ്പെടുത്തുന്നു. ഉപയോക്താക്കൾ നൽകുന്ന വിവരങ്ങൾ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ പ്രദർശിപ്പിക്കുന്നുണ്ടെങ്കിൽ, അവ ആദ്യം സാനിറ്റൈസ് (sanitize) ചെയ്യുക. ആധുനിക ഫ്രെയിംവർക്കുകൾ പലപ്പോഴും ഔട്ട്പുട്ട് സ്വയം സുരക്ഷിതമാക്കുന്നുണ്ടെങ്കിലും, കസ്റ്റം കമ്പോണന്റുകളും dangerouslySetInnerHTML പോലുള്ള API-കളും ഈ സുരക്ഷാ സംവിധാനങ്ങളെ മറികടക്കാൻ സാധ്യതയുണ്ട്. നിങ്ങൾ എന്തിനെയാണ് വിശ്വസിക്കുന്നത് എന്ന കാര്യത്തിൽ വ്യക്തത വേണം.
Cross-site request forgery (CSRF) ഒരു ബ്രൗസറിനെ ചെയ്യാൻ പാടില്ലാത്ത കാര്യങ്ങൾ ചെയ്യാൻ പ്രേരിപ്പിക്കുന്നു. ഫോമുകളിൽ anti-CSRF ടോക്കണുകൾ ഉൾപ്പെടുത്തിയും കുക്കികളിൽ SameSite അറ്റ്രിബ്യൂട്ട് (attribute) സെറ്റ് ചെയ്തും ഇത് തടയാം. SameSite=Lax അല്ലെങ്കിൽ Strict ഉപയോഗിക്കുന്നത് ക്രോസ്-ഒറിജിൻ റിക്വസ്റ്റുകൾ സമയത്ത് കുക്കികൾ ഉപയോഗിക്കുന്നത് തടയാൻ ബ്രൗസറിനോട് നിർദ്ദേശിക്കുന്നു, ഇത് മിക്ക CSRF ആക്രമണങ്ങളെയും തടയുന്നു.
Least Privilege തത്വം പ്രയോഗിക്കുക
എല്ലാ ഉപയോക്താക്കൾക്കും അഡ്മിൻ അവകാശങ്ങൾ (admin rights) ആവശ്യമില്ല. എല്ലാ മൈക്രോസർവീസുകൾക്കും നിങ്ങളുടെ ഡാറ്റാബേസിലേക്ക് റൂട്ട് ആക്സസ് (root access) ആവശ്യമില്ല. ഒരു പ്രത്യേക ജോലിക്ക് ആവശ്യമായ കൃത്യമായ ആക്സസ് മാത്രം നൽകുക എന്നതാണ് 'Principle of Least Privilege' കൊണ്ട് അർത്ഥമാക്കുന്നത്.
നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ഡാറ്റാബേസ് യൂസറിൽ നിന്ന് ഇത് തുടങ്ങാം. നിങ്ങളുടെ ബാക്കെൻഡിന് വരികൾ (rows) വായിക്കാനും എഴുതാനും മാത്രമേ ആവശ്യമുള്ളൂ എങ്കിൽ, ടേബിളുകൾ ഡിലീറ്റ് ചെയ്യാനോ (drop tables), സ്കീമകൾ മാറ്റാനോ (alter schemas), പുതിയ ഡാറ്റാബേസുകൾ നിർമ്മിക്കാനോ ഉള്ള അനുമതികൾ നീക്കം ചെയ്യുക. ഒരു അറ്റാക്കർ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ഹാക്ക് ചെയ്താൽ, ഈ നിയന്ത്രിത അനുമതികൾ ഒരു മതിലായി പ്രവർത്തിക്കും. അവർക്ക് ഡാറ്റ മോഷ്ടിക്കാൻ കഴിഞ്ഞേക്കാം, പക്ഷേ ഒരു കമാൻഡ് ഉപയോഗിച്ച് നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ നശിപ്പിക്കാൻ കഴിയില്ല.
ഇതേ രീതി നിങ്ങളുടെ ക്ലൗഡ് എൻവയോൺമെന്റിലും പ്രയോഗിക്കുക. AWS IAM roles, Google Cloud service accounts, Azure managed identities എന്നിവ ഓരോ പ്രത്യേക ആവശ്യങ്ങൾക്കും മാത്രം പരിമിതപ്പെടുത്തണം. സ്റ്റാറ്റിക് അസറ്റുകൾ മാത്രം ഡെപ്ലോയ് ചെയ്യുന്ന ഒരു CI/CD പൈപ്പ്ലൈനിന് വലിയ