SaaS WebSocket security: authentication, origin और message controls
WSS, handshake origin checks, session-aware authentication, per-message authorization, schema validation और connection limits से persistent SaaS WebSocket connections सुरक्षित करें।
इस मार्गदर्शिका में
SaaS WebSocket endpoint को कैसे सुरक्षित करें?
HTTP upgrade के बाद WebSocket खुला रहता है, इसलिए केवल पहली connection सुरक्षित करने से messages और लंबे sessions सुरक्षित नहीं होते। Production में WSS रखें, समर्थित तरीके से handshake authenticate करें, cookies शामिल होने पर browser Origin को explicit allowlist से जाँचें और हर message व channel action authorize करें। Message schema validate करें, resource use सीमित करें और सामान्यतः private message content log किए बिना security events दर्ज करें।
Handshake में WSS उपयोग करें और browser Origin जाँचें
Production में `wss://` connection encrypt करें। Cookie से authenticated browser session के लिए handshake Origin को trusted application origins की सख्त सूची से मिलाएँ, जिससे cross-site WebSocket hijacking का जोखिम घटता है। Substring matching न करें और किसी भी Origin पर भरोसा न करें। Origin check browser context के लिए है; non-browser client का authentication अलग चाहिए।
Connection authenticate करें और समय के साथ identity फिर जाँचें
Client के अनुकूल documented handshake या short-lived connection-ticket अपनाएँ; लंबे समय तक चलने वाले bearer credentials को URL में रखने से बचें क्योंकि logs और telemetry उन्हें पकड़ सकते हैं। Expiry, logout, account suspension और key rotation पर open socket बंद या फिर authenticate कैसे होगा, तय करें। सफल handshake आगे के हर action को authorize नहीं करता।
हर message, room और subscription authorize करें
हर message type के लिए जाँचें कि वर्तमान user referenced record, tenant, room या subscription पर वही action कर सकता है। Channel join करते समय और sensitive state बदलने वाले operation पर permission जाँचें। Client का ID या पहले authorized connection यह साबित नहीं करता कि role या membership बदलने के बाद भी access है।
| Endpoint और client | Handshake auth और Origin नियम | Message/room permission | Size, rate और lifetime limits | Logging और negative test |
|---|---|---|---|---|
| Browser collaboration socket | ||||
| Notification stream | ||||
| Partner या service client |
Product में कौन-से message और connection controls होने चाहिए?
Messages को structured data की तरह parse और validate करें
Text को code की तरह चलाने के बजाय JSON.parse जैसे data parser से पढ़ें। Dispatch से पहले allowlisted message type, schema, आकार, field length और business rules लागू करें। बाद में content render हो तो सही encoding करें; WebSocket message को सुरक्षित न मानें सिर्फ इसलिए कि वह सामान्य form route से नहीं आया।
Connection exhaustion और abusive traffic सीमित करें
Measured product जरूरत के अनुसार message size, connection count, idle time, subscriptions और per-user या per-tenant message rate सीमित करें। Heartbeat और timeout रखें तथा सुरक्षित सीमा पार करने वाले sockets बंद करें। Load balancer, proxy और application में limits समन्वित हों ताकि upstream default service policy को कमजोर न करे।
Reconnect और shared infrastructure को नई trust जाँच मानें
Reconnect पर केवल वही subscriptions बहाल हों जिन्हें वर्तमान identity अब भी उपयोग कर सकती है। Sticky sessions, tenant routing, Origin policy, proxy upgrade और regions में backpressure देखें। Client के reconnect token या room name से privileged access चुपचाप restore न हो।
WebSocket security की testing और monitoring कैसे करें?
Denied origins, expired sessions और cross-tenant messages test करें
अनुमत test में unapproved browser Origin से handshake और फिर missing या invalid authentication, expired credentials, revoked session तथा suspended user जाँचें। अलग test tenants से दूसरे tenant के room में subscribe या record बदलने की कोशिश करें। पहले से खुली connection पर permission बदलने का असर भी देखें।
Message validation और connection resource limits जाँचें
Controlled environment में malformed, unexpected, oversized और तेज़ी से भेजे गए messages test करें। Service उन्हें reject करे, CPU व memory काम सीमित रखे, abusive sockets को अपेक्षित ढंग से बंद करे और normal clients के लिए उपलब्ध रहे। Slow consumer, reconnect storm और downstream outage भी resilience test में रखें।
पूरे private messages के बजाय security lifecycle log करें
जहाँ उचित हो, connection open/close, identity और tenant context, denied operation, rate-limit event और abnormal error दर्ज करें। Default रूप से पूरा private message, access token या secret log न करें। सामान्य HTTP access log केवल upgrade request दिखा सकता है, इसलिए जरूरी message actions के लिए application-level events जोड़ें।
WebSocket SaaS security के सवाल
क्या authenticated WebSocket में हर message भरोसेमंद होता है?
नहीं। हर message को validate करें और मौजूदा policy से action, object तथा tenant authorize करें। Socket खुला रहने पर भी membership या permission बदल सकती है।
क्या Origin validation WebSocket authentication की जगह लेता है?
नहीं। Cookie-backed handshake में Origin बताता है कि browser request कहाँ से शुरू हुई। User और service clients को अलग authenticate करें और उनके message actions authorize करें।
क्या internal production traffic में ws:// उपयोग कर सकते हैं?
Production में encrypted `wss://` connection उपयोग करें। केवल internal network में होना रास्ते में traffic देखने या बदलने से नहीं रोकता।
क्या security logs में हर WebSocket message रखना चाहिए?
आम तौर पर नहीं। जाँच के लिए identity, action, decision और operational context दर्ज करें, पर private message, token और sensitive fields कम से कम रखें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .