Skip to content

README-hi.md

Latest commit

 

History

History
75 lines (58 loc) · 10.7 KB

README-hi.md

File metadata and controls

75 lines (58 loc) · 10.7 KB

English | 繁中版 | 简中版 | Português (Brasil) | Français | 한국어 | Nederlands | Indonesia | ไทย | Русский | Українська | Español | Italiano | 日本語 | Deutsch | Türkçe | Tiếng Việt | Монгол | العربية | Polski | Македонски | ລາວ | فارسی

API सुरक्षा जांच-सूची

अपने एपीआई को डिजाइन करने, परीक्षण करने और जारी करने के दौरान सबसे महत्वपूर्ण सुरक्षा प्रतिवाद की जांच सूची|

प्रमाणीकरण (Authentication)

  • बेसिक एथ का उपयोग मानक प्रमाणन का उपयोग न करें (जैसे JWT, OAuth)।
  • प्रमाणीकरण, टोकन पीढ़ी, पासवर्ड भंडारण में पहिया को फिर से न बदलें। मानकों का उपयोग करें।
  • लॉग इन में मैक्स पुन: प्रयास और जेल सुविधाओं का उपयोग करें।
  • सभी संवेदनशील डेटा पर एन्क्रिप्शन का उपयोग करें।

JWT (JSON वेब टोकन)

  • एक यादृच्छिक जटिल कुंजी (JWT सीक्रेट) का प्रयोग करें ताकि brute force करने के लिए टोकन बहुत कठिन हो।
  • पेलोड से एल्गोरिदम न निकालें। बैकएण्ड (HS256 या RS256) में एल्गोरिथम को बल दें।
  • टोकन की समाप्ति (टीटीएल, आरटीटीएल) को यथासंभव कम करें।
  • JWT पेलोड में संवेदनशील डेटा को संचित न करें, इसे आसानी से डिकोड किया जा सकता है।

OAuth

  • केवल व्हाइटलिस्ट किए गए URL को अनुमति देने के लिए हमेशा redirect_uri सर्वर-पक्ष को मान्य करें।
  • हमेशा कोड के लिए आदान-प्रदान करने की कोशिश नहीं करें और टोकन न दें (response_type=token की अनुमति न दें)
  • OAuth प्रमाणीकरण प्रक्रिया पर CSRF को रोकने के लिए एक यादृच्छिक हैश के साथ state पैरामीटर का उपयोग करें।
  • डिफ़ॉल्ट स्कोप को परिभाषित करें, और प्रत्येक एप्लिकेशन के लिए स्कोप मापदंडों को मान्य करें।

Access

  • DDOS / ब्रूट-फॉरेस्ट हमलों से बचने के लिए सीमा अनुरोध (थ्रोटलिंग)
  • MITM (मैन इन द मिडल अटैक) से बचने के लिए सर्वर साइड पर HTTPS का उपयोग करें।
  • SSL strip हमले से बचने के लिए SSL के साथ HSTS हैडर का उपयोग करें

Input

  • ऑपरेशन के अनुसार उचित HTTP विधि का प्रयोग करें: अनुरोधित विधि है, अगर GET (पढ़ें), पोस्ट (बनाएं), पुट / पैच (प्रतिस्थापित / अद्यतन), और हटाएं (रिकॉर्ड को हटाने के लिए), और 405 Method Not Allowed के साथ प्रतिक्रिया न दें अनुरोधित संसाधन के लिए उचित नहीं है
  • अनुरोध पर content-type मान्य करें केवल अपने समर्थित प्रारूप (जैसे application/xml, application/json, आदि) को अनुमति देने के लिए हेडर (सामग्री वार्ता-Content Negotiation) स्वीकार करें और 406 Not Acceptable करें यदि स्वीकार्य न हो तो।
  • जैसा कि आप स्वीकार करते हैं, उतनी ही पोस्ट की गई content-type की पुष्टि करें (जैसे application/x-www-form-urlencoded, multipart/form-data, application/json, इत्यादि)।
  • सामान्य कमजोरियों (जैसे XSS, SQL-Injection, Remote Code Execution, आदि) से बचने के लिए उपयोगकर्ता इनपुट मान्य करें।
  • URL में किसी भी संवेदनशील डेटा (credentials, Passwords, security tokens, या API keys) का उपयोग न करें, लेकिन मानक प्राधिकरण शीर्ष लेख का उपयोग करें।
  • कैशिंग, दर सीमा नीतियों (Quota, Spike Arrest, Concurrent Rate Limit) को सक्षम करने के लिए एपीआई गेटवे सेवा का उपयोग करें और गतिशील रूप से API संसाधनों की तैनाती करें।

