अपने ऐप में API keys कैसे सुरक्षित रखें

API keys को सुरक्षित रखने के लिए, उन्हें अपने होस्ट पर सीक्रेट या environment variables के रूप में रखें, केवल सर्वर-साइड कोड में इस्तेमाल करें, और उन्हें कभी चैट, कोड फ़ाइलों, स्क्रीनशॉट या Git repository में न चिपकाएं। हर key को केवल उतनी अनुमति दें जितनी उसे चाहिए, प्रोवाइडर पर खर्च की सीमा तय करें, और अगर कोई key कभी लीक हो जाए, तो उसे बदलें — नई बनाएं और पुरानी हटाएं — सिर्फ़ यह छुपाकर नहीं कि वह कहाँ दिखी थी।

API key किसी सेवा के लिए पासवर्ड है। आपकी OpenAI key किसी को आपके पैसे से AI खरीदने देती है; आपकी Stripe सीक्रेट key किसी को रिफ़ंड जारी करने देती है; आपकी ईमेल प्रोवाइडर key किसी को आपके नाम से मेल भेजने देती है। AI ऐप बिल्डर इन्हें जोड़ने में अच्छे हैं, पर हमेशा यह ध्यान नहीं रखते कि ये कहाँ पहुँचती हैं, इसलिए यह गाइड बताती है कि इन्हें सुरक्षित कैसे रखें और जाँचें कैसे।

सार्वजनिक keys बनाम सीक्रेट keys

हर key सीक्रेट नहीं होती। फ़र्क जानने से आप गलत key पर घबराते नहीं और सही key को नज़रअंदाज़ नहीं करते।

प्रकार	उदाहरण	क्या यह ब्राउज़र में हो सकती है?
Publishable / सार्वजनिक keys	Stripe `pk_…` key, आपके डोमेन तक सीमित maps key, कुछ analytics IDs	हाँ — इसी के लिए बनी हैं
सीक्रेट keys	Stripe `sk_…`, OpenAI और Anthropic keys, ईमेल प्रोवाइडर keys, डेटाबेस पासवर्ड	कभी नहीं
Service/admin keys	ऐसी keys जो होस्ट किए गए डेटाबेस के एक्सेस नियमों को बायपास करती हैं	कभी नहीं — इन्हें सबसे संवेदनशील मानें

अगर पक्का नहीं कि कौन-सी key किस प्रकार की है, तो प्रोवाइडर का दस्तावेज़ देखें। शक हो तो उसे सीक्रेट मानें।

चरण 1: keys को कोड में नहीं, सीक्रेट के रूप में रखें

Keys आपके होस्ट की environment variables या secrets सेटिंग्स में रहनी चाहिए। आपका कोड उन्हें रन टाइम पर नाम से पढ़ता है (जैसे process.env.OPENAI_API_KEY), इसलिए वैल्यू कभी आपकी फ़ाइलों में नहीं दिखती। पृष्ठभूमि के लिए देखें environment variables और secrets क्या हैं।

कोड से हर API key बाहर निकालकर environment variables में डालें। हर key की सूची दें जो आपको मिली, किस फ़ाइल में थी, और आपने कौन-सा variable नाम रखा। मुझे वैल्यू न दिखाएं।

फिर जाँचें कि कुछ बचा तो नहीं:

पूरे प्रोजेक्ट में, कॉन्फ़िग फ़ाइलों और किसी भी .env फ़ाइल सहित, खोजें कि कुछ API key या पासवर्ड जैसा दिखता है या नहीं। फ़ाइल और लाइन बताएं, वैल्यू नहीं।

चरण 2: सीक्रेट keys केवल सर्वर पर इस्तेमाल करें

यह सबसे ज़रूरी नियम है। ब्राउज़र को जो भी मिलता है, विज़िटर उसे पढ़ सकता है — पेज सोर्स और JavaScript फ़ाइलें developer tools में दिखती हैं।

इसलिए अगर ऐप को OpenAI को कॉल करना है, तो ब्राउज़र आपके सर्वर को कॉल करे, और आपका सर्वर key के साथ OpenAI को कॉल करे। key कभी सर्वर से बाहर नहीं जाती।

चैट फ़ीचर सीधे ब्राउज़र से OpenAI को कॉल करता है। उस कॉल को एक सर्वर API रूट पर ले जाएं जो environment से OPENAI_API_KEY पढ़ता है। ब्राउज़र केवल हमारे रूट को कॉल करे। रूट के लिए लॉग इन ज़रूरी करें।

फ़्रंटएंड फ़्रेमवर्क में एक आम जाल पर ध्यान दें: VITE_ (Vite में) या NEXT_PUBLIC_ (Next.js में) जैसे सार्वजनिक prefix वाले variables जानबूझकर ब्राउज़र कोड में बनाए जाते हैं। सीक्रेट key पर ऐसा prefix हो, तो वह उजागर हो जाती है, भले ही वह "environment variable" में हो।

चरण 3: जाँचें कि कुछ लीक नहीं हो रहा

यह मानकर न चलें कि सब ठीक हुआ — लाइव साइट पर जाँचें:

ब्राउज़र में प्रकाशित ऐप खोलें।
Developer tools खोलें, फिर Sources या Network टैब।
हर फ़ाइल में हर सीक्रेट key की पहली कुछ अक्षरों को खोजें (जैसे sk_ या sk-)।
ऐप के नेटवर्क अनुरोध देखें। अगर कोई अनुरोध ब्राउज़र से सीधे किसी पेड AI प्रोवाइडर पर जाता है, तो वह खतरे का संकेत है।

अगर कोई सीक्रेट key मिले, तो उसे सर्वर पर ले जाएं (चरण 2) और उसे बदलें (चरण 6), क्योंकि वह पहले से सार्वजनिक थी।

चरण 4: हर key क्या कर सकती है, उसे सीमित करें

कई प्रोवाइडर key को सीमित करने देते हैं:

Scoped या restricted keys जो केवल वही कर सकें जो आपके ऐप को चाहिए। उदाहरण के लिए Stripe विशेष अनुमतियों वाली restricted keys सपोर्ट करता है।
डोमेन या IP प्रतिबंध उन keys के लिए जो सार्वजनिक होनी ही हैं, जैसे maps keys।
हर ऐप और हर environment के लिए अलग keys, ताकि एक लीक सब कुछ उजागर न करे, और एक को रद्द करने से बाकी न टूटें।
बनाते समय टेस्ट keys, और लाइव keys केवल प्रकाशित ऐप में।

चरण 5: नुकसान की ऊपरी सीमा तय करें

अच्छी तरह सुरक्षित key भी आपके अपने ऐप के ज़रिए दुरुपयोग हो सकती है — जैसे कोई आपके AI फ़ीचर को हज़ारों बार स्क्रिप्ट से चलाए।

हर पेड प्रोवाइडर पर खर्च की सीमा या alerts सेट करें।
हर ऐसे फ़ीचर के लिए लॉग इन ज़रूरी करें जो प्रति कॉल पैसे खर्च करता है।
प्रति-यूज़र rate limit जोड़ें। देखें rate limiting क्या है।

/api/chat पर प्रति यूज़र प्रति घंटे 30 AI रिक्वेस्ट की सीमा जोड़ें। सीमा पूरी होने पर साफ़ संदेश लौटाएं। जो यूज़र लॉग इन नहीं हैं, उनकी रिक्वेस्ट अस्वीकार करें।

चरण 6: लीक हुई keys बदलें

अगर कोई सीक्रेट key ऐसी जगह दिख जाए जहाँ उसे नहीं होना चाहिए — चैट मैसेज, commit, स्क्रीनशॉट, सपोर्ट टिकट, ब्राउज़र कोड — तो मान लें कि वह समझौता हो चुकी है।

प्रोवाइडर पर नई key बनाएं।
अपने ऐप की सेटिंग्स में सीक्रेट अपडेट करें।
लाइव ऐप नई key इस्तेमाल करे इसके लिए दोबारा deploy या publish करें।
प्रोवाइडर पर पुरानी key हटाएं।
प्रोवाइडर के usage logs में वह गतिविधि जाँचें जो आपको पहचानी न लगे।

चैट मैसेज या Git commit मिटाना काफ़ी नहीं है। Git इतिहास पुराने वर्शन रखता है, और जो कुछ सार्वजनिक हुआ उसकी कॉपी पहले ही बन चुकी हो सकती है।

आम गलतियाँ

prompt में key चिपकाना। अब वह चैट इतिहास में है। इसके बजाय सीक्रेट फ़ॉर्म इस्तेमाल करें।
सीक्रेट variable पर सार्वजनिक prefix। VITE_OPENAI_API_KEY key को हर विज़िटर तक भेज देता है।
.env फ़ाइल commit करना। पहले push से पहले पक्का करें कि वह .gitignore में है।
हर जगह एक ही key। टेस्ट और लाइव के लिए, और हर ऐप के लिए अलग keys इस्तेमाल करें।
कोई खर्च सीमा नहीं। लीक हुई या दुरुपयोग हो रही बिना सीमा वाली key आपके ध्यान में आने से पहले बड़ा बिल बना सकती है।
छुपाने के बजाय बदलना नहीं। एक बार key उजागर हो जाए, तो केवल नई key ही उसे ठीक करती है।
स्क्रीनशॉट में keys। मदद माँगने से पहले सेटिंग्स पेज को क्रॉप या ब्लर करें।

