SaaS CSRF prevention: state-changing requests को सुरक्षित करें
Framework CSRF tokens, origin checks, safe HTTP methods, cookie settings और जाँची गई integration exceptions से SaaS apps में cross-site request forgery रोकें।
इस मार्गदर्शिका में
CSRF क्या है और किन SaaS requests को सुरक्षा चाहिए?
Cross-site request forgery (CSRF) में किसी व्यक्ति का signed-in browser, service पर उसकी अनुमति के बिना request भेजने के लिए फुसलाया जाता है। Service अक्सर session cookie जैसे credentials अपने-आप भेजे जाने पर भरोसा करती है। हर state-changing action को server-verified anti-CSRF control से सुरक्षित करें। Framework की built-in सुरक्षा से शुरू करें, read-only navigation के लिए safe methods रखें और केवल CORS या cookie के SameSite setting को पूरी सुरक्षा न मानें।
Cookie-authenticated actions के लिए framework का CSRF बचाव लें
Supported middleware चालू करें और state बदलने वाले forms या approved request header में उसका token भेजें। Server को token को current session या दूसरी सुरक्षित binding से मिलाकर validate करना चाहिए और missing या invalid value अस्वीकार करनी चाहिए। Framework में उपलब्ध तरीका जाँचे बिना custom token व्यवस्था न बनाएँ।
GET और अन्य safe methods से बदलाव न करें
Link, image या browser navigation बिना user के इरादे के GET करा सकता है। Password बदलने, record update करने, API credentials बनाने, payment approve करने या user logout करने के लिए GET न लें। State change को ऐसे method और handler से करें जिस पर CSRF protection लगी हो।
पहचानें कि browser credentials अपने-आप कहाँ भेजता है
जब browser cookie या अन्य ambient credentials अपने-आप भेजता है तब CSRF का जोखिम सबसे ज्यादा होता है। Session cookies, cross-origin form posts, account settings, billing actions और administrative flows देखें। JavaScript API यदि bearer token स्पष्ट रूप से जोड़ती है तो उसका CSRF profile अलग है, लेकिन token storage, XSS और authorization की समीक्षा फिर भी जरूरी है।
| Action / route | Credential अपने-आप भेजता है? | Method और token control | जानबूझकर cross-origin flow | Test और owner |
|---|---|---|---|---|
| Recovery email बदलना | ||||
| API token बनाना या revoke करना | ||||
| Billing या administrator बदलाव |
SaaS product tokens, origins और cookies को कैसे संभाले?
Unpredictable token बनाएँ और server पर verify करें
User session से जुड़ा framework-generated token या signed और session-bound तरीका अपनाएँ। इसे URL, analytics और logs से बाहर रखें तथा state-changing request में token absent या invalid हो तो reject करें। Browser से लौटे token को उसकी binding जाँचे बिना trusted न मानें।
SameSite और origin checks को अतिरिक्त संकेत मानें
Sign-in और integration flow के अनुसार स्पष्ट SameSite policy लगाएँ और संवेदनशील browser requests पर `Origin` या `Referer` validate करने पर विचार करें। Cookie authentication में ये जाँच framework token strategy को मजबूत करें, उसका विकल्प न बनें। लागू करने से पहले वैध redirects और supported browsers test करें।
Cross-origin exceptions का दायरा सीमित और दर्ज रखें
Webhook receiver, embedded app या स्पष्ट cross-origin API को अलग controls चाहिए हो सकते हैं। केवल जरूरी exact route को exempt करें और उसके intended authentication, request validation, CORS policy तथा logging से सुरक्षा दें। एक integration चलाने के लिए middleware को पूरी app पर disable न करें।
SaaS application में CSRF सुरक्षा verify कैसे करें?
हर high-impact बदलाव test करें
अनुमति वाले test accounts से देखें कि token के बिना, गलत token या अनपेक्षित origin से आई request अस्वीकार होती है। Account recovery, role changes, credential rotation, billing, exports और tenant administration शामिल करें। Confirm करें कि reject हुई request ने बदलाव का कोई हिस्सा लागू नहीं किया।
Cross-origin सुरक्षा browser behavior के साथ test करें
Cookie SameSite settings, origin validation, CORS configuration और intended integration paths को साथ में जाँचें। CORS यह नियंत्रित करती है कि browser code दूसरे origin का response पढ़ सके या नहीं; वह हर cross-site request को भेजे जाने से नहीं रोकती। छिपा हुआ form response न पढ़ पाने पर भी कुछ requests भेज सकता है।
XSS और service workers का असर भी देखें
XSS flaw अक्सर CSRF tokens को bypass कर सकती है क्योंकि injected code trusted site के origin में चलकर page token पढ़ या request भेज सकता है। Scripts, service workers और browser extensions को threat model में देखें और XSS अलग से ठीक करें। CSRF controls authentication या object-level authorization की जगह नहीं।
SaaS CSRF prevention के सवाल
क्या CORS CSRF रोकती है?
नहीं। CORS मुख्य रूप से रोकती है कि दूसरे origin का browser code response पढ़े। यह हर simple form submission या cookies के साथ जा सकने वाली request नहीं रोकती। Cookie-authenticated state changes पर server-side CSRF सुरक्षा लें।
क्या हर endpoint को बचाने के लिए SameSite पर्याप्त है?
नहीं। SameSite उपयोगी defense-in-depth है, लेकिन product flows, browser behavior और cross-origin उपयोग अलग होते हैं। Cookie-authenticated actions के लिए framework CSRF protection लें और पूरी workflow test करें।
क्या bearer-token APIs को CSRF tokens चाहिए?
यह इस बात पर निर्भर है कि browser credential कैसे पाता और भेजता है। Same-origin application code से स्पष्ट रूप से जोड़ा token cookie की तरह अपने-आप नहीं जाता; लेकिन cookie या browser की अन्य ambient authentication में रखा credential CSRF जोखिम लौटा सकता है। असली client और storage design जाँचें।
क्या webhook को CSRF जाँच से exempt कर सकते हैं?
Machine-to-machine webhook अपनी signature या authentication scheme इस्तेमाल कर सकती है। केवल वही route exempt करें, provider के documented तरीके से message verify करें और replay तथा authorization behavior test करें; पूरी application की CSRF सुरक्षा न हटाएँ।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .