നിങ്ങളുടെ ആപ്പിൽ API കീകൾ സുരക്ഷിതമായി സൂക്ഷിക്കുന്നത് എങ്ങനെ
API കീകൾ സുരക്ഷിതമാക്കാൻ, അവ നിങ്ങളുടെ ഹോസ്റ്റിൽ secrets അല്ലെങ്കിൽ environment variables ആയി സൂക്ഷിക്കുക, സെർവർ-സൈഡ് കോഡിൽ മാത്രം ഉപയോഗിക്കുക, ഒരിക്കലും ചാറ്റിലോ കോഡ് ഫയലുകളിലോ സ്ക്രീൻഷോട്ടുകളിലോ Git റിപ്പോസിറ്ററിയിലോ ഒട്ടിക്കരുത്. ഓരോ കീക്കും ആവശ്യമുള്ളത്ര കുറഞ്ഞ അനുമതി മാത്രം നൽകുക, ദാതാവിൽ ചെലവ് പരിധി വെക്കുക. ഒരു കീ ചോർന്നാൽ അത് മറയ്ക്കുന്നതിന് പകരം മാറ്റുക: പുതിയത് ഉണ്ടാക്കി പഴയത് ഡിലീറ്റ് ചെയ്യുക.
API കീ എന്നാൽ ഒരു സേവനത്തിന്റെ പാസ്വേഡ് ആണ്. നിങ്ങളുടെ OpenAI കീ ഉപയോഗിച്ച് ആരെങ്കിലും നിങ്ങളുടെ പണം AI-ക്കായി ചെലവാക്കാം; Stripe secret key ഉപയോഗിച്ച് റീഫണ്ടുകൾ നൽകാം; ഇമെയിൽ ദാതാവിന്റെ കീ ഉപയോഗിച്ച് നിങ്ങളുടെ പേരിൽ മെയിൽ അയക്കാം. AI ആപ്പ് ബിൽഡറുകൾ ഇവ ബന്ധിപ്പിക്കുന്നതിൽ മിടുക്കരാണെങ്കിലും ഇവ എവിടെയെത്തുന്നു എന്നതിൽ എപ്പോഴും ശ്രദ്ധിക്കാറില്ല. അതിനാൽ ഈ ഗൈഡ് അവ എങ്ങനെ സുരക്ഷിതമാക്കാം, എങ്ങനെ പരിശോധിക്കാം എന്നാണ് പറയുന്നത്.
പബ്ലിക് കീകളും സീക്രട്ട് കീകളും
എല്ലാ കീകളും രഹസ്യമല്ല. ഇതിലെ വ്യത്യാസം അറിയുന്നത് തെറ്റായ കീയെക്കുറിച്ച് വെറുതെ പരിഭ്രമിക്കാതിരിക്കാനും ശരിയായ കീയെ അവഗണിക്കാതിരിക്കാനും സഹായിക്കും.
| തരം | ഉദാഹരണങ്ങൾ | ബ്രൗസറിൽ ആകാമോ? |
|---|---|---|
| Publishable / പബ്ലിക് കീകൾ | Stripe pk_… കീ, നിങ്ങളുടെ ഡൊമെയ്നിൽ പരിമിതപ്പെടുത്തിയ maps കീ, ചില analytics ID-കൾ | അതെ — അതിനായി രൂപകൽപ്പന ചെയ്തത് |
| Secret കീകൾ | Stripe sk_…, OpenAI, Anthropic കീകൾ, ഇമെയിൽ ദാതാവിന്റെ കീകൾ, ഡാറ്റാബേസ് പാസ്വേഡുകൾ | ഒരിക്കലുമില്ല |
| സർവീസ്/അഡ്മിൻ കീകൾ | ഹോസ്റ്റഡ് ഡാറ്റാബേസിലെ ആക്സസ് നിയമങ്ങൾ മറികടക്കുന്ന കീകൾ | ഒരിക്കലുമില്ല — ഏറ്റവും സെൻസിറ്റീവ് ആയി കണക്കാക്കുക |
ഏത് തരം കീയാണെന്ന് ഉറപ്പില്ലെങ്കിൽ ദാതാവിന്റെ ഡോക്യുമെന്റേഷൻ നോക്കുക. സംശയം തോന്നിയാൽ അത് സീക്രട്ട് ആയി കണക്കാക്കുക.
ഘട്ടം 1: കീകൾ കോഡിന് പുറത്ത് സീക്രട്ടുകളായി സൂക്ഷിക്കുക
കീകൾ നിങ്ങളുടെ ഹോസ്റ്റിന്റെ environment variables അല്ലെങ്കിൽ secrets ക്രമീകരണത്തിലാണ് സൂക്ഷിക്കേണ്ടത്. നിങ്ങളുടെ കോഡ് അവയെ റൺടൈമിൽ പേര് വെച്ച് വായിക്കുന്നു (ഉദാഹരണത്തിന് process.env.OPENAI_API_KEY), അതുകൊണ്ട് മൂല്യം ഒരിക്കലും ഫയലുകളിൽ വരുന്നില്ല. പശ്ചാത്തലം അറിയാൻ environment variables, secrets എന്താണ് എന്ന് വായിക്കുക.
എല്ലാ API കീകളും കോഡിൽ നിന്ന് മാറ്റി environment variables-ലേക്ക് നീക്കുക. നിങ്ങൾ കണ്ടെത്തിയ ഓരോ കീയും, അത് ഏത് ഫയലിലായിരുന്നു, നിങ്ങൾ ഉപയോഗിച്ച variable പേര് എന്നിവ പട്ടികപ്പെടുത്തുക. മൂല്യങ്ങൾ കാണിക്കരുത്.
പിന്നെ ഒന്നും ബാക്കിയില്ലെന്ന് ഉറപ്പാക്കുക:
config ഫയലുകളും
.envഫയലുകളും ഉൾപ്പെടെ മുഴുവൻ പ്രോജക്റ്റിലും API കീ അല്ലെങ്കിൽ പാസ്വേഡ് പോലെ തോന്നുന്നതെന്തും തിരയുക. ഫയലും വരിയും മാത്രം റിപ്പോർട്ട് ചെയ്യുക, മൂല്യം വേണ്ട.
ഘട്ടം 2: സീക്രട്ട് കീകൾ സെർവറിൽ മാത്രം ഉപയോഗിക്കുക
ഏറ്റവും പ്രധാനപ്പെട്ട നിയമം ഇതാണ്. ബ്രൗസറിന് കിട്ടുന്നതെന്തും ഒരു സന്ദർശകന് വായിക്കാം — പേജ് സോഴ്സും JavaScript ഫയലുകളും developer tools-ൽ എല്ലാവർക്കും കാണാം.
അതുകൊണ്ട് ആപ്പിന് OpenAI വിളിക്കണമെങ്കിൽ ബ്രൗസർ നിങ്ങളുടെ സെർവറിനെ വിളിക്കണം, സെർവർ കീ ഉപയോഗിച്ച് OpenAI-യെ വിളിക്കണം. കീ ഒരിക്കലും സെർവർ വിട്ടുപോകരുത്.
ചാറ്റ് ഫീച്ചർ ബ്രൗസറിൽ നിന്ന് നേരിട്ട് OpenAI-യെ വിളിക്കുന്നു. ആ വിളി ഒരു സെർവർ API route-ലേക്ക് മാറ്റുക, അത് OPENAI_API_KEY environment-ൽ നിന്ന് വായിക്കണം. ബ്രൗസർ നമ്മുടെ route-നെ മാത്രം വിളിക്കണം. ആ route-ന് ലോഗിൻ നിർബന്ധമാക്കുക.
ഫ്രണ്ടെൻഡ് ഫ്രെയിംവർക്കുകളിലെ ഒരു സാധാരണ കെണി ശ്രദ്ധിക്കുക: VITE_ (Vite-ൽ), NEXT_PUBLIC_ (Next.js-ൽ) പോലുള്ള പബ്ലിക് prefix ഉള്ള variables ബ്രൗസർ കോഡിൽ മനഃപൂർവം ഉൾപ്പെടുത്തുന്നവയാണ്. സീക്രട്ട് കീക്ക് ഇത്തരം prefix ഉണ്ടെങ്കിൽ അത് "environment variable-ൽ" ആണെങ്കിലും ചോർന്നിരിക്കുന്നു.
ഘട്ടം 3: ഒന്നും ചോരുന്നില്ലെന്ന് പരിശോധിക്കുക
പ്രവർത്തിച്ചെന്ന് വിശ്വസിക്കരുത് — ലൈവ് സൈറ്റിൽ പരിശോധിക്കുക:
- പബ്ലിഷ് ചെയ്ത ആപ്പ് ബ്രൗസറിൽ തുറക്കുക.
- Developer tools തുറക്കുക, തുടർന്ന് Sources അല്ലെങ്കിൽ Network ടാബ്.
- ഓരോ സീക്രട്ട് കീയുടെയും ആദ്യ അക്ഷരങ്ങൾ (ഉദാഹരണത്തിന്
sk_അല്ലെങ്കിൽsk-) എല്ലാ ഫയലുകളിലും തിരയുക. - ആപ്പ് നടത്തുന്ന network requests പരിശോധിക്കുക. ബ്രൗസറിൽ നിന്ന് നേരിട്ട് പണമടച്ചുള്ള AI ദാതാവിലേക്ക് പോകുന്ന request ഒരു അപായ സൂചനയാണ്.
ഒരു സീക്രട്ട് കീ കണ്ടെത്തിയാൽ അത് സെർവറിലേക്ക് മാറ്റുക (ഘട്ടം 2), പിന്നെ മാറ്റുക (ഘട്ടം 6), കാരണം അത് ഇതിനകം പബ്ലിക് ആയിരുന്നു.
ഘട്ടം 4: ഓരോ കീക്കും എന്തെല്ലാം ചെയ്യാനാകുമെന്ന് പരിമിതപ്പെടുത്തുക
പല ദാതാക്കളും കീ പരിമിതപ്പെടുത്താൻ അനുവദിക്കുന്നു:
- Scoped അല്ലെങ്കിൽ restricted keys: ആപ്പിന് ആവശ്യമുള്ളത് മാത്രം ചെയ്യാൻ കഴിയുന്നവ. ഉദാഹരണത്തിന് Stripe-ൽ നിർദ്ദിഷ്ട അനുമതികളോടെ restricted keys ഉണ്ട്.
- ഡൊമെയ്ൻ അല്ലെങ്കിൽ IP നിയന്ത്രണങ്ങൾ: maps കീ പോലെ പബ്ലിക് ആയിരിക്കണ്ട കീകൾക്ക്.
- ഓരോ ആപ്പിനും ഓരോ environment-നും പ്രത്യേക കീകൾ: ഒന്ന് ചോർന്നാൽ എല്ലാം തുറന്നുപോകില്ല, ഒന്ന് റദ്ദാക്കിയാൽ മറ്റുള്ളവ തകരില്ല.
- നിർമ്മാണ സമയത്ത് ടെസ്റ്റ് കീകൾ, ലൈവ് കീകൾ പബ്ലിഷ് ചെയ്ത ആപ്പിൽ മാത്രം.
ഘട്ടം 5: നാശനഷ്ടത്തിന് ഒരു പരിധി വെക്കുക
നന്നായി സംരക്ഷിച്ച കീ പോലും നിങ്ങളുടെ ആപ്പിലൂടെ ദുരുപയോഗം ചെയ്യപ്പെടാം — ഉദാഹരണത്തിന് ആരെങ്കിലും നിങ്ങളുടെ AI ഫീച്ചറിനെ ആയിരക്കണക്കിന് തവണ സ്ക്രിപ്റ്റ് ചെയ്ത് വിളിക്കുന്നത്.
- ഓരോ പണമടച്ചുള്ള ദാതാവിലും ചെലവ് പരിധിയോ അലേർട്ടുകളോ വെക്കുക.
- ഓരോ കോളിനും പണം ചെലവാകുന്ന ഏത് ഫീച്ചറിനും ലോഗിൻ നിർബന്ധമാക്കുക.
- ഒരു ഉപയോക്താവിന് ഒരു പരിധി (per-user rate limit) ചേർക്കുക. rate limiting എന്താണ് എന്ന് കാണുക.
/api/chat-ലേക്ക് ഓരോ ഉപയോക്താവിനും മണിക്കൂറിൽ 30 AI request എന്ന പരിധി ചേർക്കുക. പരിധി എത്തുമ്പോൾ വ്യക്തമായ സന്ദേശം കാണിക്കുക. ലോഗിൻ ചെയ്യാത്ത ഉപയോക്താക്കളുടെ request-കൾ നിരസിക്കുക.
ഘട്ടം 6: ചോർന്ന കീകൾ മാറ്റുക
സീക്രട്ട് കീ പാടില്ലാത്ത ഒരിടത്ത് എത്തിയാൽ — ചാറ്റ് സന്ദേശം, commit, സ്ക്രീൻഷോട്ട്, സപ്പോർട്ട് ടിക്കറ്റ്, ബ്രൗസർ കോഡ് — അത് വിട്ടുവീഴ്ച ചെയ്യപ്പെട്ടതായി കണക്കാക്കുക.
- ദാതാവിൽ പുതിയ കീ ഉണ്ടാക്കുക.
- നിങ്ങളുടെ ആപ്പിന്റെ ക്രമീകരണത്തിൽ സീക്രട്ട് അപ്ഡേറ്റ് ചെയ്യുക.
- ലൈവ് ആപ്പ് പുതിയ കീ ഉപയോഗിക്കാൻ വീണ്ടും deploy അല്ലെങ്കിൽ publish ചെയ്യുക.
- ദാതാവിൽ പഴയ കീ ഡിലീറ്റ് ചെയ്യുക.
- നിങ്ങൾക്ക് പരിചയമില്ലാത്ത പ്രവർത്തനങ്ങൾക്കായി ദാതാവിന്റെ usage logs പരിശോധിക്കുക.
ചാറ്റ് സന്ദേശമോ Git commit-ഓ ഡിലീറ്റ് ചെയ്യുന്നത് മതിയാകില്ല. Git ചരിത്രത്തിൽ പഴയ പതിപ്പുകൾ ഉണ്ടാകും, പബ്ലിക് ആയ എന്തും ഇതിനകം കോപ്പി ചെയ്യപ്പെട്ടിരിക്കാം.
സാധാരണ തെറ്റുകൾ
- കീ prompt-ൽ ഒട്ടിക്കുന്നത്. അത് ഇപ്പോൾ ചാറ്റ് ചരിത്രത്തിലാണ്. പകരം secrets ഫോം ഉപയോഗിക്കുക.
- സീക്രട്ട് variable-ൽ പബ്ലിക് prefix.
VITE_OPENAI_API_KEYകീ എല്ലാ സന്ദർശകർക്കും അയക്കുന്നു. .envഫയൽ commit ചെയ്യുന്നത്. ആദ്യ push-ന് മുമ്പ് അത്.gitignore-ൽ ഉണ്ടെന്ന് ഉറപ്പാക്കുക.- എല്ലായിടത്തും ഒരേ കീ. ടെസ്റ്റിനും ലൈവിനും ഓരോ ആപ്പിനും പ്രത്യേക കീകൾ ഉപയോഗിക്കുക.
- ചെലവ് പരിധി ഇല്ലാത്തത്. ചോർന്നതോ ദുരുപയോഗം ചെയ്യപ്പെട്ടതോ ആയ ഒരു പരിധിയില്ലാത്ത കീ നിങ്ങൾ ശ്രദ്ധിക്കും മുമ്പ് വലിയ ബിൽ ഉണ്ടാക്കാം.
- മറയ്ക്കുന്നത്, മാറ്റാതെ. ഒരിക്കൽ കീ പുറത്തായാൽ, പുതിയ കീ മാത്രമേ അത് പരിഹരിക്കൂ.
- സ്ക്രീൻഷോട്ടുകളിൽ കീകൾ. സഹായം ചോദിക്കും മുമ്പ് ക്രമീകരണ പേജുകൾ crop ചെയ്യുകയോ blur ചെയ്യുകയോ ചെയ്യുക.
ചെക്ക്ലിസ്റ്റ്
- ഓരോ കീയും കോഡിന് പുറത്ത് secret അല്ലെങ്കിൽ environment variable ആയി സൂക്ഷിച്ചിരിക്കുന്നു.
- ഒരു
.envഫയലോ കീയോ Git-ലേക്ക് commit ചെയ്തിട്ടില്ല. - സീക്രട്ട് കീകൾ സെർവർ-സൈഡ് കോഡിൽ മാത്രം ഉപയോഗിക്കുന്നു.
-
VITE_അല്ലെങ്കിൽNEXT_PUBLIC_പോലുള്ള പബ്ലിക് prefix ഒരു സീക്രട്ട് variable-നും ഇല്ല. - ഓരോ കീയുടെ prefix-നും ലൈവ് സൈറ്റിന്റെ JavaScript-ൽ തിരഞ്ഞു, ഒന്നും കണ്ടില്ല.
- ദാതാവ് അനുവദിക്കുന്നിടത്ത് കീകൾ പരിമിതപ്പെടുത്തിയിരിക്കുന്നു.
- ടെസ്റ്റ് കീകളും ലൈവ് കീകളും വേറെയാണ്.
- പണമടച്ചുള്ള ഫീച്ചറുകൾക്ക് ലോഗിൻ വേണം, ഉപയോക്താവിന് ഒരു പരിധിയുമുണ്ട്.
- ഓരോ പണമടച്ചുള്ള ദാതാവിനും ചെലവ് പരിധിയോ അലേർട്ടോ ഉണ്ട്.
- ഓരോ കീയും എങ്ങനെ മാറ്റണമെന്ന് എനിക്കറിയാം, ഒരിക്കൽ പുറത്തായ കീകളെല്ലാം മാറ്റിയിട്ടുണ്ട്.
Mythex-ൽ കീകൾ സുരക്ഷിതമാക്കുന്നത്
Mythex കീകളെ നിങ്ങളുടെ കോഡിൽ നിന്നും ചാറ്റിൽ നിന്നും രണ്ട് വഴികളിലൂടെ അകറ്റി നിർത്തുന്നു:
- Secrets request card. ഏജന്റിന് ഒരു കീ വേണ്ടിവരുമ്പോൾ ചാറ്റിൽ ഒരു കാർഡ് കാണിക്കും. അവിടെ നിങ്ങൾ മൂല്യം ഫോം ഫീൽഡുകളിൽ നൽകുന്നു, മെസേജ് ബോക്സിൽ അല്ല, അത് ഒരു പ്രോജക്റ്റ് secret ആയി സൂക്ഷിക്കുന്നു. ചാറ്റിലെ Secrets കാണുക.
- Project settings → Secrets, അല്ലെങ്കിൽ ചാറ്റിൽ
/secrets, കീകൾ സ്വയം ചേർക്കാനോ മാറ്റാനോ. Environment variables and secrets കാണുക.
പബ്ലിഷ് ചെയ്ത ആപ്പിന്റെ secret മാറ്റിയ ശേഷം, ലൈവ് ആപ്പ് അത് എടുക്കാൻ വീണ്ടും publish ചെയ്യുക. Export ചെയ്ത പ്രോജക്റ്റുകളിൽ secrets ഉണ്ടാകില്ല, അതിനാൽ കോഡ് എവിടെ പ്രവർത്തിപ്പിച്ചാലും അവ വീണ്ടും ചേർക്കുക. ഒരു കീ ഒരിക്കൽ ചാറ്റിൽ വന്നാൽ ദാതാവിൽ അത് മാറ്റുക.
ലോഞ്ചിന് മുമ്പുള്ള സുരക്ഷാ പരിശോധനയുടെ ബാക്കി ഭാഗത്തിന്, AI-നിർമ്മിത ആപ്പുകൾക്കുള്ള സുരക്ഷാ ചെക്ക്ലിസ്റ്റ് പിന്തുടരുക. AI ഫീച്ചറുകൾ ചേർക്കുന്നുണ്ടെങ്കിൽ, LLM APIs എങ്ങനെ ഉപയോഗിക്കാം കീകളെയും ചെലവുകളെയും കുറിച്ച് കൂടുതൽ വിശദമായി പറയുന്നു.
ചോദ്യങ്ങൾ
ഫ്രണ്ടെൻഡ് കോഡിൽ API കീ ഇടുന്നത് സുരക്ഷിതമാണോ?
ആ കീ പബ്ലിക് ആയിരിക്കാൻ ദാതാവ് രൂപകൽപ്പന ചെയ്തതാണെങ്കിൽ മാത്രം. ഉദാഹരണത്തിന് Stripe-ന്റെ publishable key, അല്ലെങ്കിൽ നിങ്ങളുടെ ഡൊമെയ്നിൽ മാത്രം പരിമിതപ്പെടുത്തിയ maps key. പണം ചെലവാക്കാനോ സ്വകാര്യ ഡാറ്റ വായിക്കാനോ കഴിയുന്ന ഏതൊരു കീയും സെർവറിൽ തന്നെ നിൽക്കണം, കാരണം ബ്രൗസറിലേക്ക് അയക്കുന്നതെന്തും ആർക്കും വായിക്കാം.
API കീ ചാറ്റിലോ പബ്ലിക് റിപ്പോസിറ്ററിയിലോ ഒട്ടിച്ചുപോയാൽ എന്തുചെയ്യണം?
കീ മാറ്റുക: ദാതാവിൽ പുതിയ കീ ഉണ്ടാക്കുക, നിങ്ങളുടെ ആപ്പിന്റെ secrets അപ്ഡേറ്റ് ചെയ്യുക, വീണ്ടും publish ചെയ്യുക, തുടർന്ന് പഴയ കീ ഡിലീറ്റ് ചെയ്യുക. സന്ദേശമോ commit-ഓ ഡിലീറ്റ് ചെയ്താൽ മാത്രം പോരാ, കോപ്പികൾ ഇതിനകം ഉണ്ടാകാം.
API കീകൾ എവിടെയാണ് സൂക്ഷിക്കേണ്ടത്?
നിങ്ങളുടെ ഹോസ്റ്റിന്റെ environment variables അല്ലെങ്കിൽ secrets ക്രമീകരണത്തിൽ. റൺടൈമിൽ സെർവർ-സൈഡ് കോഡ് അവ വായിക്കണം. സോഴ്സ് ഫയലുകളിലോ Git-ലേക്ക് commit ചെയ്ത ഫയലുകളിലോ സ്ക്രീൻഷോട്ടുകളിലോ അവ എഴുതരുത്.
എന്റെ വെബ്സൈറ്റിൽ API കീ ചോർന്നിട്ടുണ്ടോ എന്ന് എങ്ങനെ അറിയാം?
നിങ്ങളുടെ ലൈവ് സൈറ്റ് തുറക്കുക, ബ്രൗസറിന്റെ developer tools-ൽ പേജ് സോഴ്സും JavaScript ഫയലുകളും നോക്കുക, കീയുടെ ആദ്യ ഭാഗം തിരയുക. അത് കണ്ടാൽ അത് ചോർന്നിട്ടുണ്ട്; സെർവറിലേക്ക് മാറ്റി കീ മാറ്റണം.