चेकलिस्ट

हर key environment variable या सीक्रेट के रूप में सेव है, कोड में नहीं।
कोई .env फ़ाइल या key Git में commit नहीं है।
सीक्रेट keys केवल सर्वर-साइड कोड में इस्तेमाल होती हैं।
किसी सीक्रेट variable पर VITE_ या NEXT_PUBLIC_ जैसा सार्वजनिक prefix नहीं है।
मैंने लाइव साइट के JavaScript में हर key का prefix खोजा और कुछ नहीं मिला।
जहाँ प्रोवाइडर अनुमति देता है, keys सीमित (scoped या restricted) हैं।
टेस्ट और लाइव keys अलग हैं।
पैसे लगाने वाले फ़ीचर के लिए लॉग इन और प्रति-यूज़र सीमा है।
हर पेड प्रोवाइडर पर खर्च सीमा या alert है।
मुझे पता है हर key कैसे बदलनी है, और जो key कभी उजागर हुई थी उसे बदला जा चुका है।

Mythex पर keys सुरक्षित रखना

Mythex दो तरीकों से keys को आपके कोड और चैट से बाहर रखता है:

Secrets request कार्ड। जब एजेंट को key चाहिए होती है, तो चैट में एक कार्ड दिखता है जहाँ आप मान फ़ॉर्म फ़ील्ड में डालते हैं, मैसेज बॉक्स में नहीं, और वह एक प्रोजेक्ट सीक्रेट के रूप में सेव होती है। देखें चैट में Secrets।
Project settings → Secrets, या चैट में /secrets, ताकि आप खुद keys जोड़ या बदल सकें। देखें Environment variables और secrets।

प्रकाशित ऐप के लिए सीक्रेट बदलने के बाद उसे फिर से पब्लिश करें, ताकि लाइव ऐप नई वैल्यू उठा सके। एक्सपोर्ट किए गए प्रोजेक्ट में सीक्रेट शामिल नहीं होते, इसलिए जहाँ भी कोड अगली बार चलाएं वहाँ उन्हें फिर से जोड़ें। अगर कोई key कभी चैट में दिखे, तो प्रोवाइडर पर उसे बदलें।

लॉन्च से पहले की बाकी सुरक्षा जाँच के लिए AI से बने ऐप के लिए सुरक्षा चेकलिस्ट पूरी करें। अगर आप AI फ़ीचर जोड़ रहे हैं, तो LLM APIs कैसे इस्तेमाल करें keys और लागत पर और गहराई से बताता है।

सवाल

क्या frontend कोड में API key डालना सुरक्षित है?

केवल तब, जब प्रोवाइडर ने वह key सार्वजनिक रहने के लिए ही बनाई हो, जैसे Stripe की publishable key या ऐसी maps key जो आपके डोमेन तक सीमित हो। जो भी key पैसे खर्च करा सकती है या निजी डेटा पढ़ सकती है, वह सर्वर पर ही रहनी चाहिए, क्योंकि ब्राउज़र को जो भेजा जाता है उसे कोई भी पढ़ सकता है।

अगर मैंने किसी चैट या सार्वजनिक repo में API key चिपका दी, तो क्या करूँ?

उसे बदलें: प्रोवाइडर पर नई key बनाएं, अपने ऐप के सीक्रेट अपडेट करें, फिर से पब्लिश करें, और फिर पुरानी key हटाएं। सिर्फ़ मैसेज या commit मिटाना काफ़ी नहीं है, क्योंकि उसकी कॉपी पहले ही बन चुकी हो सकती है।

API keys कहाँ सेव करनी चाहिए?

अपने होस्ट की environment variables या secrets सेटिंग्स में, जिन्हें सर्वर-साइड कोड रन टाइम पर पढ़ता है। उन्हें सोर्स फ़ाइलों में न लिखें, Git में commit न करें, और स्क्रीनशॉट में शामिल न करें।

कैसे पता करूँ कि मेरी लाइव वेबसाइट पर API key लीक है?

अपनी लाइव साइट खोलें, ब्राउज़र के developer tools में पेज सोर्स और JavaScript फ़ाइलें देखें, और key की शुरुआत खोजें। अगर वह दिखती है, तो वह लीक है और उसे सर्वर पर ले जाकर बदलना चाहिए।