𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗔𝘂𝗱𝗶𝘁 𝗥𝗲𝘀𝘂𝗹𝘁𝘀: 𝗪𝗵𝘆 𝗜 𝗳𝗲𝗹 𝗲𝗺𝗯𝗮𝗿𝗿𝗮𝘀𝘀𝗲𝗱
ഞാൻ അടുത്തിടെ എന്റെ എല്ലാ സൈഡ് പ്രോജക്റ്റുകളിലും ഒരു സെക്യൂരിറ്റി ഓഡിറ്റ് നടത്തി. ഇതിൽ എന്റെ FastAPI backend, Telegram bots, PWA, Streamlit apps എന്നിവ ഉൾപ്പെടുന്നു.
ഞാൻ ശ്രദ്ധാലുവായതുകൊണ്ട് എന്റെ കോഡ് സുരക്ഷിതമാണെന്ന് ഞാൻ കരുതി. എന്നാൽ ഞാൻ തെറ്റാണ്.
ഇവ ഒഴിവാക്കാൻ നിങ്ങളെ സഹായിക്കുന്നതിനായി യഥാർത്ഥ പ്രൊഡക്ഷൻ ബഗുകൾ (production bugs) ഞാൻ പങ്കുവെക്കുന്നു. ഇവ വെറും സിദ്ധാന്തപരമായ ചെക്ക്ലിസ്റ്റുകളല്ല. ഞാൻ നേരിട്ട് ചെയ്ത തെറ്റുകളാണിവ.
കണ്ടിഷണൽ ഓതന്റിക്കേഷൻ കെണി (The Conditional Authentication Trap) ഒരു API secret വെരിഫൈ ചെയ്യുന്നതിന് മുമ്പ് അത് നിലവിലുണ്ടോ എന്ന് പരിശോധിക്കുന്ന രീതിയിലുള്ള കോഡാണ് ഞാൻ എഴുതിയത്. എൻവയോൺമെന്റ് വേരിയബിൾ (environment variable) ഇല്ലെങ്കിൽ, ആ പരിശോധന പൂർണ്ണമായും ഒഴിവാക്കപ്പെട്ടു. ഇതിനർത്ഥം എന്റെ മുഴുവൻ API-യും പൊതുജനങ്ങൾക്ക് ലഭ്യമായിരുന്നു എന്നാണ്. നിയമം: ഒരു secret കാണാതിരിക്കുകയാണെങ്കിൽ, 500 error കാണിച്ചുകൊണ്ട് പ്രക്രിയ അവസാനിപ്പിക്കുക. ഓതന്റിക്കേഷൻ ഒരിക്കലും ഒഴിവാക്കരുത്.
Git ഹിസ്റ്ററി ചോർച്ച (The Git History Leak) ഒരു വേഗത്തിലുള്ള ടെസ്റ്റിനായി ഞാൻ ഒരിക്കൽ ഒരു API key കോഡിൽ നേരിട്ട് എഴുതിയിരുന്നു (hardcoded). പിന്നീട് ഞാൻ അത് ഒരു .env ഫയലിലേക്ക് മാറ്റി, പ്രശ്നം പരിഹരിക്കപ്പെട്ടുവെന്ന് കരുതി. എന്നാൽ Git എല്ലാം ഓർമ്മിച്ചുവെക്കുന്നു. എന്റെ കമിറ്റ് ഹിസ്റ്ററിയിൽ (commit history) ആർക്കും ആ കീ കണ്ടെത്താൻ കഴിയും. നിയമം: നിങ്ങൾ ഒരു കീ കമിറ്റ് ചെയ്താൽ, അത് മോഷ്ടിക്കപ്പെട്ടതായി കരുതുക. ഉടൻ തന്നെ അത് മാറ്റുക (Rotate). നിങ്ങളുടെ ഹിസ്റ്ററി വൃത്തിയാക്കാൻ git-filter-repo ഉപയോഗിക്കുക.
ഡീബഗ് എൻഡ്പോയിന്റ് ചോർച്ച (The Debug Endpoint Leak) പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ സഹായിക്കുന്നതിനായി ഞാൻ പ്രൊഡക്ഷനിൽ ഒരു
/debug/configഎൻഡ്പോയിന്റ് നിലനിർത്തിയിരുന്നു. ഇത് എന്റെ ഡാറ്റാബേസ് URL-കളും എൻവയോൺമെന്റ് സെറ്റിംഗുകളും വെളിപ്പെടുത്തി. നിയമം: ഡിപ്ലോയ്മെന്റിന് മുമ്പ് എല്ലാ ഡീബഗ് എൻഡ്പോയിന്റുകളും നീക്കം ചെയ്യുക. പകരം ലോഗുകൾ (logs) ഉപയോഗിക്കുക.എററുകൾ വഴി സിസ്റ്റം വിവരങ്ങൾ ചോർത്തുന്നു (Leaking System Info via Errors) എന്റെ എറർ റെസ്പോൺസുകളിൽ (error responses) ഞാൻ
str(e)ഉപയോഗിച്ചു. ഇത് ഡാറ്റാബേസ് എററുകളും ഫയൽ പാത്തുകളും നേരിട്ട് ഉപയോക്താവിന് അയച്ചു കൊടുത്തു. നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ മനസ്സിലാക്കാൻ ആക്രമണകാരികൾ ഇത് ഉപയോഗിക്കുന്നു. നിയമം: വിശദമായ എറർ വിവരങ്ങൾ നിങ്ങൾക്കായി ലോഗ് ചെയ്യുക. ക്ലയന്റിന് ഒരു പൊതുവായ "Internal Server Error" മാത്രം അയക്കുക.ഫ്രണ്ട്എൻഡിലെ XSS റിസ്ക് (The XSS Risk in Frontend) ഉപയോക്താക്കളുടെ ഉള്ളടക്കം കാണിക്കാൻ ഞാൻ
innerHTMLഉപയോഗിച്ചു. ഇത് മറ്റ് ഉപയോക്താക്കളുടെ ബ്രൗസറുകളിൽ സ്ക്രിപ്റ്റുകൾ പ്രവർത്തിക്കാൻ അനുവദിച്ചു. നിയമം: എപ്പോഴും HTML എസ്കേപ്പ് (escape) ചെയ്യുക.innerHTML-നെ ഏത് കോഡും പ്രവർത്തിപ്പിക്കാനുള്ള ഒരു മാർഗമായി കാണുക.റേറ്റ് ലിമിറ്റുകളുടെ അഭാവം (Missing Rate Limits) പരിധികളില്ലാതെ വിലകൂടിയ AI മോഡലുകളെ വിളിക്കുന്ന എൻഡ്പോയിന്റുകൾ എനിക്കുണ്ടായിരുന്നു. ഒരു സിംഗിൾ ലൂപ്പോ അല്ലെങ്കിൽ മോഷ്ടിക്കപ്പെട്ട ഒരു കീയോ എനിക്ക് നൂറുകണക്കിന് ഡോളർ നഷ്ടമുണ്ടാക്കിയേക്കാം. നിയമം: ഓതന്റിക്കേഷൻ അനധികൃത ഉപയോക്താക്കളെ തടയുന്നു. റേറ്റ് ലിമിറ്റിംഗ് (Rate limiting) എന്നത് അംഗീകൃത ഉപയോക്താക്കൾ നിങ്ങളുടെ സിസ്റ്റം ദുരുപയോഗം ചെയ്യുന്നത് തടയുന്നു.
അനുവദനീയമായ CORS പോളിസി (Permissive CORS Policy) പ്രൊഡക്ഷനിൽ ഞാൻ
allow_origins=["*"]ഉപയോഗിച്ചു. ഇത് ഏത് സൈറ്റിനും നിങ്ങളുടെ API-ലേക്ക് റിക്വസ്റ്റുകൾ അയക്കാൻ അനുവദിക്കുന്നു. നിയമം: നിങ്ങളുടെ പ്രത്യേക ഫ്രണ്ട്എൻഡ് ഡൊമെയ്ൻ മാത്രം അനുവദിക്കുക.The Temporary File Leak If my code crashed while processing a file, the temporary file stayed on the disk forever. This wastes space and leaks sensitive data. Rule: Use try-finally blocks to ensure files are deleted even if an error occurs.
My new mandatory checklist:
Before coding: • Create a .gitignore • Create a .env.example
For every endpoint: • Add authentication • Use generic error messages • Add rate limits to expensive tasks
Before committing: • Scan for secrets in your diff
Before deploying: • Run security audits on your dependencies
Security issues do not happen by accident. They happen because of "TODO" comments and "temporary" fixes that stay in production forever.
Fixing a bug is boring. Fixing a breach is expensive.