Processing

  • जांचें कि क्या सभी समापन बिंदुओं को टूटा प्रमाणीकरण प्रक्रिया से बचने के लिए प्रमाणीकरण के पीछे सुरक्षित किया गया है या नहीं।
  • उपयोगकर्ता के स्वयं के संसाधन आईडी से बचना चाहिए। /user/654321/orders के बजाय /me/orders का उपयोग करें।
  • auto-increment आईडी न करें। बजाय यूयूआईडी का प्रयोग करें।
  • यदि आप XML फ़ाइलों को पार्स कर रहे हैं, तो सुनिश्चित करें कि इकाई पार्सिंग XXE (XML external entity attack) से बचने के लिए सक्षम है।
  • यदि आप XML फ़ाइलों को पार्स कर रहे हैं, तो सुनिश्चित करें कि Billion Laughs/XML bomb (exponential entity expansion attack) के हमले से बचने के लिए सक्षम है।
  • फ़ाइल अपलोड के लिए CDN का उपयोग करें।
  • यदि आप बड़ी मात्रा में डेटा के साथ काम कर रहे हैं, तो Workers और Queues का उपयोग पृष्ठभूमि में यथासंभव प्रक्रिया करने के लिए और HTTP अवरोधन(Blocking) से बचने के लिए तेज़ी से return response करें।
  • DEBUG मोड बंद करने के लिए मत भूलना।

Output

  • X-Content-Type-Options: nosniff हेडर भेजें।
  • X-Frame-Options: denyहेडर भेजें।
  • Content-Security-Policy: default-src 'none'हेडर भेजें।
  • X-Powered-By, Server, X-AspNet-Version फिंगरप्रिंटिंग हेडर हटाएं।
  • आपकी प्रतिक्रिया के लिए content-type को बल दें, यदि आप application/json वापस करते हैं तो आपकी प्रतिक्रिया content-type application/json है।
  • credentials, Passwords, security tokens जैसे संवेदनशील डेटा वापस न करें। ऑपरेशन के अनुसार उचित स्थिति कोड वापस करें। (जैसे 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, आदि)।

CI & CD

  • unit/integration परीक्षण कवरेज के साथ अपने डिजाइन और कार्यान्वयन की जांच करें।
  • कोड समीक्षा प्रक्रिया का उपयोग करें और स्वयं-स्वीकृति की उपेक्षा करें।
  • सुनिश्चित करें कि आपकी सेवाओं के सभी components को AV सॉफ्टवेयर द्वारा स्कैन करने से पहले उत्पादक को push. vendor libraries और अन्य dependencies शामिल हैं।
  • तैनाती के लिए एक रोलबैक समाधान तैयार करें।

यह भी देखें:

yosriady/api-development-tools RESTful HTTP+JSON APIs के निर्माण के लिए उपयोगी संसाधनों का संग्रह।

योगदान

इस रिपोजिटरी contribute, कुछ बदलाव करने और pull request सबमिट करने में योगदान करने के लिए स्वतंत्र महसूस करें। किसी भी प्रश्न के लिए हमें team@shieldfy.io पर एक ईमेल है।