SaaS XSS prevention: output encoding और सुरक्षित rendering मार्गदर्शिका
Context-aware output encoding, safe rendering, HTML sanitization और defense-in-depth जाँच से SaaS apps में stored, reflected और DOM-based cross-site scripting रोकें।
इस मार्गदर्शिका में
Cross-site scripting (XSS) क्या है और इससे कैसे बचें?
Cross-site scripting (XSS) तब होता है जब application browser से untrusted content को executable code की तरह चलवाती है। सबसे मजबूत सामान्य बचाव data को code से अलग रखना है: framework की auto-escaping सुविधा और जिस जगह content दिखे उसी context के output encoding का उपयोग करें। Input को business rules के अनुसार validate करें, HTML स्वीकार करने वाला feature हो तभी उसे sanitize करें, और CSP जैसी browser सुरक्षा को अतिरिक्त परत मानें, मुख्य fix नहीं।
सामान्य text के लिए framework का सुरक्षित rendering अपनाएँ
User names, comments, support content और imported values को framework के सामान्य template या component APIs से text की तरह दिखाएँ। Raw HTML डालने वाले escape hatches—जैसे React का `dangerouslySetInnerHTML`—से बचें, जब तक product को rich text सचमुच न चाहिए और content maintained library से sanitize न हो। अपने database के data को भी अपने-आप safe न मानें; वह user या integration से आया हो सकता है।
Output को उसके असली context के अनुसार encode करें
HTML text, HTML attributes, JavaScript, CSS और URLs के parsing rules अलग हैं। उसी context के लिए बना encoder या safe sink लें, attributes को quotes में रखें और untrusted destination को `href` या `src` में डालने से पहले URL scheme validate करें। User values को inline scripts, event-handler attributes, CSS selectors या executable templates में न जोड़ें।
HTML स्वीकार करना जरूरी हो तभी उसे sanitize करें
यदि user formatting लिख सकता है तो elements और attributes की छोटी allowlist वाले maintained HTML sanitizer का उपयोग करें। HTML दिखाने की सीमा के जितना पास हो सके sanitize करें, sanitizer updated रखें और sanitized output में बाद में ऐसा बदलाव न करें जो unsafe markup लौटा दे। साधारण text के लिए sanitize करने की बजाय encode करें।
| Data का स्रोत | Render context / sink | Framework सुरक्षा | Sanitizer या URL policy | Test और owner |
|---|---|---|---|---|
| User profile या comment | ||||
| Imported integration content | ||||
| Rich-text field |
SaaS team browser-side और rich-text content कैसे संभाले?
Safe DOM APIs चुनें और खतरनाक sinks से बचें
Markup parse करने वाले APIs की बजाय text डालने वाले `textContent` जैसे APIs पसंद करें। `innerHTML`, `document.write`, dynamic script URLs, `eval` और inline event handlers के उपयोग की समीक्षा करें। एक context में सुरक्षित value दूसरे context या browser library में copy या transform होने के बाद खतरनाक हो सकती है।
Content Security Policy को जरूरत के मुताबिक अतिरिक्त परत बनाएँ
सोच-समझकर लागू Content Security Policy, script sources सीमित करके कुछ injection flaws का असर घटा सकती है। पहले report-only mode से rollout करें, product के वैध व्यवहार को देखें और फिर app के लिए उपयुक्त policy लागू करें। CSP, output encoding या sanitization की जगह नहीं; बहुत व्यापक policy सुरक्षा का झूठा भरोसा दे सकती है।
केवल cookie flags पर निर्भर हुए बिना sessions सुरक्षित रखें
`HttpOnly` page script को cookie सीधे पढ़ने से रोक सकता है, लेकिन XSS flaw browser session से authenticated request करा सकती है। Secure cookie settings कुछ नतीजों को सीमित करती हैं; वे injected code को चलने से नहीं रोकतीं। Unsafe rendering रास्ता ठीक करें और issue को contain करने के बाद session changes भी देखें।
SaaS product में XSS कैसे test करें?
हर output तक untrusted data का रास्ता trace करें
Profile fields, comments, search terms, filenames, support messages, imported records, operators को दिखाए जाने वाले logs और rich-text previews देखें। Stored, reflected और DOM-based रास्तों के साथ email या export views भी जाँचें, जो वही content अलग तरह से render कर सकते हैं। अनुमति वाले test environment में harmless markers से जाँच करें।
केवल server validation नहीं, rendered context जाँचें
सामान्य page, attributes, links, client-side updates, error states और administrative tools में content text के रूप में inert रहे, यह देखें। Sanitizer अस्वीकृत markup रोकता है और वैध formatting काम करती है, इसकी पुष्टि करें। Input filters अकेले प्रमाण नहीं; वैध punctuation और कई encodings को समर्थन देना जरूरी रहता है।
Fix और regression tests track करें
Data source, render sink, प्रभावित users, context-specific encoding या sanitization का बदलाव और उसी रास्ते को जाँचने वाला test दर्ज करें। दूसरे user या administrator पर असर और rendered page के privileges के अनुसार priority तय करें। Framework, editor या third-party component update होने पर फिर जाँचें।
SaaS XSS prevention के सवाल
क्या input validation से XSS अपने-आप रुक जाता है?
नहीं। Input validation field का format या length जैसी business जरूरत लागू करता है, लेकिन stored और third-party data unsafe render sink तक फिर भी पहुँच सकते हैं। Context-aware output encoding करें और HTML स्वीकार करना product की जरूरत हो तभी sanitize करें।
क्या Content Security Policy output encoding की जगह ले सकती है?
नहीं। CSP अतिरिक्त सुरक्षा है और कुछ flaws का असर घटा सकती है, लेकिन policy में gaps या allowed scripts के कारण app फिर भी vulnerable हो सकती है। सही rendering और sanitization मुख्य controls हैं।
क्या हर user field को HTML sanitization चाहिए?
नहीं। Plain text के लिए सुरक्षित framework rendering और context के अनुसार encoding सही तरीका है। सक्रिय रूप से maintained sanitizer तभी लें जब feature को HTML formatting का सीमित हिस्सा स्वीकार करना हो।
क्या HttpOnly से XSS का नुकसान नहीं होता?
नहीं। यह cookie सीधे पढ़ने को सीमित करता है, पर page में चल रहा malicious code user के browser session से काम कर सकता है। Injection रास्ता हटाएँ और प्रभावित account के actions तथा data की समीक्षा करें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .