SaaS third-party API consumption security guide
Third-party API responses validate करें, credentials व retries सीमित रखें और upstream failures को बाकी services तक फैलने से रोकें।
इस मार्गदर्शिका में
SaaS app को third-party API सुरक्षित रूप से कैसे consume करनी चाहिए?
किसी vendor से जुड़ाव होने से उसका हर response सुरक्षित नहीं हो जाता। Provider की identity और transport verify करें, integration credential को न्यूनतम access दें, response को अपेक्षित schema से parse करें और किसी दूसरी query, page या workflow में उपयोग से पहले returned values को untrusted data मानें। Timeout, retry और response size सीमित रखें ताकि provider outage या compromised integration आपकी service में न फैल जाए।
Endpoint, TLS identity और outbound destination verify करें
Customer या response body से आया destination उपयोग करने के बजाय configured provider endpoint रखें। TLS certificate और hostname जाँचें, जहाँ architecture अनुमति दे वहाँ egress सीमित करें और redirects की स्पष्ट policy रखें। यह API-consumption review SSRF सुरक्षा का पूरक है; trusted hostname भी response content को सुरक्षित नहीं बनाता।
Upstream response पर भरोसा करने से पहले validate करें
Content type, आकार, schema, जरूरी fields, type, range और business meaning जाँचें। Unexpected properties तथा malformed responses को reject या सुरक्षित संभालें। Value बाद में दिखे तो सही context में encode करें और database में जाए तो parameterized query इस्तेमाल करें। Vendor compromised या misconfigured हो सकता है अथवा expected data की जगह error page दे सकता है।
सीमित credential उपयोग करें और integration data सुरक्षित रखें
हर integration को अलग credential दें, जिसमें केवल जरूरी scopes और tenant data की अनुमति हो। Secret को approved secret manager में रखें, documented प्रक्रिया से rotate करें और token या पूरा sensitive request log न करें। साझा data, business purpose, provider owner तथा provider या credential compromise होने पर response दर्ज करें।
| Provider और endpoint | Credential और साझा data | Response schema और validation | Timeout, retry और size limits | Owner, failure mode और test |
|---|---|---|---|---|
| Identity या account provider | ||||
| Billing या payment service | ||||
| Analytics या enrichment API |
Upstream failure को दूसरी services में फैलने से कैसे रोकें?
Timeout, retry और concurrency की सीमा तय करें
Connection व response deadline तय करें, attempts सीमित रखें, jitter के साथ backoff करें और non-idempotent action retry न करें जब तक provider सुरक्षित idempotency न देता हो। Concurrent requests सीमित करें तथा बार-बार failure पर worker exhaustion रोकने के लिए circuit breaker या fallback रखें। Client, queue और proxy retry व्यवहार मिलाएँ ताकि retry storm न हो।
Provider अनुपलब्ध होने पर सुरक्षित और उपयोगी व्यवहार रखें
तय करें कौन-सा feature fail closed होगा, पुराना non-sensitive data देगा, काम queue करेगा या साफ temporary error दिखाएगा। Provider ने पुष्टि न की हो तो payment, identity verification या security decision को सफल न बताएं। Customer error में internal URL, raw provider trace या secret वाली response details न रखें।
Imported values के साथ data provenance और authorization रखें
महत्वपूर्ण value किस provider से और कब मिली, यह दर्ज करें। Imported record दिखाने से पहले अपने tenant और property authorization फिर लागू करें। Webhook, delayed callback और polled API result अलग trust path हैं; हर एक की उपयुक्त signature या identity verification जाँचें।
Team third-party API integrations को कैसे test करे?
Malformed, oversized और संदिग्ध response के लिए mocks चलाएँ
Missing field, unexpected type, extreme value, invalid encoding, HTML या script-जैसा text, redirect और documented सीमा से बड़ा response test करें। पक्का करें कि data template, database query, shell tool या customer workflow तक पहुँचने से पहले reject या सुरक्षित संभाला जाए।
Timeout, throttling, retry और duplicate delivery चलाकर देखें
Provider timeout, 429 तथा 5xx response, slow stream, रुक-रुककर सफलता और duplicate callback simulate करें। Retry सीमा, queue growth, idempotency और customer status सही होने चाहिए। Provider की अपनी rate limit unbounded retry loop या आपके quota पर दबाव न बनाए।
Provider या data flow बदलने पर integration दोबारा जाँचें
Provider API version, scopes, domains, response schema, data retention और sub-processors में बदलाव review करें। Owner और inventory record रखें, failure mode test करें और incident में credential या integration बंद करना जानें।
Third-party API सुरक्षा के सवाल
क्या known vendor से आया response भरोसेमंद है?
अपने-आप नहीं। Transport और provider identity verify करें, फिर उपयोग से पहले हर response validate करें। Vendor malformed data लौटा सकता है, compromise हो सकता है या व्यवहार बदल सकता है।
क्या TLS validation upstream response को सुरक्षित बनाता है?
नहीं। TLS connection बचाने और server पहचानने में मदद करता है। यह साबित नहीं करता कि हर value सही, authorized या दिखाने व store करने के लिए सुरक्षित है।
क्या हर failed provider call retry करना चाहिए?
नहीं। Timeout, bounded retry और backoff रखें; non-idempotent action तभी retry करें जब provider safe deduplication देता हो। Unbounded retry outage को बढ़ा सकती है।
क्या third-party API validation और SSRF prevention एक ही हैं?
नहीं। SSRF control करता है कि service कहाँ connect कर सकती है। Unsafe API consumption external service से authentication, उसकी response validation और data के सुरक्षित उपयोग को देखता है। Product को दोनों चाहिए हो सकते हैं।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .
- OWASP API Security Top 10: API10:2023 Unsafe Consumption of APIs
- OWASP Transport Layer Security Cheat Sheet
- OWASP Server-Side Request Forgery Prevention Cheat Sheet
- OWASP API Security Top 10: API3:2023 Broken Object Property Level Authorization
- OWASP Cheat Sheet: secrets management
- OWASP Web Service Security Cheat Sheet
- OWASP API Security Top 10: API9:2023 Improper Inventory Management