एपीआई सुरक्षा सर्वोत्तम अभ्यास: प्रमाणीकरण, प्राधिकरण और दर सीमित करना

एपीआई आधुनिक व्यापार प्लेटफार्मों के संयोजी ऊतक हैं। आपका ईआरपी एपीआई के माध्यम से आपके ईकॉमर्स स्टोर से संचार करता है। आपका भुगतान गेटवे एपीआई के माध्यम से लेनदेन की प्रक्रिया करता है। आपका मोबाइल ऐप एपीआई के माध्यम से डेटा प्राप्त करता है। और हमलावरों को यह पता है: गार्टनर ने भविष्यवाणी की है कि 2026 तक, एपीआई पारंपरिक वेब इंटरफेस को पार करते हुए एंटरप्राइज़ वेब अनुप्रयोगों के लिए सबसे लगातार हमला वेक्टर होगा।

ओडब्ल्यूएएसपी एपीआई सिक्योरिटी टॉप 10 से पता चलता है कि सबसे आम एपीआई कमजोरियां विदेशी शून्य-दिन नहीं हैं --- वे मौलिक प्रमाणीकरण विफलताएं, टूटा हुआ प्राधिकरण और अत्यधिक डेटा एक्सपोजर हैं। ये रोके जाने योग्य दोष हैं जो परिष्कृत हमलों के बजाय अपर्याप्त सुरक्षा वास्तुकला से उत्पन्न होते हैं।

मुख्य बातें

• PKCE के साथ OAuth2 एपीआई प्रमाणीकरण के लिए वर्तमान मानक है; अकेले एपीआई कुंजियाँ उत्पादन प्रणालियों के लिए अपर्याप्त हैं
• ब्रोकन ऑब्जेक्ट-लेवल ऑथराइजेशन (BOLA) नंबर एक एपीआई भेद्यता है --- प्रत्येक एंडपॉइंट को संसाधन स्वामित्व को सत्यापित करना होगा
• दर सीमित करना एक सुरक्षा नियंत्रण है, न कि केवल एक प्रदर्शन अनुकूलन --- यह क्रेडेंशियल स्टफिंग, गणना और DoS को रोकता है
• एपीआई सीमा पर इनपुट सत्यापन आपके डेटाबेस तक पहुंचने से पहले इंजेक्शन, अतिप्रवाह और व्यावसायिक तर्क हमलों को रोकता है

---

प्रमाणीकरण: पहचान साबित करना

प्रमाणीकरण इस प्रश्न का उत्तर देता है "यह अनुरोध कौन कर रहा है?" एपीआई के लिए, उत्तर क्रिप्टोग्राफ़िक रूप से सत्यापन योग्य, पुनरावृत्ति हमलों के लिए प्रतिरोधी और वितरित सिस्टम में स्केलेबल होना चाहिए।

प्रमाणीकरण विधि तुलना

| विधि | सुरक्षा स्तर | केस का प्रयोग करें | सीमाएँ | |-------|----------------------|---|---|| | एपीआई कुंजियाँ | निम्न | सर्वर-टू-सर्वर, आंतरिक उपकरण | डिफ़ॉल्ट रूप से कोई समाप्ति तिथि नहीं, आसानी से लीक, कोई उपयोगकर्ता संदर्भ नहीं | | बेसिक ऑथ (उपयोगकर्ता:पास) | निम्न | केवल लीगेसी सिस्टम | प्रत्येक अनुरोध के साथ क्रेडेंशियल भेजे जाते हैं, कोई टोकन समाप्ति नहीं | | जेडब्ल्यूटी बियरर टोकन | मध्यम-उच्च | उपयोगकर्ता-सामना करने वाले एपीआई, माइक्रोसर्विसेज | हस्ताक्षर, समाप्ति तिथि और जारीकर्ता को मान्य करना होगा। निरसन के लिए अतिरिक्त बुनियादी ढांचे की आवश्यकता है | | OAuth2 + OIDC | उच्च | तृतीय-पक्ष पहुंच, एसएसओ, उपयोगकर्ता-सामना | जटिल कार्यान्वयन, पहचान प्रदाता की आवश्यकता है | | म्युचुअल टीएलएस (एमटीएलएस) | बहुत ऊँचा | सेवा-से-सेवा, शून्य विश्वास | प्रमाणपत्र प्रबंधन ओवरहेड, ब्राउज़रों के लिए उपयुक्त नहीं है | | एपीआई कुंजी + एचएमएसी हस्ताक्षर | उच्च | वेबहुक, लाइसेंस सत्यापन | साझा गुप्त प्रबंधन, घड़ी सिंक्रनाइज़ेशन की आवश्यकता है |

OAuth2 और OIDC सर्वोत्तम प्रथाएँ

ओपनआईडी कनेक्ट (ओआईडीसी) के साथ OAuth2 आधुनिक अनुप्रयोगों में एपीआई प्रमाणीकरण के लिए मानक है। प्रमुख कार्यान्वयन प्रथाएँ:

पीकेसीई के साथ प्राधिकरण कोड प्रवाह का उपयोग करें एकल-पेज एप्लिकेशन और मोबाइल ऐप्स सहित सभी क्लाइंट प्रकारों के लिए। ब्राउज़र इतिहास और रेफ़रर हेडर में टोकन एक्सपोज़र के कारण अंतर्निहित प्रवाह को रोक दिया गया है।

अल्पकालिक एक्सेस टोकन। एक्सेस टोकन 15-60 मिनट में समाप्त हो जाने चाहिए। पुनः प्रमाणीकरण के बिना नए एक्सेस टोकन प्राप्त करने के लिए ताज़ा टोकन (सुरक्षित रूप से संग्रहीत, उपयोग पर घुमाए गए) का उपयोग करें।

टोकन भंडारण। टोकन को कभी भी लोकलस्टोरेज या सेशनस्टोरेज (XSS के प्रति संवेदनशील) में संग्रहित न करें। सुरक्षित और सेमसाइट विशेषताओं के साथ HttpOnly कुकीज़ का उपयोग करें। उन एसपीए के लिए जिन्हें सीधे टोकन का उपयोग करना होगा, उन्हें केवल मेमोरी में रखें और पेज रीफ्रेश पर सत्र हानि के ट्रेड-ऑफ को स्वीकार करें।

टोकन को पूरी तरह से सत्यापित करें। प्रत्येक एपीआई अनुरोध को टोकन के हस्ताक्षर, समाप्ति, जारीकर्ता, दर्शक और दायरे को सत्यापित करना होगा। केवल JWT को डिकोड न करें और इसकी सामग्री पर भरोसा न करें।

टोकन बाइंडिंग। जहां संभव हो, टोकन चोरी और रीप्ले को रोकने के लिए डीपीओपी (कब्जे का सबूत प्रदर्शित करना) हेडर का उपयोग करके अनुरोध करने वाले क्लाइंट को टोकन बाइंड करें।

जेडब्ल्यूटी सुरक्षा संबंधी विचार

जेडब्ल्यूटी एपीआई के लिए सबसे आम टोकन प्रारूप हैं, लेकिन उनमें विशिष्ट जोखिम होते हैं:

• कभी भी none एल्गोरिथम का उपयोग न करें। हमेशा अपेक्षित एल्गोरिदम की श्वेतसूची के विरुद्ध alg हेडर को मान्य करें।
• सार्वजनिक-सामना वाले एपीआई के लिए सममित (एचएस256) की तुलना में असममित एल्गोरिदम (आरएस256, ईएस256) को प्राथमिकता दें। असममित कुंजियाँ हस्ताक्षर कुंजी साझा किए बिना टोकन सत्यापन की अनुमति देती हैं।
• मानक दावे शामिल करें: iss (जारीकर्ता), aud (दर्शक), exp (समाप्ति), iat (जारी), sub (विषय), jti (निरस्तीकरण के लिए अद्वितीय आईडी)।
• पेलोड छोटा रखें। JWTs कोई डेटाबेस नहीं हैं। प्राधिकरण निर्णयों के लिए आवश्यक दावे ही शामिल करें। आवश्यकता पड़ने पर उपयोगकर्ता जानकारी समापन बिंदु से अतिरिक्त डेटा प्राप्त करें।
• टोकन निरस्तीकरण लागू करें। खातों से छेड़छाड़ होने पर तत्काल निरस्तीकरण के लिए टोकन ब्लॉकलिस्ट (रेडिस या समान में) के साथ संयुक्त रूप से संक्षिप्त समाप्ति समय का उपयोग करें।

---

प्राधिकरण: अभिगम नियंत्रण लागू करना

प्रमाणीकरण आपको बताता है कि अनुरोध कौन कर रहा है। प्राधिकरण आपको बताता है कि उन्हें क्या करने की अनुमति है। OWASP API टॉप 10 में ब्रोकन ऑब्जेक्ट-लेवल ऑथराइज़ेशन (BOLA) को नंबर एक API भेद्यता के रूप में सूचीबद्ध किया गया है क्योंकि यह सबसे आम और सबसे प्रभावशाली दोनों है।

आरबीएसी बनाम एबीएसी

भूमिका-आधारित अभिगम नियंत्रण (आरबीएसी) भूमिकाओं को अनुमतियाँ प्रदान करता है, और उपयोगकर्ताओं को भूमिकाएँ सौंपी जाती हैं। इसे लागू करना और तर्क करना आसान है।

विशेषता-आधारित अभिगम नियंत्रण (एबीएसी) उपयोगकर्ता, संसाधन, क्रिया और पर्यावरण की विशेषताओं के विरुद्ध नीतियों का मूल्यांकन करता है। यह अधिक जटिल नियमों का समर्थन करता है लेकिन ऑडिट करना कठिन है।

ईआरपी और ईकॉमर्स सिस्टम सहित अधिकांश व्यावसायिक प्लेटफार्मों के लिए, संसाधन स्वामित्व जांच के साथ संयुक्त होने पर आरबीएसी पर्याप्त है। एबीएसी पर विचार करें जब आपके प्राधिकरण नियम समय, स्थान, डेटा वर्गीकरण, या गतिशील संगठनात्मक पदानुक्रम जैसे प्रासंगिक कारकों पर निर्भर करते हैं।

बोला को रोकना

टूटा हुआ ऑब्जेक्ट-स्तर प्राधिकरण तब होता है जब एक एपीआई उपयोगकर्ताओं को संसाधन पहचानकर्ताओं में हेरफेर करके अन्य उपयोगकर्ताओं से संबंधित संसाधनों तक पहुंचने या संशोधित करने की अनुमति देता है। उदाहरण के लिए, /api/orders/12345 को /api/orders/12346 में बदलने से किसी अन्य उपयोगकर्ता का ऑर्डर प्रकट नहीं होना चाहिए।

रोकथाम के नियम:

1. प्रत्येक समापन बिंदु को संसाधन स्वामित्व को सत्यापित करना होगा। कभी भी केवल प्रमाणीकरण पर भरोसा न करें। उपयोगकर्ता की पहचान सत्यापित करने के बाद, सत्यापित करें कि उनके पास अनुरोध किए जा रहे विशिष्ट संसाधन तक पहुंच है।
2. अप्रत्यक्ष संदर्भों का उपयोग करें। अनुक्रमिक डेटाबेस आईडी को उजागर करने के बजाय, यूयूआईडी या उपयोगकर्ता-स्कोप संदर्भ संख्याओं का उपयोग करें।
3. डेटा स्तर पर लागू करें। केवल नियंत्रक स्तर पर ही नहीं, बल्कि प्रत्येक डेटाबेस क्वेरी में स्वामित्व फ़िल्टर (उदाहरण के लिए, WHERE organization_id = ?) जोड़ें। यह बहु-किरायेदारी पैटर्न है जिसका उपयोग ECOSIRE के प्लेटफ़ॉर्म आर्किटेक्चर में किया जाता है।
4. स्वचालित परीक्षण। अपने सीआई/सीडी पाइपलाइन में प्राधिकरण बाईपास परीक्षण शामिल करें। प्रत्येक समापन बिंदु के लिए, परीक्षण करें कि उपयोगकर्ता ए उपयोगकर्ता बी के संसाधनों तक नहीं पहुंच सकता है।

---

दर सीमित करना और थ्रॉटलिंग

दर सीमित करना एक सुरक्षा नियंत्रण है जो दुरुपयोग को रोकता है, न कि केवल एक प्रदर्शन अनुकूलन जो अधिभार को रोकता है। दर को सीमित किए बिना, हमलावर प्रति सेकंड हजारों प्रयासों पर क्रेडेंशियल स्टफिंग कर सकते हैं, वैध खातों की गणना कर सकते हैं, आपके संपूर्ण उत्पाद कैटलॉग को परिमार्जन कर सकते हैं, या अपस्ट्रीम प्रदाताओं के साथ आपके एपीआई कोटा को समाप्त कर सकते हैं।

दर सीमित करने की रणनीतियाँ

समापन बिंदु प्रकार द्वारा दर सीमित करना

अलग-अलग समापन बिंदु अलग-अलग खतरे की प्रोफाइल का सामना करते हैं और अलग-अलग सीमाओं की आवश्यकता होती है:

• प्रमाणीकरण समापन बिंदु (लॉगिन, टोकन एक्सचेंज): प्रति आईपी प्रति मिनट 5-10 अनुरोध। कम सीमाएँ क्रेडेंशियल स्टफिंग और क्रूर बल को रोकती हैं।
• पासवर्ड रीसेट/खाता पुनर्प्राप्ति: प्रति खाता प्रति घंटे 3-5 अनुरोध। खाता गणना और दुरुपयोग को रोकता है।
• डेटा पढ़ने के अंतिम बिंदु: प्रति उपयोगकर्ता प्रति मिनट 100-1000 अनुरोध। सामान्य उपयोग की अनुमति देते हुए स्क्रैपिंग को रोकता है।
• डेटा लेखन समापन बिंदु: प्रति उपयोगकर्ता प्रति मिनट 30-60 अनुरोध। स्वचालित दुरुपयोग और स्पैम को रोकता है.
• सार्वजनिक खोज समापन बिंदु: प्रति आईपी 20-60 अनुरोध प्रति मिनट। प्रतिस्पर्धी स्क्रैपिंग को रोकता है।
• वेबहुक रिसीवर्स: दर सीमित करने के बजाय हस्ताक्षरों को मान्य करें, लेकिन अपेक्षित मात्रा से अधिक अनुरोधों को छोड़ दें।

दर सीमा लागू करना

उचित HTTP स्थिति कोड और हेडर लौटाएँ ताकि ग्राहक स्व-विनियमन कर सकें:

• 429 बहुत अधिक अनुरोध जब सीमा पार हो जाती है
• सीमा रीसेट होने तक सेकंड की संख्या के साथ पुनःप्रयास-बाद हेडर
• X-RateLimit-Limit हेडर कुल स्वीकृत अनुरोधों को दर्शाता है
• X-RateLimit-Remaining हेडर विंडो में छोड़े गए अनुरोध दिखा रहा है
• विंडो रीसेट होने पर यूटीसी टाइमस्टैम्प के साथ X-RateLimit-Reset हेडर

हमलावरों को सीमाओं को बायपास करने के लिए विभिन्न उदाहरणों में अनुरोध वितरित करने से रोकने के लिए प्रति-आवृत्ति सीमा के बजाय एक केंद्रीकृत दर सीमित सेवा (रेडिस-समर्थित) का उपयोग करें।

---

इनपुट सत्यापन

एपीआई सीमा पर इनपुट सत्यापन इंजेक्शन हमलों, बफर ओवरफ्लो और व्यावसायिक तर्क शोषण के खिलाफ आपकी रक्षा की पहली पंक्ति है। आपके एपीआई में प्रवेश करने वाले प्रत्येक डेटा को प्रकार, प्रारूप, लंबाई, सीमा और व्यावसायिक नियमों के लिए मान्य किया जाना चाहिए।

OWASP एपीआई सुरक्षा शीर्ष 10

OWASP एपीआई सिक्योरिटी टॉप 10 (2023 संस्करण) उन महत्वपूर्ण जोखिमों की पहचान करता है जिन्हें प्रत्येक एपीआई को संबोधित करना चाहिए:

| रैंक | भेद्यता | रोकथाम | |------|-----|---|| | एपीआई1 | टूटा हुआ वस्तु-स्तर प्राधिकरण | प्रत्येक संसाधन पहुंच पर स्वामित्व की जांच | | एपीआई2 | टूटा हुआ प्रमाणीकरण | OAuth2/OIDC, MFA, सुरक्षित टोकन हैंडलिंग | | एपीआई3 | टूटी हुई वस्तु संपत्ति-स्तर प्राधिकरण | प्रतिक्रिया फ़िल्टरिंग, आंतरिक फ़ील्ड को उजागर न करें | | एपीआई4 | अप्रतिबंधित संसाधन उपभोग | दर सीमित करना, पेजिनेशन, क्वेरी जटिलता सीमाएँ | | एपीआई5 | टूटा हुआ फ़ंक्शन-स्तर प्राधिकरण | हर ऑपरेशन पर भूमिका की जांच, न कि सिर्फ पढ़ना | | एपीआई6 | संवेदनशील व्यावसायिक प्रवाह तक अप्रतिबंधित पहुंच | बॉट का पता लगाना, कैप्चा, व्यवसाय नियम प्रवर्तन | | एपीआई7 | सर्वर-साइड अनुरोध जालसाजी (एसएसआरएफ) | यूआरएल सत्यापन, अनुमति सूचियां, निजी आईपी को ब्लॉक करें | | एपीआई8 | सुरक्षा ग़लतफ़हमी | सुरक्षा शीर्षलेख, सीओआरएस नीति, त्रुटि प्रबंधन | | एपीआई9 | अनुचित इन्वेंटरी प्रबंधन | एपीआई संस्करण, बहिष्करण, दस्तावेज़ीकरण | | एपीआई10 | एपीआई का असुरक्षित उपभोग | तृतीय-पक्ष API से प्राप्त डेटा को अविश्वसनीय के रूप में मान्य करें |

सत्यापन सर्वोत्तम अभ्यास

स्कीमा सत्यापन। अनुरोध स्कीमा को परिभाषित करें (JSON स्कीमा, ज़ॉड, या ओपनएपीआई स्पेक का उपयोग करके) और किसी भी अनुरोध को अस्वीकार करें जो अनुरूप नहीं है। यह व्यावसायिक तर्क तक पहुंचने से पहले विकृत डेटा को पकड़ लेता है।

पैरामीटरयुक्त क्वेरीज़। उपयोगकर्ता इनपुट को कभी भी SQL, NoSQL, या LDAP क्वेरीज़ में संयोजित न करें। पैरामीटरयुक्त क्वेरीज़ या ORM विधियों का उपयोग करें जो स्वचालित रूप से भागने को संभालती हैं। यह सभी व्यावसायिक प्लेटफार्मों के लिए एक महत्वपूर्ण सुरक्षा नियम है।

सामग्री प्रकार प्रवर्तन। केवल अपेक्षित सामग्री-प्रकार शीर्षलेख स्वीकार करें। JSON की अपेक्षा करने वाले API को पार्सर-आधारित हमलों को रोकने के लिए XML, फॉर्म डेटा और अन्य सामग्री प्रकारों को अस्वीकार कर देना चाहिए।

प्रतिक्रिया फ़िल्टरिंग। क्लाइंट को पूर्ण डेटाबेस रिकॉर्ड कभी न लौटाएँ। प्रत्येक प्रतिक्रिया में कौन से फ़ील्ड शामिल हैं, इसे स्पष्ट रूप से परिभाषित करने के लिए डीटीओ (डेटा ट्रांसफर ऑब्जेक्ट) का उपयोग करें। पासवर्ड हैश, आंतरिक आईडी और ऑडिट मेटाडेटा जैसे आंतरिक फ़ील्ड कभी भी एपीआई प्रतिक्रियाओं में प्रकट नहीं होने चाहिए।

त्रुटि प्रबंधन। ग्राहकों को सामान्य त्रुटि संदेश लौटाएँ। स्टैक ट्रेस, डेटाबेस त्रुटियाँ, या आंतरिक सिस्टम विवरण कभी भी उजागर न करें। डिबगिंग के लिए विस्तृत त्रुटियाँ सर्वर-साइड लॉग करें।

---

एपीआई सुरक्षा वास्तुकला पैटर्न

एपीआई गेटवे पैटर्न

एक एपीआई गेटवे सभी बैकएंड सेवाओं के सामने बैठता है और क्रॉस-कटिंग सुरक्षा चिंताओं को केंद्रीकृत करता है:

• प्रमाणीकरण --- अनुरोधों के बैकएंड सेवाओं तक पहुंचने से पहले टोकन को मान्य करता है
• दर सीमित करना --- गेटवे स्तर पर सीमाएं लागू करता है
• अनुरोध/प्रतिक्रिया परिवर्तन --- संवेदनशील हेडर हटाता है, सुरक्षा हेडर जोड़ता है
• लॉगिंग और मॉनिटरिंग --- सुरक्षा विश्लेषण के लिए सभी एपीआई ट्रैफ़िक को कैप्चर करता है
• WAF एकीकरण --- ज्ञात आक्रमण पैटर्न को ब्लॉक करता है (SQL इंजेक्शन, XSS पेलोड)

लोकप्रिय एपीआई गेटवे में कोंग, एडब्ल्यूएस एपीआई गेटवे, एज़्योर एपीआई मैनेजमेंट और ट्रैफिक शामिल हैं।

सेवा-से-सेवा प्रमाणीकरण

माइक्रोसर्विसेज के बीच आंतरिक एपीआई को भी प्रमाणीकरण की आवश्यकता होती है। विकल्पों में शामिल हैं:

• म्यूचुअल टीएलएस (एमटीएलएस) --- क्लाइंट और सर्वर दोनों प्रमाणपत्र प्रस्तुत करते हैं। मजबूत लेकिन संचालनात्मक रूप से जटिल.
• सेवा टोकन --- सेवाएँ पूर्व-साझा टोकन के साथ प्रमाणित होती हैं। सरल लेकिन सुरक्षित वितरण की आवश्यकता है।
• सेवा जाल --- कुबेरनेट्स में सेवाओं के बीच इस्तियो या लिंकरड स्वचालित रूप से एमटीएलएस को संभालते हैं।
• OAuth2 क्लाइंट क्रेडेंशियल --- एक्सेस टोकन प्राप्त करने के लिए सेवाएं क्लाइंट आईडी और सीक्रेट का उपयोग करके प्रमाणित करती हैं।

शून्य विश्वास आर्किटेक्चर के लिए, उल्लंघन के बाद पार्श्विक हलचल को रोकने के लिए सेवा-से-सेवा प्रमाणीकरण आवश्यक है।

---

निगरानी और घटना का पता लगाना

एपीआई सुरक्षा निगरानी को तकनीकी संकेतों (असफल प्रमाणीकरण प्रयास, असामान्य अनुरोध पैटर्न) और व्यावसायिक संकेतों (असामान्य लेनदेन मात्रा, थोक डेटा एक्सेस) दोनों को पकड़ना चाहिए।

महत्वपूर्ण एपीआई सुरक्षा सिग्नल

• प्रमाणीकरण विफलता --- एकल आईपी से विफल लॉगिन या एकल खाते को लक्षित करने में स्पाइक
• प्राधिकरण विफलताएँ --- 403 प्रतिक्रियाएँ उपयोगकर्ताओं को अनधिकृत संसाधनों तक पहुँचने का प्रयास करने का संकेत देती हैं
• दर सीमा का उल्लंघन --- एक ही स्रोत से लगातार 429 प्रतिक्रियाएं मिलीं
• असामान्य डेटा वॉल्यूम --- बल्क रीड ऑपरेशन जो डेटा एक्सफिल्ट्रेशन का सुझाव देते हैं
• पैरामीटर छेड़छाड़ --- अनुक्रमिक आईडी गणना, नकारात्मक मान, सीमा परीक्षण
• भौगोलिक विसंगतियाँ --- अप्रत्याशित क्षेत्रों या असंभव यात्रा पैटर्न से एपीआई कॉल

ऐसे डैशबोर्ड बनाएं जो वास्तविक समय में इन संकेतों को प्रदर्शित करें। अन्य सुरक्षा घटनाओं के साथ सहसंबंध के लिए अपने सिएम के साथ एकीकृत करें। उच्च-विश्वास वाले खतरों के लिए स्वचालित प्रतिक्रियाओं को परिभाषित करें: विफल प्रमाणीकरण सीमा से अधिक आईपी को ब्लॉक करें, असंभव यात्रा प्रदर्शित करने वाले खातों को अस्थायी रूप से अक्षम करें, और थोक डेटा एक्सेस पैटर्न पर अलर्ट करें।

---

अक्सर पूछे जाने वाले प्रश्न

क्या मुझे एपीआई कुंजी या OAuth2 टोकन का उपयोग करना चाहिए?

किसी भी एपीआई के लिए OAuth2 टोकन का उपयोग करें जो उपयोगकर्ता-सामना वाले एप्लिकेशन या तृतीय-पक्ष एकीकरण प्रदान करता है। एपीआई कुंजी केवल सर्वर-टू-सर्वर संचार के लिए स्वीकार्य हैं जहां दोनों एंडपॉइंट आपके नियंत्रण में हैं, और फिर भी, एचएमएसी-हस्ताक्षरित अनुरोध मजबूत सुरक्षा प्रदान करते हैं। सार्वजनिक रूप से पहुंच योग्य समापन बिंदुओं के लिए एकमात्र प्रमाणीकरण के रूप में कभी भी एपीआई कुंजियों का उपयोग न करें।

मैं एपीआई संस्करण को सुरक्षित रूप से कैसे प्रबंधित करूं?

स्पष्टता और खोज योग्यता के लिए यूआरएल-आधारित संस्करण (उदाहरण के लिए, /api/v2/orders) का उपयोग करें। किसी संस्करण को अस्वीकृत करते समय, एक समाप्ति तिथि निर्धारित करें, इसे उपभोक्ताओं को बताएं और उपयोग की निगरानी करें। अप्रचलित संस्करणों पर सुरक्षा पैच लागू करना जारी रखें जब तक कि वे पूरी तरह से समाप्त न हो जाएं। बिना पैच वाले पुराने एपीआई संस्करणों को कभी भी चालू न छोड़ें --- वे आसान लक्ष्य बन जाते हैं।

मुझे बिजनेस एपीआई के लिए कौन सी दर सीमा निर्धारित करनी चाहिए?

रूढ़िवादी शुरुआत करें और वैध उपयोग डेटा के आधार पर वृद्धि करें। प्रमाणीकरण समापन बिंदुओं के लिए, प्रति आईपी 5-10 अनुरोध प्रति मिनट मानक है। डेटा एंडपॉइंट के लिए, प्रति प्रमाणित उपयोगकर्ता प्रति मिनट 100-500 अनुरोध अधिकांश व्यावसायिक उपयोग के मामलों को कवर करते हैं। उन सीमाओं की पहचान करने के लिए 429 प्रतिक्रियाओं की निगरानी करें जो बहुत अधिक प्रतिबंधात्मक हैं, और जो सीमाएं बहुत अधिक उदार हैं उनकी पहचान करने के लिए दुरुपयोग पैटर्न की निगरानी करें।

मैं वेबहुक को तृतीय-पक्ष सेवाओं से कैसे सुरक्षित करूँ?

साझा रहस्य के साथ HMAC-SHA256 का उपयोग करके वेबहुक हस्ताक्षर सत्यापित करें। रीप्ले हमलों को रोकने के लिए टाइमस्टैम्प को मान्य करें (5 मिनट से अधिक पुरानी घटनाओं को अस्वीकार करें)। टाइमआउट-आधारित सेवा अस्वीकृति को रोकने के लिए वेबहुक को अतुल्यकालिक रूप से संसाधित करें। ऑडिट उद्देश्यों के लिए सभी वेबहुक इवेंट लॉग करें। प्रसंस्करण से पहले पेलोड स्कीमा को सत्यापित करें।

---

आगे क्या है

एपीआई सुरक्षा वह सुविधा नहीं है जिसे आप विकास के अंत में जोड़ते हैं --- यह एक डिज़ाइन सिद्धांत है जो पहले समापन बिंदु से मौजूद होना चाहिए। मजबूत प्रमाणीकरण (OAuth2/OIDC) के साथ प्रारंभ करें, प्रत्येक संसाधन पहुंच बिंदु पर प्राधिकरण लागू करें, सभी समापन बिंदु प्रकारों पर दर सीमित लागू करें, और आपकी एपीआई सीमा को पार करने वाले प्रत्येक इनपुट को मान्य करें।

ECOSIRE प्रत्येक एपीआई एकीकरण में सुरक्षा बनाता है। हमारा ओपनक्लाव एआई प्लेटफॉर्म डिफ़ॉल्ट रूप से एचएमएसी-हस्ताक्षरित अनुरोध, दर सीमित करना और एसएसआरएफ सुरक्षा लागू करता है, जबकि हमारा ओडू ईआरपी एकीकरण भूमिका-आधारित पहुंच नियंत्रण के साथ OAuth2/OIDC का उपयोग करता है। हमारी टीम से संपर्क करें अपने बिजनेस प्लेटफॉर्म एपीआई को सुरक्षित करने के लिए।

---

ECOSIRE द्वारा प्रकाशित --- Odoo ERP, Shopify eCommerce, और OpenClaw AI में AI-संचालित समाधानों के साथ व्यवसायों को बढ़ाने में मदद करना।