Svelte 5.52.0 {@html} के लिए TrustedHTML समर्थन जोड़ता है, जिससे सुरक्षित Trusted Types एकीकरण संभव होता है

Svelte 5.52.0 (18 फरवरी, 2026 को प्रकाशित) {@html} ब्लॉक्स में TrustedHTML ऑब्जेक्ट्स के लिए प्रथम-श्रेणी का समर्थन प्रस्ताव करता है: Svelte TrustedHTML मानों को स्ट्रिंग में coercion के बजाय स्वीकार करेगा और संरक्षित करेगा, जिससे ब्राउज़र Trusted Types APIs को अपनाना आसान होगा और कच्चे HTML को रेंडर करते समय XSS जोखिम कम होगा। (github.com)

पूर्ण-स्टैक टीमों के लिए यह क्यों मायने रखता है

• Trusted Types एक ब्राउज़र‑स्तरीय सुरक्षा तंत्र है जो DOM XSS को रोकता है, ताकि HTML स्वीकार करने वाले sinks (जैसे innerHTML) उन मानों को प्राप्त करें जो एक स्वीकृत नीति के द्वारा बनाए गए हों. फ्रेमवर्क‑स्तरीय समर्थन इसका मतलब है कि अब आप Svelte के सर्वर/क्लाइंट प्रवाह को उस मॉडल में इस तरह जोड़ सकते हैं कि फ्रेमवर्क चुपचाप TrustedHTML ऑब्जेक्ट को untrusted स्ट्रिंग में पुनः बदल दे—यानी आकस्मिक प्रतिगमन के एक वर्ग को हटा देता है. (github.com)
• SSR + hydration एप्लिकेशनों के लिए, यह उन आशंकाओं को कम करता है जहाँ सर्वर-रेंडर्ड मार्कअप और क्लाइंट‑साइड नीतियाँ एक दूसरे के साथ इंटरैक्ट करती हैं. Content-Security-Policy: require-trusted-types-for 'script' (और संबंधित नीतियाँ) वाले टीमें Svelte के साथ Trusted Types को और व्यवहारिक रूप से अपना सकती हैं. (github.com)

व्यावहारिक, उच्च-प्रभाव वाला अपग्रेड चेकलिस्ट

1. [email protected] (या बाद के संस्करण) पर अपग्रेड करें।
2. {@html} के उपयोगों का ऑडिट करें: मौजूदा Raw-HTML sinks को सुरक्षा-संवेदनशील मानें और संभव हो तो ज्ञात-सुरक्षित स्रोतों से TrustedHTML मान बनाने को प्राथमिकता दें।
3. क्लाइंट-केवल Trusted Types के लिए:
   • ब्राउज़र में एक trusted policy (policy.createHTML(...)) के माध्यम से HTML बनाएं और उस TrustedHTML को उन घटकों को दें जो {@html} रेंडर करते हैं।
   • उत्पादन में CSP Trusted Types नीतियाँ सक्षम करने से पहले स्थानीय परीक्षण करें।
4. SSR परिदृश्यों के लिए:
   • सर्वर-से sanitised strings (जैसे DOMPurify) बनाना प्राथमिकता दें और पहले क्लाइंट सक्रियण पर ब्राउज़र नीति के माध्यम से TrustedHTML में परिवर्तन करें ताकि आगे के DOM ऑपरेशनों से पहले सर्वर आउटपुट सुरक्षित रहे।
   • वैकल्पिक रूप से, सुरक्षित serialization पैटर्न का उपयोग करें और hydration के दौरान allowlisted नीति के माध्यम से क्लाइंट-साइड कोड TrustedHTML पुनःसृजन करे।
5. Thoroughly टेस्ट करें: staging CSP में require-trusted-types-for सक्षम करें ताकि उन जगहों को surface किया जा सके जहाँ अभी भी untrusted strings उपयोग हो रहे हैं।

Migration pitfalls and guidance

• TrustedHTML एक ब्राउज़र रनटाइम ऑब्जेक्ट है; सर्वर सीधे ब्राउज़र TrustedHTML इंस्टेंस नहीं बना सकता. रिलीज coercion से बचाती है, पर यह स्वचालित रूप से सर्वर-निर्मित स्ट्रिंग को क्लाइंट पर TrustedHTML नहीं बनाती—आपके एप्लिकेशन को क्लाइंट-साइड TrustedHTML बनाना होगा (या hydration के दौरान policy.createHTML प्रवाह के साथ स्पष्ट, ऑडिटेड serialization बनानी होगी)।
• फ्रेमवर्क coercion पर निर्भर होकर सामग्री को sanitize न करें. TrustedHTML समर्थन Trusted Types को अपनाने में बाधा कम करता है, लेकिन आपको अभी भी उपयोगकर्ताओं या terceros से मिलने वाली किसी भी सामग्री के लिए उचित sanitization और एक स्पष्ट trust मॉडल चाहिए। (github.com)

निष्कर्ष यह Svelte रिलीज़ XSS से सुरक्षा के लिए वेब एप्लिकेशन को मजबूत करने वाली एक व्यावहारिक, ग्राउंड-लेवल सुधार है: यह Trusted Types के साथ फ्रेमवर्क‑स्तरीय impedance mismatch को दूर करता है और ब्राउज़र‑नेटिव डिफेन्स को अपनाने को अधिक सरल बनाता है—खासकर उन फुल‑स्टैक एप्लिकेशन के लिए जो SSR करते हैं और जटिल मार्कअप को hydration करते हैं. इसे {@html} उपयोग की ऑडिटिंग, sanitization नीतियों को अपनाने या कसने, और production में strict CSP सक्षम करने से पहले staging में Trusted Types के चरणबद्ध rollout की योजना बनाने के अवसर के रूप में लें. (github.com)

स्रोत:

स्रोत

• स्रोत