AI ഉപയോഗിച്ച് നിർമ്മിച്ച ആപ്പുകൾക്കുള്ള സുരക്ഷാ ചെക്ക്‌ലിസ്റ്റ്: ലോഞ്ചിന് മുൻപ് എന്ത് പരിശോധിക്കണം

AI ഉപയോഗിച്ച് നിർമ്മിച്ച ആപ്പ് യഥാർത്ഥ ആളുകൾ ഉപയോഗിക്കുന്നതിന് മുൻപ് ഏഴ് കാര്യങ്ങൾ പരിശോധിക്കുക: ഓരോ പേജും API-യും ഉപയോക്താവ് ആരാണെന്നും അയാൾക്ക് എന്ത് ചെയ്യാമെന്നും പരിശോധിക്കുന്നു; രഹസ്യ കീകൾ സെർവറിൽ മാത്രം, ബ്രൗസറിലോ ചാറ്റിലോ അല്ല; എല്ലാ ഇൻപുട്ടും സെർവറിൽ സാധൂകരിക്കുന്നു; ഓരോ ഉപയോക്താവിനും സ്വന്തം റെക്കോർഡുകളിൽ മാത്രമേ എത്താനാകൂ; ലോഗ്-ഇന്നും ചെലവേറിയ എൻഡ്പോയിന്റുകളും റേറ്റ്-ലിമിറ്റ് ചെയ്തിരിക്കുന്നു; ഡിപെൻഡൻസികൾ പുതുക്കിയിരിക്കുന്നു; എന്തെങ്കിലും തെറ്റായാൽ ഡാറ്റ തിരികെ കൊണ്ടുവരാനാകുന്നു. താഴെയുള്ള ചെക്ക്‌ലിസ്റ്റ് ഓരോന്നിനെയും കോഡ് വായിക്കാതെ തന്നെ നിങ്ങൾക്ക് നടത്താവുന്ന പ്രത്യേക പരിശോധനകളാക്കി മാറ്റുന്നു.

AI ആപ്പ് ബിൽഡറുകൾ ഫീച്ചറുകൾ പ്രവർത്തിപ്പിക്കുന്നതിൽ മിടുക്കരാണ്. പക്ഷേ അവ സ്വാഭാവികമായി ജാഗ്രതയുള്ളവയല്ല, കാരണം "ജാഗ്രത" പ്രോംപ്റ്റിൽ അപൂർവമായേ വരുന്നുള്ളൂ. താഴെയുള്ള പ്രശ്നങ്ങളിൽ മിക്കതും ആരും ആവശ്യപ്പെടാത്ത കാര്യങ്ങളിൽനിന്നാണ് വരുന്നത്, അതിനാൽ പരിഹാരം സാധാരണയായി ചോദിക്കുക എന്നതാണ്.

ഈ ചെക്ക്‌ലിസ്റ്റ് എങ്ങനെ ഉപയോഗിക്കാം

ക്രമത്തിൽ പ്രവർത്തിക്കുക, ഓരോ ഇനത്തിനും രണ്ട് കാര്യങ്ങൾ ചെയ്യുക: അത് കൈകാര്യം ചെയ്തിട്ടുണ്ടെന്ന് ഉറപ്പാക്കാൻ AI-യോട് ചോദിക്കുക, അത് നിങ്ങൾ തന്നെ പരീക്ഷിക്കുക. അനുമതി പരിശോധന എഴുതാൻ AI-ക്ക് കഴിയും; അത് പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് ഒരു പരീക്ഷണം മാത്രമേ പറയൂ. ഇനങ്ങൾ ഇങ്ങനെ അടയാളപ്പെടുത്തിയിരിക്കുന്നു:

• Must — ആപ്പ് മറ്റാരെങ്കിലും ഉപയോഗിക്കുന്നതിന് മുൻപ് ഇത് ചെയ്യുക.
• Should — യഥാർത്ഥ ഉപയോക്താക്കൾക്കോ യഥാർത്ഥ ഡാറ്റയ്‌ക്കോ മുൻപ് ഇത് ചെയ്യുക.
• Later — ആപ്പ് വളരുന്തോറും ചെയ്യാൻ യോഗ്യമായത്.

ഒരു മണിക്കൂർ മാത്രമേയുള്ളൂവെങ്കിൽ, എല്ലാ Must ഇനങ്ങളും ചെയ്യുക.

1. ഓത്തന്റിക്കേഷൻ: ഇത് ആരാണ്?

ഓത്തന്റിക്കേഷൻ എന്നാൽ ഒരാൾ ആരാണെന്ന് ഉറപ്പാക്കുന്നത് — സാധാരണയായി ലോഗ്-ഇൻ. അടിസ്ഥാനങ്ങൾക്ക് എന്താണ് ഓത്തന്റിക്കേഷൻ, ഓപ്ഷനുകൾക്ക് നിങ്ങളുടെ ആപ്പിൽ ലോഗ്-ഇൻ എങ്ങനെ ചേർക്കാം കാണുക.

• Must: സ്വകാര്യ ഡാറ്റ കാണിക്കുന്ന ഓരോ പേജിനും ലോഗ്-ഇൻ ആവശ്യമാണ്. പരീക്ഷണം: ലോഗ്-ഔട്ട് ചെയ്യുക, ഒരു സ്വകാര്യ പേജിന്റെ URL നേരിട്ട് ബ്രൗസറിൽ ഒട്ടിക്കുക.
• Must: ആ പേജുകൾക്ക് പിന്നിലുള്ള ഓരോ API എൻഡ്പോയിന്റിനും ലോഗ്-ഇൻ ആവശ്യമാണ് — പേജിന് മാത്രമല്ല. പരീക്ഷണം: ലോഗ്-ഔട്ട് ചെയ്യുക, ബ്രൗസറിന്റെ നെറ്റ്‌വർക്ക് ടാബ് തുറന്ന്, ലോഗ്-ഇൻ ആയിരിക്കുമ്പോൾ ആപ്പ് ഉണ്ടാക്കിയ ഒരു റിക്വസ്റ്റ് വീണ്ടും ശ്രമിക്കുക.
• Must: പാസ്‌വേഡുകൾ പ്ലെയിൻ ടെക്സ്റ്റിലല്ല, സാവധാനമുള്ള പാസ്‌വേഡ്-ഹാഷിങ് അൽഗോരിതം ഉപയോഗിച്ച് ഹാഷ് ചെയ്താണ് സൂക്ഷിക്കുന്നത്. OWASP-ന്റെ പാസ്‌വേഡ് സംഭരണ മാർഗനിർദേശം Argon2id ആണ് ആദ്യം ശുപാർശ ചെയ്യുന്നത്, scrypt, bcrypt, PBKDF2 ബദലുകളായും. ചോദിക്കുക: "പാസ്‌വേഡുകൾ എങ്ങനെയാണ് സൂക്ഷിക്കുന്നത്?"
• Should: പാസ്‌വേഡ് റീസെറ്റ് ലിങ്കുകൾ കാലഹരണപ്പെടുകയും ഒരു തവണ മാത്രം പ്രവർത്തിക്കുകയും ചെയ്യുന്നു.
• Should: സെഷൻ കുക്കികൾ Secure, HttpOnly, SameSite ആയി അടയാളപ്പെടുത്തിയിരിക്കുന്നു, ലോഗ്-ഔട്ട് സെർവറിൽ സെഷൻ അവസാനിപ്പിക്കുന്നു.
• Later: ടു-ഫാക്ടർ ഓത്തന്റിക്കേഷൻ നൽകുക, അല്ലെങ്കിൽ അത് ഉള്ള ഒരു പ്രൊവൈഡർ വഴി സൈൻ-ഇൻ ചെയ്യാൻ അനുവദിക്കുക.

ഉപയോക്തൃ ഡാറ്റ തിരികെ നൽകുന്ന ഓരോ API റൂട്ടും പേജും പരിശോധിക്കുക. ഓരോന്നും ലോഗ്-ഇൻ ചെയ്യാത്ത ഉപയോക്താക്കളിൽനിന്നുള്ള റിക്വസ്റ്റുകൾ നിരസിക്കണം, പേജിന്റെ കോഡിൽ മാത്രമല്ല, സെർവറിൽ. നിങ്ങൾ പരിശോധിച്ച റൂട്ടുകൾ പട്ടികപ്പെടുത്തുക.

2. ഓതറൈസേഷൻ: എന്ത് ചെയ്യാൻ അവർക്ക് അനുമതിയുണ്ട്?

ഓതറൈസേഷൻ എന്നാൽ ലോഗ്-ഇൻ ചെയ്ത ശേഷമുള്ള ഘട്ടം: ഈ പ്രത്യേക ഉപയോക്താവിന് എന്ത് കാണാമെന്നും മാറ്റാമെന്നും തീരുമാനിക്കൽ. AI-നിർമ്മിത ആപ്പുകളിൽ ഏറ്റവും ഗുരുതരമായ പഴുതുകൾ പലപ്പോഴും ഇവിടെയാണ്, കാരണം ആപ്പ് ശരിയായി കാണപ്പെടുന്നു — ഓരോ ഉപയോക്താവിന്റെയും ഡാഷ്‌ബോർഡ് അവരുടെ ഡാറ്റ മാത്രം കാണിക്കുന്നു — പക്ഷേ സെർവർ നേരിട്ട് ചോദിച്ചാൽ ആരുടെ ഡാറ്റയും സന്തോഷത്തോടെ നൽകും.

• Must: ഓരോ വായന, അപ്ഡേറ്റ്, ഡിലീറ്റിലും, റെക്കോർഡ് നിലവിലെ ഉപയോക്താവിന്റേതാണ് (അല്ലെങ്കിൽ അവരുടെ ടീമിന്റേതാണ്) എന്ന് സെർവറിൽ പരിശോധിക്കുന്നു.
• Must: പരീക്ഷിക്കുക: A, B എന്നീ രണ്ട് അക്കൗണ്ടുകൾ ഉണ്ടാക്കുക. A ആയി A-യുടെ ഒരു റെക്കോർഡ് തുറന്ന്, URL-ലോ നെറ്റ്‌വർക്ക് റിക്വസ്റ്റിലോ ഉള്ള ID ശ്രദ്ധിക്കുക. B ആയി ലോഗ്-ഇൻ ചെയ്ത് അതേ ID അഭ്യർത്ഥിക്കുക. B-ക്ക് പിശക് കിട്ടണം, A-യുടെ ഡാറ്റ അല്ല.
• Must: അഡ്മിൻ പേജുകളും അഡ്മിൻ API എൻഡ്പോയിന്റുകളും ഉപയോക്താവിന്റെ റോൾ സെർവറിൽ പരിശോധിക്കുന്നു. അഡ്മിൻ ലിങ്ക് ഒളിപ്പിക്കുന്നത് സംരക്ഷണമല്ല.
• Must: റിക്വസ്റ്റ് എഡിറ്റ് ചെയ്ത് ഉപയോക്താക്കൾക്ക് സ്വന്തം റോൾ, വില, ബാലൻസ്, ഓണർ ഫീൽഡുകൾ മാറ്റാനാകില്ല. പരീക്ഷണം: നെറ്റ്‌വർക്ക് ടാബിൽ, പ്രൊഫൈൽ അപ്ഡേറ്റ് എന്താണ് അയയ്ക്കുന്നതെന്ന് നോക്കുക. role അല്ലെങ്കിൽ isAdmin പോലുള്ള ഫീൽഡുകൾ ഉണ്ടെങ്കിൽ, ക്ലയന്റിൽനിന്ന് അവ അവഗണിക്കാൻ AI-യോട് ആവശ്യപ്പെടുക.
• Should: URL-ലെ IDകൾ ഊഹിക്കാൻ പ്രയാസമാണ് (1, 2, 3 എന്നതിന് പകരം റാൻഡം IDകൾ). ഇത് അനുമതി പരിശോധനകൾക്ക് പകരമല്ല, പക്ഷേ ഒന്ന് നഷ്ടപ്പെട്ടാൽ നാശം പരിമിതപ്പെടുത്തുന്നു.

റെക്കോർഡ് വായിക്കുകയോ മാറ്റുകയോ ചെയ്യുന്ന ഓരോ എൻഡ്പോയിന്റിനും, ലോഗ്-ഇൻ ചെയ്ത ഉപയോക്താവ് അത് സ്വന്തമാക്കുന്നുണ്ടോ അല്ലെങ്കിൽ ആക്സസ് ചെയ്യാൻ അനുമതിയുണ്ടോ എന്ന് സെർവറിൽ പരിശോധിക്കുക. ഇല്ലെങ്കിൽ 404 തിരികെ നൽകുക. എന്നിട്ട് രണ്ട് അക്കൗണ്ടുകൾ ഉപയോഗിച്ച് ഇത് എങ്ങനെ പരീക്ഷിക്കുമെന്ന് കാണിക്കുക.

3. ഡാറ്റാബേസിലെ റോ-ലെവൽ ആക്സസ്

"റോ-ലെവൽ ആക്സസ്" എന്നാൽ ഒരു ടേബിളിലെ ഓരോ റോയും (ഒരു ബുക്കിങ്, ഒരു ഇൻവോയ്സ്) അത് സ്വന്തമായ ഉപയോക്താക്കൾക്ക് മാത്രം ദൃശ്യമാകുക എന്നാണ്. ഇത് നടപ്പാക്കാൻ രണ്ട് സാധാരണ വഴികളുണ്ട്:

രണ്ടും നന്നായി ചെയ്യാം. പ്രധാനം ഇവയാണ്:

• Must: ബ്രൗസർ ഡാറ്റാബേസുമായി നേരിട്ട് സംസാരിക്കുന്നെങ്കിൽ (ചില ഹോസ്റ്റഡ് ഡാറ്റാബേസ് ഉൽപ്പന്നങ്ങൾ ഇത് അനുവദിക്കുന്നു), ഓരോ ടേബിളിനും റോ-ലെവൽ നിയമങ്ങൾ ഓണാണ്. അവ ഇല്ലെങ്കിൽ, പബ്ലിക് കീ ഉള്ള ആർക്കും മുഴുവൻ ടേബിളും വായിക്കാം.
• Must: ക്വറികൾ നിലവിലെ ഉപയോക്താവിനെയോ ടീമിനെയോ ഫിൽട്ടർ ചെയ്യുന്നു, ബ്രൗസർ അയയ്ക്കുന്ന ഒരു ID വെച്ചല്ല.
• Should: പങ്കിട്ട ഡാറ്റയ്ക്ക് (ഒരു ടീമിന്റെ പ്രോജക്റ്റുകൾ) ആരാണ് ടീമിൽ ഉള്ളതെന്ന് വ്യക്തമായ നിയമമുണ്ട്, ഒരിടത്ത് നടപ്പാക്കുന്നു.

4. രഹസ്യങ്ങളും API കീകളും

API കീ ഒരു സേവനത്തിനുള്ള പാസ്‌വേഡാണ്. Stripe, ഇമെയിൽ, AI പ്രൊവൈഡർമാർ എല്ലാം ഇവ ഉപയോഗിക്കുന്നു. പശ്ചാത്തലത്തിന്, എന്താണ് എൻവയോൺമെന്റ് വേരിയബിളുകളും സീക്രട്ടുകളും കാണുക.

• Must: കീകൾ പ്രോജക്റ്റിന്റെ എൻവയോൺമെന്റ് വേരിയബിളുകളിലോ സീക്രട്ടുകളിലോ സൂക്ഷിക്കുന്നു, കോഡിൽ എഴുതിയിട്ടില്ല.
• Must: പണം ചെലവാക്കാനോ സ്വകാര്യ ഡാറ്റ വായിക്കാനോ കഴിയുന്ന കീകൾ സെർവറിൽ മാത്രം ഉപയോഗിക്കുന്നു. പരീക്ഷണം: നിങ്ങളുടെ ലൈവ് സൈറ്റ് തുറന്ന്, പേജ് സോഴ്സും ഡെവ്‌ടൂൾസിലെ JavaScript ഫയലുകളും കാണുക, കീയുടെ ആരംഭം (ഉദാഹരണത്തിന് sk_) തിരയുക. അത് കാണരുത്.
• Must: കീകൾ ഒരിക്കലും ചാറ്റിലോ പബ്ലിക് റിപ്പോസിറ്ററിയിലോ സ്ക്രീൻഷോട്ടിലോ ഒട്ടിച്ചിട്ടില്ല. ഒട്ടിച്ചിട്ടുണ്ടെങ്കിൽ, പ്രൊവൈഡറിൽ അത് റൊട്ടേറ്റ് ചെയ്യുക (പുതിയത് ഉണ്ടാക്കി പഴയത് നീക്കം ചെയ്യുക).
• Should: പ്രൊവൈഡർ അനുവദിക്കുന്നിടത്ത് റെസ്ട്രിക്റ്റഡ് അല്ലെങ്കിൽ സ്കോപ്പ്ഡ് കീകൾ ഉപയോഗിക്കുക. ഉദാഹരണത്തിന് Stripe, ഇന്റഗ്രേഷന് ആവശ്യമായ അനുമതികൾ മാത്രമുള്ള റെസ്ട്രിക്റ്റഡ് കീകൾ ശുപാർശ ചെയ്യുന്നു.
• Should: ടെസ്റ്റ്, ലൈവ് കീകൾ വേറെയാണ്, നിങ്ങൾ തയ്യാറാകുമ്പോൾ മാത്രം ലൈവ് ആപ്പ് ലൈവ് കീകൾ ഉപയോഗിക്കുന്നു.

ചില കീകൾ പബ്ലിക് ആയിരിക്കാൻ രൂപകൽപ്പന ചെയ്തവയാണ് — Stripe-ന്റെ publishable key (pk_…), അല്ലെങ്കിൽ നിങ്ങളുടെ ഡൊമെയ്‌നിൽ മാത്രം നിയന്ത്രിച്ച മാപ്സ് കീ. നിയമം ശക്തി നൽകുന്ന കീകളെക്കുറിച്ചാണ്, കീ പോലെ തോന്നുന്ന ഓരോ സ്ട്രിങ്ങിനെയും കുറിച്ചല്ല.

5. ഇൻപുട്ട് സാധൂകരണം

ഉപയോക്താവ് അയയ്ക്കുന്ന ഏതും — ഫോം ഫീൽഡുകൾ, ഫയൽ അപ്‌ലോഡുകൾ, URL പാരാമീറ്ററുകൾ — നിങ്ങളുടെ ഫോം അനുവദിക്കുന്നതിന് അപ്പുറം എന്തും ആകാം.

• Must: സാധൂകരണം സെർവറിലാണ്, ബ്രൗസറിൽ മാത്രമല്ല. ബ്രൗസർ പരിശോധനകൾ സൗകര്യത്തിനാണ്; ആർക്കും അവ ഒഴിവാക്കാം.
• Must: ഡാറ്റാബേസ് ക്വറികൾ പാരാമീറ്ററുകൾ ഉപയോഗിക്കുന്നു, ഉപയോക്തൃ ഇൻപുട്ടിൽനിന്നുള്ള ടെക്സ്റ്റ് ഒട്ടിച്ചു ചേർത്തതല്ല (ഇത് SQL ഇൻജെക്ഷൻ തടയുന്നു). AI-യോട് ഉറപ്പാക്കാൻ ആവശ്യപ്പെടുക.
• Must: ഉപയോക്താക്കൾ നൽകുന്ന ടെക്സ്റ്റ് HTML ആയി പ്രവർത്തിക്കാതെ ടെക്സ്റ്റായി കാണിക്കുന്നു. പരീക്ഷണം: നിങ്ങളുടെ പേരായി <b>hello</b> നൽകുക. ബോൾഡ് ടെക്സ്റ്റിന് പകരം ടാഗുകൾ കാണണം.
• Should: ഫയൽ അപ്‌ലോഡുകൾ തരവും വലിപ്പവും പരിശോധിക്കുന്നു, അപ്‌ലോഡ് ചെയ്ത ഫയലുകൾ ആപ്പിന്റെ പ്രധാന ഡൊമെയ്‌നിൽനിന്ന് പ്രവർത്തിക്കാവുന്ന പേജുകളായി നൽകുന്നില്ല.
• Should: ഉപയോക്താക്കൾക്ക് കാണിക്കുന്ന പിശകുകൾ ലളിതമാണ് ("എന്തോ തെറ്റ് സംഭവിച്ചു"); വിശദമായ പിശകുകൾ സെർവർ ലോഗുകളിൽ മാത്രം പോകുന്നു.
• Should: Stripe പോലുള്ള സേവനങ്ങളിൽനിന്നുള്ള വെബ്‌ഹുക്കുകൾ പ്രവർത്തിക്കുന്നതിന് മുൻപ് പ്രൊവൈഡറുടെ സിഗ്നേച്ചർ പരിശോധിക്കുന്നു. എന്താണ് വെബ്‌ഹുക്ക് കാണുക.

