SaaS teams के लिए GraphQL API security checklist
Resolver-level authorization, query-cost limits, validation, सुरक्षित errors, batching controls और अलग-अलग roles पर repeatable tests से SaaS GraphQL API सुरक्षित करें।
इस मार्गदर्शिका में
GraphQL API को सुरक्षित कैसे करें?
GraphQL को भी REST API की तरह server-side authentication और object-level authorization चाहिए। साथ ही लचीली queries महँगी हो सकती हैं, इसलिए हर object और mutation पर resolver या domain सीमा में permission जाँचें, input validate करें, query cost और batching सीमित करें, और ऐसे errors दें जो उपयोगी हों लेकिन implementation न खोलें। Schema छिपाना अपने-आप में सुरक्षा-सीमा नहीं है।
Caller जिन objects, fields और mutations तक पहुँच सकता है, हर जगह authorization करें
Authentication बताता है कि request किसने की; इससे हर node, edge, nested field या tenant record देखने की अनुमति साबित नहीं होती। Server-side resolver या domain logic में ownership, tenant, role और sharing नियम लागू करें। List, search, connection, nested-object और mutation paths जाँचें; सुरक्षित top-level resolver के नीचे भी unauthorized child record दिख सकता है।
महँगी service तक पहुँचने से पहले query का काम सीमित करें
केवल depth हर लागत नहीं बताती: aliases, repeated fields, nested relations, batching और resolver fan-out database या network काम कई गुना कर सकते हैं। Schema, pagination और expected traffic के अनुरूप limits तय करें; जरूरत के अनुसार per-user या per-tenant rate limit और timeout जोड़ें। सामान्य query shapes मापने के बाद limit लागू करें ताकि सुरक्षा के नाम पर ग्राहक का सही काम न टूटे।
Input validate करें और implementation details न खोलें
Variables और nested input objects पर उपयोग से पहले length, type, range और business-rule validation करें। Client को stack trace, database error, secret, internal service name या गैरज़रूरी debug विवरण न दें। जरूरत न हो तो public production endpoint पर introspection और GraphiQL बंद या सीमित करने पर विचार करें, पर data सुरक्षा का एकमात्र उपाय schema छिपाना नहीं है।
| Operation या resolver | Identity और tenant context | Object/field permission | Cost, depth या batch limit | अनुमत और अस्वीकृत test |
|---|---|---|---|---|
| Query: customer records | ||||
| Nested node या edge | ||||
| Mutation: role या billing बदलाव |
API में कौन-से GraphQL controls पूरे lifecycle पर लागू होते हैं?
केवल route entry नहीं, node और edge पर भी permission लागू करें
एक GraphQL endpoint ऐसी अनेक object types दिखा सकता है जो route-by-route review में छूट जाती हैं। Object या domain सीमा पर reusable policy रखें और उसे collection edges तथा individual nodes दोनों पर लागू करें। Authorization server-side रखें और caller identity या tenant context न होने पर access रोकें।
Pagination और batching का अनुमानित व्यवहार तय करें
Page size सीमित करें और बिना सीमा की collection query अस्वीकार करें। एक HTTP request में operations की संख्या सीमित करें और aliases या repeated mutations की लागत व transaction असर देखें। Tenant-aware quota से एक ग्राहक को shared capacity पर हावी होने से रोकें और API clients के लिए limit तथा retry व्यवहार साफ रखें।
Schema और developer tooling की उपलब्धता को सोचकर तय करें
Development में schema exploration integration आसान कर सकता है। Production में introspection, playground और verbose suggestions तभी खोलें जब documented जरूरत और access policy हो। इन्हें बंद करना सहज discovery घटा सकता है, लेकिन ज्ञात operations चलाने या authorization flaw का दुरुपयोग रोकता नहीं। API documentation और स्वीकृत client tooling उचित माध्यम से उपलब्ध रखें।
Team GraphQL security tests कैसे चलाए?
Roles, tenants और record relationships पर operation tests बनाएँ
अलग-अलग permissions वाले test tenants और accounts रखें। हर महत्वपूर्ण type पर allowed और denied reads, nested fields, list filters, mutations, bulk व्यवहार और shared records जाँचें। Response data के साथ side effect भी देखें; अगर निषिद्ध mutation पहले ही commit हो गई तो error response पर्याप्त नहीं है।
वास्तविक और चुनौतीपूर्ण query shapes से resource limits मापें
Controlled environment में गहरी nesting, aliases, repeated fields, batches, बड़े variables और धीमी downstream dependencies जाँचें। पक्का करें कि limits service बचाती हैं और documented normal operations भी चलते हैं। Rate limit response का व्यवहार समान रखें और logs में अनावश्यक sensitive payload रखने से बचें।
Schema और resolver बदलाव में security checks बनाए रखें
नया field, relation या mutation जुड़ने पर authorization दोबारा review करें। बदली हुई permission boundary और resource budget पर regression test जोड़ें। Production errors और capacity signals देखें, तथा API बढ़ने पर schema exposure और third-party integrations फिर जाँचें।
GraphQL SaaS सुरक्षा के सवाल
क्या production में introspection बंद करने से GraphQL सुरक्षित हो जाता है?
नहीं। इससे जरूरत न होने पर schema खोजना कठिन हो सकता है, लेकिन caller ज्ञात operations भेज सकता है। वास्तविक सुरक्षा authorization, input validation और resource limits से आती है।
क्या endpoint पर एक authorization check हर field सुरक्षित कर देता है?
आम तौर पर नहीं। एक endpoint कई object types और nested paths देता है। जिस data या operation तक पहुँच हो रही है, वहाँ permission लागू करें—edges, nodes, lists और mutations सहित।
क्या query depth limit GraphQL denial of service रोकती है?
यह एक प्रकार की query को सीमित करती है, लेकिन हर महँगे resolver, alias, batch या downstream call की लागत नहीं मापती। मापी हुई cost limits, pagination, timeouts और tenant-aware rate controls साथ रखें।
क्या debugging के लिए GraphQL errors में stack trace देना चाहिए?
विस्तृत जानकारी access-controlled server logs में रखें। Client को स्थिर error दें जिसमें stack trace, secret वाली query या internal infrastructure की जानकारी न निकले।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .