ओरिजिन एपीआई एज 145 में आया — ब्राउज़रों में नेटिव ओरिजिन ऑब्जेक्ट

क्या हुआ

• माइक्रोसॉफ्ट एज 145 ओरिजिन एपीआई को शिप करता है — एक नेटिव, संरचित ओरिजिन ऑब्जेक्ट जो वेब कोड को ओरिजिन को पार्स, सीरियलाइज़ और तुलना करने की अनुमति देता है, बजाय इसके कि वह नाजुक ASCII स्ट्रिंग्स पर निर्भर करे। (learn.microsoft.com)

फुल-स्टैक डेवलपर्स के लिए यह क्यों महत्वपूर्ण है

• सुरक्षित ओरिजिन तुलना: कई सुरक्षा बग और लॉजिक त्रुटियाँ सीरियलाइज़्ड ओरिजिन स्ट्रिंग्स (या location.origin को पार्स करने) की तुलना से आती हैं, विशेष रूप से ओपैक ओरिजिन के आसपास (सैंडबॉक्स किए गए iframe, डेटा URL, आदि)। ओरिजिन एपीआई ब्राउज़र के कैनोनिकल ओरिजिन प्रतिनिधित्व को उजागर करता है और तुलना हेल्पर्स को उजागर करता है ताकि आप नाजुक स्ट्रिंग हैंडलिंग के बिना समान ओरिजिन / समान साइट संबंधों का विश्वसनीय परीक्षण कर सकें। (learn.microsoft.com)
• iframe और सैंडबॉक्स परिदृश्यों के लिए कम एज केस: ओपैक ओरिजिन विशेष रूप से व्यवहार करते हैं (सिर्फ अपने साथ समान ओरिजिन)। ओरिजिन एपीआई आपको उन अर्थों के बारे में सीधे सोचने की अनुमति देता है, बजाय इसके कि आप कस्टम स्ट्रिंग ह्यूरिस्टिक्स का आविष्कार करें। (learn.microsoft.com)
• सरल सर्वर/क्लाइंट समन्वय: सर्वर लॉजिक जो वर्तमान में हेडर, क्वेरी पैरामीटर, या document.referrer से ओरिजिन को पार्स करता है, उसे सरल बनाया जा सकता है (या कम से कम सत्यापित किया जा सकता है) उसी कैनोनिकल प्रतिनिधित्व के खिलाफ जो ब्राउज़र उपयोग करता है, जिससे ऐसे असंगतताएँ कम होती हैं जो ऑथ/सेशन समस्याओं और CSRF/CORS गलतियों का कारण बनती हैं। (learn.microsoft.com)

क्या आया (संक्षेप में)

• ब्राउज़र एक प्रथम श्रेणी का ओरिजिन ऑब्जेक्ट प्रस्तुत करता है जो पार्सिंग/सीरियलाइज़िंग और मजबूत ओरिजिन/साइट तुलना का समर्थन करता है; ब्राउज़रों ने इस फीचर को स्थिर चैनलों में स्थानांतरित कर दिया है और यह फीचर HTML स्पेक/टेस्टिंग में परिलक्षित होता है। (learn.microsoft.com)

तत्काल चेकलिस्ट — टीमों के लिए व्यावहारिक कदम (उच्च प्राथमिकता)

1. ओरिजिन तुलना और ऑथ जांच का ऑडिट करें (1–2 दिन)
   • अपने कोडबेस में किसी भी लॉजिक की खोज करें जो स्ट्रिंग समानता का उपयोग करके ओरिजिन की तुलना करता है (जैसे, a.origin === b.origin, होस्टनेम का regex पार्सिंग, मैनुअल सबस्ट्रिंग जांच)। इन स्थानों को जोखिम भरा मानें और उन्हें आधुनिक बनाने के लिए परीक्षण या फीचर फ्लैग जोड़ें।
2. फीचर-डिटेक्ट करें और क्रमिक रूप से सुधारें (कुछ मिनट)
   • फीचर डिटेक्शन (if (typeof Origin !== 'undefined')) का उपयोग करें ताकि जहां उपलब्ध हो, नेटिव एपीआई का उपयोग किया जा सके और पुराने ब्राउज़रों के लिए वर्तमान फॉलबैक बनाए रखें।
   • उदाहरण पैटर्न (संकल्पनात्मक, इनलाइन):
     • यदि Origin मौजूद है: const o = Origin.from(someValue); o.isSameOrigin(otherOrigin);
     • अन्यथा: अपने स्ट्रिंग-आधारित लॉजिक को संकेंद्रित फॉलबैक हेल्पर्स का उपयोग करते रहें जो अच्छी तरह से परीक्षण किए गए हैं।
3. सर्वर-साइड सत्यापन और लॉगिंग को अपडेट करें (कुछ घंटे)
   • जहां सर्वर ओरिजिन हेडर्स (CORS, टोकन बाइंडिंग, वेबहुक सत्यापन) को मान्य करते हैं, वहां प्राप्त सीरियलाइज़्ड ओरिजिन और क्लाइंट कोड द्वारा रोलआउट के दौरान उत्पन्न कैनोनिकल ओरिजिन दोनों को लॉग करें। इससे असंगतताएँ जल्दी सामने आएंगी।
4. इंटीग्रेशन परीक्षणों में iframe / सैंडबॉक्स व्यवहार को मजबूत करें (1–3 दिन)
   • सैंडबॉक्स किए गए iframes, डेटा/फाइल URLs, और रीडायरेक्ट के लिए इंटीग्रेशन परीक्षण जोड़ें ताकि सत्र और SameSite हैंडलिंग की पुष्टि की जा सके। ओरिजिन एपीआई कई एज केस को स्पष्ट बनाता है; उनका परीक्षण करें।
5. प्रतिस्थापन रोडमैप की योजना बनाएं (2–4 स्प्रिंट)
   • महत्वपूर्ण सुरक्षा पथों (CSRF जांच, सत्र बाइंडिंग, भुगतान प्रवाह) को फिर से तैयार करें ताकि जहां संभव हो, कैनोनिकल ओरिजिन तुलना को प्राथमिकता दी जा सके। कम जोखिम वाले सेवाओं से शुरू करें और आगे बढ़ें।

संगतता और रोलआउट नोट्स

• ओरिजिन एपीआई क्रोमियम-आधारित स्थिर चैनलों (एज 145 / क्रोमियम शिप गतिविधि) में आ रहा है, और संबंधित इंजन कार्य अन्य ब्राउज़र इंजनों में मौजूद है; रोलआउट ब्राउज़र और प्लेटफ़ॉर्म के अनुसार भिन्न होते हैं — संक्रमण के दौरान फीचर डिटेक्शन का उपयोग करते रहें और फॉलबैक बनाए रखें। (learn.microsoft.com)
• अभी तक सार्वभौमिक उपलब्धता का अनुमान न लगाएं — एपीआई को एक क्रमिक सुधार के रूप में मानें और महत्वपूर्ण प्रवाहों की सुरक्षा के लिए सर्वर-साइड सत्यापन करें जब तक कि आपने क्लाइंट अपनाने को माप नहीं लिया है।

जोखिम और समस्याएँ

• केवल इसलिए सर्वर-साइड प्राधिकरण जांचों को प्रतिस्थापित न करें क्योंकि क्लाइंट एक ओरिजिन की रिपोर्ट करता है — ओरिजिन एपीआई क्लाइंट्स को कम गलतियाँ करने में मदद करता है, लेकिन हमलावर-नियंत्रित इनपुट को अभी भी सर्वर-साइड पर मान्य किया जाना चाहिए।
• तृतीय-पक्ष फ्रेम और क्रॉस-ओरिजिन नेविगेशनों पर ध्यान दें: Origin ऑब्जेक्ट की उपस्थिति अंतर्निहित सुरक्षा मॉडल को नहीं बदलती; यह केवल मॉडल को स्क्रिप्ट से निरीक्षण करना आसान और सुरक्षित बनाता है।

निष्कर्ष

• ओरिजिन एपीआई एक सूक्ष्म, उच्च-प्रभाव वाला वेब-प्लेटफ़ॉर्म सुधार है: यह ओरिजिन/पार्सिंग बग के वर्गों को कम करता है जो ऐतिहासिक रूप से सुरक्षा और सत्र प्रबंधन समस्याएँ उत्पन्न करते हैं। ओरिजिन तुलना का ऑडिट करके शुरू करें, फीचर डिटेक्शन जोड़ें, और एक बार अपनाने के बाद महत्वपूर्ण जांचों को कैनोनिकल तुलना का उपयोग करने के लिए क्रमिक रूप से माइग्रेट करें। (learn.microsoft.com)

स्रोत:

स्रोत

• Source