ഓരോ ഫോമിനും API എൻഡ്പോയിന്റിനും സെർവർ-സൈഡ് സാധൂകരണം ചേർക്കുക: ആവശ്യമായ ഫീൽഡുകൾ, നീളം, ഫോർമാറ്റുകൾ, അനുവദനീയ മൂല്യങ്ങൾ. മറ്റെന്തും വ്യക്തമായ സന്ദേശത്തോടെ നിരസിക്കുക. ആന്തരിക പിശക് വിശദാംശങ്ങൾ ഉപയോക്താക്കളെ കാണിക്കരുത്.

6. റേറ്റ് ലിമിറ്റുകളും ദുരുപയോഗവും

റേറ്റ് ലിമിറ്റ് ഒരു കാലയളവിൽ ഒരാൾക്ക് എത്ര റിക്വസ്റ്റ് അയയ്ക്കാമെന്ന് പരിമിതപ്പെടുത്തുന്നു. ഇല്ലെങ്കിൽ ആർക്കും ദിവസം മുഴുവൻ പാസ്‌വേഡ് ഊഹിക്കാം, സൈൻ-അപ്പ് ഫോം നിറയ്ക്കാം, അല്ലെങ്കിൽ പണമടയ്ക്കുന്ന API-യിൽ ബിൽ കൂട്ടാം.

• Must: ലോഗ്-ഇൻ, സൈൻ-അപ്പ്, പാസ്‌വേഡ് റീസെറ്റ് എന്നിവ IP വിലാസം അനുസരിച്ചും അക്കൗണ്ട് അനുസരിച്ചും റേറ്റ്-ലിമിറ്റ് ചെയ്തിരിക്കുന്നു.
• Must: ഓരോ കോളിനും നിങ്ങൾക്ക് പണം ചെലവാകുന്ന എന്തും — AI മോഡൽ റിക്വസ്റ്റുകൾ, SMS, ഇമെയിൽ — ഓരോ ഉപയോക്താവിനും പരിധിയുണ്ട്, ലോഗ്-ഇൻ ആവശ്യമാണ്.
• Should: പബ്ലിക് ഫോമുകൾക്ക് (കോൺടാക്റ്റ്, വെയിറ്റ്‌ലിസ്റ്റ്) സ്പാം സംരക്ഷണമുണ്ട്: റേറ്റ് ലിമിറ്റ്, ഒളിഞ്ഞ ഹണിപോട്ട് ഫീൽഡ്, അല്ലെങ്കിൽ CAPTCHA.
• Should: പെയ്ഡ് പ്രൊവൈഡർമാരിൽ ചെലവ് പരിധികളോ അലേർട്ടുകളോ സജ്ജമാക്കുക, ഒരു ബഗോ ആക്രമണകാരിയോ അനന്തമായ ബിൽ ഉണ്ടാക്കാതിരിക്കാൻ.

7. ഡിപെൻഡൻസികൾ

ആപ്പുകൾ ഓപ്പൺ-സോഴ്‌സ് പാക്കേജുകളിൽനിന്നാണ് നിർമ്മിക്കുന്നത്, പാക്കേജുകളിൽ ചിലപ്പോൾ അറിയപ്പെടുന്ന ദുർബലതകൾ ഉണ്ടാകാം.

• Should: അറിയപ്പെടുന്ന ദുർബലതകൾ പരിശോധിക്കാൻ AI-യോട് ആവശ്യപ്പെടുക (JavaScript പ്രോജക്റ്റുകൾക്ക് npm audit അല്ലെങ്കിൽ നിങ്ങളുടെ പാക്കേജ് മാനേജർക്ക് തുല്യമായത്), ബാധിച്ചവ പുതുക്കുക.
• Should: ആപ്പ് ഇനി ഉപയോഗിക്കാത്ത പാക്കേജുകൾ നീക്കം ചെയ്യുക.
• Should: വളരെ കുറച്ച് ഉപയോക്താക്കളുള്ള പാക്കേജുകളെയും, പ്രശസ്തമായവയുടെ അക്ഷരത്തെറ്റുകൾ പോലെ തോന്നുന്ന പേരുകളെയും സൂക്ഷിക്കുക.
• Later: ഒന്നോ രണ്ടോ മാസം കൂടുമ്പോൾ വീണ്ടും പരിശോധിക്കുക, അല്ലെങ്കിൽ നിങ്ങളുടെ കോഡ് GitHub-ൽ ആണെങ്കിൽ ഓട്ടോമേറ്റഡ് അലേർട്ടുകൾ ഓണാക്കുക.

8. ബാക്കപ്പുകളും വീണ്ടെടുക്കലും

സുരക്ഷയിൽ തെറ്റുകളിൽനിന്ന് വീണ്ടെടുക്കാനുള്ള കഴിവും ഉൾപ്പെടുന്നു — നിങ്ങളുടേതോ AI-യുടേതോ ആക്രമണകാരിയുടേതോ ആയ.

• Must: നിങ്ങളുടെ ഡാറ്റ എവിടെയാണെന്നും അത് ബാക്കപ്പ് ചെയ്യുന്നുണ്ടോ എന്നും അറിയുക. ഊഹിക്കരുത്; ഹോസ്റ്റിന്റെ ഡോക്യുമെന്റേഷനിൽ പരിശോധിക്കുക.
• Should: പ്രധാന ഡാറ്റയുടെ ഒരു കാലാനുസൃത എക്സ്പോർട്ട് സ്വന്തമായി സൂക്ഷിക്കുക (ഉദാഹരണത്തിന് CSV എക്സ്പോർട്ട് ഫീച്ചർ അല്ലെങ്കിൽ ഡാറ്റാബേസ് ഡംപ്), മറ്റൊരിടത്ത്.
• Should: നിങ്ങളുടെ കോഡ് വേർഷൻ കൺട്രോളിൽ സൂക്ഷിക്കുക, അതിനാൽ ഏത് പതിപ്പും തിരികെ കൊണ്ടുവരാം.
• Should: നശിപ്പിക്കുന്ന പ്രവർത്തനങ്ങൾ (അക്കൗണ്ട് ഡിലീറ്റ്, പ്രോജക്റ്റ് ഡിലീറ്റ്) സ്ഥിരീകരണം ചോദിക്കുന്നു, കുറച്ചുകാലം പഴയപടിയാക്കാവുന്ന "soft delete" പരിഗണിക്കുക.
• Later: ഒരിക്കൽ വീണ്ടെടുക്കൽ യഥാർത്ഥത്തിൽ പരീക്ഷിക്കുക. ഒരിക്കലും പുനഃസ്ഥാപിച്ചിട്ടില്ലാത്ത ബാക്കപ്പ് ഒരു പ്രതീക്ഷയാണ്, പദ്ധതിയല്ല.

9. ലോഞ്ചിന് മുൻപ്

• Must: ലൈവ് സൈറ്റ് എല്ലായിടത്തും HTTPS ഉപയോഗിക്കുന്നു.
• Must: ഡെവലപ്‌മെന്റിൽനിന്നുള്ള സാമ്പിൾ ഡാറ്റ, ടെസ്റ്റ് അക്കൗണ്ടുകൾ, ഡീബഗ് പേജുകൾ നീക്കം ചെയ്തിരിക്കുന്നു.
• Should: വ്യക്തിഗത ഡാറ്റ ശേഖരിക്കുന്നതെന്തിനെന്നും എന്തിനാണെന്നും പ്രൈവസി പോളിസി പറയുന്നു — വ്യക്തിഗത ഡാറ്റ ശേഖരിക്കുന്നെങ്കിൽ പല സ്ഥലങ്ങളിലും ഇത് നിർബന്ധമാണ്. നിങ്ങൾക്ക് ഇല്ലാത്ത സർട്ടിഫിക്കേഷനുകൾ (SOC 2, HIPAA) അവകാശപ്പെടരുത്.
• Should: സുരക്ഷാ പ്രശ്നങ്ങൾക്ക് ബന്ധപ്പെടാൻ ഒരു മാർഗമുണ്ട്, എല്ലാ കീകളും വേഗത്തിൽ റൊട്ടേറ്റ് ചെയ്യാൻ അറിയാം.

സുരക്ഷയ്ക്ക് അപ്പുറമുള്ള വിശാലമായ ലോഞ്ചിന് മുൻപുള്ള പരിശോധനയ്ക്ക്, AI പ്രോട്ടോടൈപ്പ് പ്രൊഡക്ഷനിലേക്ക് എങ്ങനെ കൊണ്ടുപോകാം കാണുക.

എപ്പോൾ പ്രൊഫഷണൽ അവലോകനം വേണം

ഒരു ചെക്ക്‌ലിസ്റ്റ് സാധാരണ തെറ്റുകൾ പിടിക്കുന്നു; അത് ഒരു വിദഗ്ധന് പകരമാകുന്നില്ല. കാർഡ് നമ്പറുകൾ ഹോസ്റ്റഡ് ചെക്കൗട്ടിന് പകരം നിങ്ങൾ തന്നെ കൈകാര്യം ചെയ്യുകയോ, ആരോഗ്യം, സാമ്പത്തിക അല്ലെങ്കിൽ കുട്ടികളുടെ ഡാറ്റ സൂക്ഷിക്കുകയോ, സുരക്ഷാ ചോദ്യാവലികൾ ആവശ്യപ്പെടുന്ന കമ്പനികൾക്ക് വിൽക്കുകയോ, അല്ലെങ്കിൽ ചോർച്ചയിൽ ഗുരുതരമായി ബാധിക്കപ്പെടുകയോ ചെയ്യുന്നെങ്കിൽ ഒരു അവലോകനത്തിന് പണം നൽകുന്നത് പരിഗണിക്കുക. നിങ്ങളുടെ കോഡ് എക്സ്പോർട്ട് ചെയ്യാവുന്നതാണെങ്കിൽ അത്തരം അവലോകനം വളരെ എളുപ്പമാകും.

Mythex-ൽ നിർമ്മിക്കുമ്പോൾ സുരക്ഷ

Mythex-ന് പ്രത്യേക സുരക്ഷാ-സ്കാൻ പാനൽ ഇല്ല, അതിനാൽ മുകളിലുള്ള ചെക്ക്‌ലിസ്റ്റാണ് പിന്തുടരേണ്ട പ്രക്രിയ. സഹായകമായ ചില കാര്യങ്ങൾ:

• പ്രോജക്റ്റ് സീക്രട്ടുകൾ. പ്രോജക്റ്റ് സെറ്റിങ്സ് → Secrets വഴിയോ, ഏജന്റ് ചാറ്റിൽ കാണിക്കുന്ന സീക്രട്ട്സ് കാർഡ് വഴിയോ കീകൾ സൂക്ഷിക്കുക, അവ കോഡിലും സന്ദേശങ്ങളിലും എത്താതിരിക്കാൻ. ലൈവ് ആപ്പിന്റെ ഒരു സീക്രട്ട് മാറ്റിയ ശേഷം വീണ്ടും പ്രസിദ്ധീകരിക്കുക.
• Plan, Ask മോഡുകൾ. എഡിറ്റ് ചെയ്യാതെ അനുമതികൾ അവലോകനം ചെയ്യാൻ ഏജന്റിനോട് ആവശ്യപ്പെടുക: "Ask മോഡിൽ, ഓരോ API റൂട്ടും അത് ചെയ്യുന്ന അനുമതി പരിശോധന പട്ടികപ്പെടുത്തുക."
• /test ഏജന്റ് നിങ്ങളുടെ പ്രിവ്യൂവിൽ ഒരു ഉപയോക്താവായി ക്ലിക്ക് ചെയ്ത് പോകുന്നു — സെക്ഷൻ 2-ലെ രണ്ട്-അക്കൗണ്ട് പരീക്ഷണത്തിന് ഉപയോഗപ്രദം.
• Checkpoints തകർത്ത ഒരു മാറ്റം തിരികെ എടുക്കാൻ അനുവദിക്കുന്നു.

ആപ്പുകൾക്കുള്ള സുരക്ഷ, എൻവയോൺമെന്റ് വേരിയബിളുകളും സീക്രട്ടുകളും എന്നിവ ഡോക്സിൽ കാണുക. അടുത്തതായി ഉപയോക്തൃ അക്കൗണ്ടുകൾ ചേർക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ ആപ്പിൽ ലോഗ്-ഇൻ എങ്ങനെ ചേർക്കാം വായിക്കുക.

ചോദ്യങ്ങൾ