वेब डेवलपमेंट में एआई से होने वाली 10 सबसे बड़ी गलतियां

Philip Walton

पब्लिश होने की तारीख: 11 नवंबर, 2026

इस हफ़्ते, हमने मॉडर्न वेब गाइडेंस का वर्शन 1.0 रिलीज़ किया है. यह स्किल का एक सेट है, जो वेब प्लैटफ़ॉर्म की विशेषज्ञता, सबसे सही तरीकों, और ब्राउज़र के साथ काम करने के डेटा को सीधे आपके कोडिंग एजेंट में एम्बेड करता है. मॉडर्न वेब गाइडेंस का हमारा मकसद, एआई कोडिंग एजेंट का इस्तेमाल करने वाले डेवलपर की मदद करना है, ताकि वे मॉडर्न वेब प्लैटफ़ॉर्म की क्षमता और सुविधाओं का पूरा फ़ायदा ले सकें. इससे उपयोगकर्ताओं को वेब पर बेहतर अनुभव मिलेगा.

मई में मॉडर्न वेब गाइडेंस की सार्वजनिक तौर पर उपलब्ध होने से पहले वाली झलक पेश करने के बाद से, कोडिंग एजेंट बेहतर से बेहतर होते गए हैं. साथ ही, कई शानदार नए फ़्रंटियर मॉडल रिलीज़ किए गए हैं. हमसे अक्सर एक सवाल पूछा जाता है: क्या ये नए फ़्रंटियर मॉडल, वेब डेवलपमेंट के सबसे सही तरीकों का पहले से ही पालन नहीं करते?

माफ़ करें, इसका जवाब "नहीं" है. हमें पता है कि इसका जवाब "नहीं" है, क्योंकि हमने इसकी जांच की है.

मॉडर्न वेब गाइडेंस की हर गाइड में, ज़रूरी शर्तों का एक सेट तय किया गया है. अगर गाइड में बताए गए सबसे सही तरीकों का ठीक से पालन किया गया है, तो इन शर्तों को पूरा करना ज़रूरी है. इसके बाद, हमारा इवैल सुइट उन गाइड की जांच करता है. इसके लिए, वह मॉडर्न वेब गाइडेंस (गाइड किया गया एजेंट) इंस्टॉल करके चलाए जा रहे एजेंट और मॉडर्न वेब गाइडेंस (बिना गाइड किया गया एजेंट) इंस्टॉल किए बिना चलाए जा रहे दूसरे एजेंट को एक ही प्रॉम्प्ट देता है. दोनों रन के आउटपुट की जांच, गाइड में बताई गई उम्मीदों के हिसाब से की जाती है.

निर्देशों के साथ और बिना निर्देशों के पास होने की दर की तुलना करने पर, यह पता चलता है कि एआई मॉडल, आधुनिक वेब डेवलपमेंट के सबसे सही तरीकों को अपने-आप पूरी तरह से लागू नहीं कर पाते. यहां तक कि सबसे नए फ़्रंटियर मॉडल भी ऐसा नहीं कर पाते.

औसतन, बिना गाइडेंस वाले कोडिंग एजेंट, हमारे इवैलुएशन सुइट में सिर्फ़ 50% जांच पास कर पाते हैं. वहीं, मॉडर्न वेब गाइडेंस का इस्तेमाल करने पर, करीब 90% जांच पास हो जाती हैं.

हमारे इवैल डैशबोर्ड पर जाकर, हर गाइड के लिए की जाने वाली खास जांचों की पूरी सूची देखी जा सकती है. साथ ही, यह भी देखा जा सकता है कि हर मॉडल को उन जांचों में कितना स्कोर मिला है.

हालांकि, इस पोस्ट में हमने 10 ऐसी समस्याओं के बारे में बताया है जो एआई मॉडल में अक्सर देखने को मिलती हैं. ये समस्याएं, वेब डेवलपर के रोज़मर्रा के काम से जुड़े मुख्य विषयों से जुड़ी हैं. जैसे, सुलभता, उपयोगकर्ता अनुभव, परफ़ॉर्मेंस, और सुरक्षा.

1. सुलभता: कीबोर्ड फ़ोकस और inert मैनेजमेंट

कीबोर्ड या स्क्रीन रीडर का इस्तेमाल करके नेविगेट करने वाले लोगों के लिए, इंटरैक्टिव यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करना आसान होता है. ऐसा इसलिए, क्योंकि इसमें फ़ोकस ऑर्डर का अनुमान लगाया जा सकता है. इसके बिना, फ़ोकस बैकग्राउंड में मौजूद कॉन्टेंट पर जा सकता है या कई अतिरिक्त टैब स्टॉप में अटक सकता है.

फ़ोकस और inert मैनेजमेंट, हमारे आकलन में सुलभता से जुड़ी सबसे बड़ी कमियों में से एक है. साथ ही, यह उन क्षेत्रों में से एक है जिनमें मॉडर्न वेब गाइडेंस की मदद से सबसे ज़्यादा सुधार होता है. आम तौर पर होने वाली गलतियां:

• नए खुले व्यू पर फ़ोकस न करना और वापस जाने पर, ट्रिगर करने वाले एलिमेंट पर फ़ोकस वापस न लाना.
• कस्टम मॉडल पर मैन्युअल JavaScript टैब ट्रैप और aria-modal="true" पर भरोसा करना. इसके बजाय, मॉडल <dialog> का इस्तेमाल करना या बैकग्राउंड कॉन्टेंट inert को मार्क करना.
• टूलबार या डायरेक्शनल ग्रिड में मौजूद हर आइटम को अलग-अलग टैब स्टॉप के तौर पर दिखाना. इसके बजाय, रोविंग tabindex के साथ एक टैब स्टॉप का इस्तेमाल करना.
• कस्टम :focus-visible आउटलाइन बनाना, जिनका आस-पास के बैकग्राउंड के साथ कंट्रास्ट रेशियो 3:1 से कम हो.

2. सुलभता: कम मोशन वाली सुविधा

पेज पर अचानक होने वाले मूवमेंट और बड़े पैमाने पर होने वाले ऐनिमेशन, न सिर्फ़ ध्यान भटकाते हैं, बल्कि वेस्टिबुलर डिसऑर्डर या मोशन सेंसिटिविटी वाले लोगों के लिए, चक्कर आना, जी मिचलाना या सिरदर्द जैसी समस्याएं भी पैदा कर सकते हैं.

एआई मॉडल आम तौर पर, स्टैंडर्ड सीएसएस ट्रांज़िशन या कीफ़्रेम ऐनिमेशन जोड़ते समय prefers-reduced-motion की जांच करना याद रखते हैं. हालांकि, स्मूद स्क्रोलिंग, व्यू ट्रांज़िशन या स्क्रोल-ड्रिवन ऐनिमेशन जैसी नई सुविधाओं का इस्तेमाल करते समय, वे अक्सर कम मोशन वाली सेटिंग को भूल जाते हैं या उसे लागू करते समय गलतियां कर देते हैं:

• रूट एलिमेंट पर, scroll-behavior:smooth को ग्लोबल तौर पर और बिना किसी शर्त के सेट करना.
• स्क्रोल-ड्रिवन सीएसएस ऐनिमेशन का इस्तेमाल करना, लेकिन कम मोशन की जांच न करना.
• स्क्रोल करते समय मोशन को कम करने के लिए, कैरसेल आइटम पर transition ड्यूरेशन को हटाना, लेकिन ट्रांसफ़ॉर्म प्रॉपर्टी को हटाना भूल जाना. इससे स्क्रोल करते समय आइटम का साइज़ अचानक बदल जाता है.
• कम मोशन की सुविधा चालू होने पर, *, *::before, और *::after पर 0.01ms की अवधि को रीसेट करने से, सभी ज़रूरी नॉन-मोशन ट्रांज़िशन भी मिट जाते हैं. ये ट्रांज़िशन, यूज़र इंटरफ़ेस (यूआई) की स्थिति में होने वाले बदलावों को बताने के लिए ज़रूरी होते हैं.
• बिना किसी शर्त के, अलग-अलग दस्तावेज़ों के बीच व्यू ट्रांज़िशन की सुविधा चालू करना और कम मोशन की सुविधा चालू होने पर, ::view-transition-* ऐनिमेशन को बदलना. इसके लिए, कम मोशन की जांच के बाद, @view-transition नियम को लागू करने की ज़रूरत नहीं है.

3. सुलभता: फ़ॉर्म की पुष्टि, फ़ॉर्मैट के संकेत, और ऑटोमैटिक भरने की सुविधा की स्थितियां

वेब पर, क्रिटिकल यूज़र जर्नी के लिए फ़ॉर्म सबसे अहम होते हैं. चेकआउट फ़ॉर्म में होने वाली छोटी सी गड़बड़ी भी, कारोबार की आय पर काफ़ी असर डाल सकती है.

फ़ॉर्म बनाते समय, एआई मॉडल ज़्यादातर बुनियादी बातों का ध्यान रखते हैं. हालांकि, वे अक्सर छोटी लेकिन ज़रूरी चीज़ों पर ध्यान नहीं देते. जैसे, पुष्टि करने से जुड़ी गड़बड़ियां, प्लेसहोल्डर और फ़ॉर्मैट के हिंट को सही जगह पर न रखना, और Password Manager और जानकारी अपने-आप भरने की सुविधाओं को सही तरीके से इंटिग्रेट न करना:

• कस्टम JavaScript blur की पुष्टि करने की सुविधा के साथ सीएसएस :user-invalid को फिर से लागू करना. इससे अक्सर उन required फ़ील्ड को फ़्लैग किया जाता है जिन्हें उपयोगकर्ताओं ने टैब से आगे बढ़ने के बाद भी नहीं छुआ है.
• aria-invalid को सिंक न होने देना, जिससे गड़बड़ियां दिखती हैं. जैसे, aria-invalid="true" को समय से पहले blur पर सेट करना या JavaScript में aria-invalid को सिंक किए बिना, सीएसएस में :user-invalid को स्टाइल करना.
• ज़रूरी फ़ॉर्मैट (जैसे, कार्ड की समयसीमा खत्म होने की तारीख के इनपुट पर MM/YY) दिखाने के लिए, गायब होने वाले placeholder टेक्स्ट पर भरोसा करना. इसके बजाय, aria-describedby से जुड़े हिंट को लगातार रेंडर करना चाहिए.
• फ़ॉर्मैट के संकेत और पासवर्ड के नियम, <input> के ऊपर के बजाय नीचे रखे गए हैं. इस वजह से, जब उपयोगकर्ता को इन्हें पढ़ने की ज़रूरत होती है, तब ये मोबाइल कीबोर्ड और जानकारी अपने-आप भरने की सुविधा के पॉपओवर से छिप सकते हैं.
• :autofill इनपुट को हाइलाइट करने के लिए, सिर्फ़ बॉर्डर का रंग बदला गया है. इसके बजाय, रंग के साथ-साथ बिना रंग वाले संकेत का इस्तेमाल किया जाना चाहिए, जिससे लेआउट में बदलाव न हो. जैसे, इनसेट box-shadow.

4. उपयोगकर्ता अनुभव: स्वाइप और टच जेस्चर

एजेंट, इंपेरेटिव JavaScript का इस्तेमाल करके टच जेस्चर लागू करने और अपना कस्टम फ़िज़िक्स लॉजिक लिखने में माहिर होते हैं. ये तरीके काम करते हैं. हालांकि, JavaScript की मदद से काम करने वाले टच इंटरैक्शन, उपयोगकर्ताओं को उतने आसान नहीं लगते जितने कि खास ऐप्लिकेशन के होते हैं.

इनमें से कई इंटरैक्शन, सीएसएस और नेटिव स्क्रोल एपीआई की मदद से लागू किए जा सकते हैं. इससे ब्राउज़र, जेस्चर फ़िज़िक्स को मुख्य थ्रेड से बाहर चला सकता है. हालांकि, हमारे आकलन के मुताबिक, एआई मॉडल अक्सर इन सुविधाओं को अनदेखा कर देते हैं:

• सीएसएस स्क्रोल स्नैप का इस्तेमाल करने के बजाय, pointermove या touchmove लिसनर के साथ स्वाइप-टू-डिसमिस या स्वाइप-टू-रिवील जेस्चर लागू करना.
• टैब-स्वाइप इंटरफ़ेस पर overscroll-behavior-x:none को हटाना. इससे, ज़्यादा स्वाइप करने पर, ब्राउज़र में गलती से पीछे या आगे जाने की सुविधा ट्रिगर हो सकती है.
• स्क्रोल-ड्रिवन ऐनिमेशन का इस्तेमाल करने के बजाय, JavaScript कॉलबैक में मुख्य थ्रेड पर स्वाइप प्रोग्रेस इफ़ेक्ट को चलाना.
• स्क्रोल करके स्वाइप करने की सुविधा वाले पैनल पर, कीबोर्ड फ़ोकस ठीक से काम नहीं कर रहा है.

5. उपयोगकर्ता अनुभव: डायलॉग, पॉपओवर, और टॉप-लेयर ट्रांज़िशन

हमारे आकलन में, मॉडल अक्सर ज़रूरी JavaScript वर्कअराउंड का इस्तेमाल करते हैं. ऐसा तब होता है, जब मॉडल डायलॉग और पॉपओवर के आस-पास स्क्रोल करने की सुविधा को ऐनिमेट किया जाता है, खारिज किया जाता है या उसमें शामिल किया जाता है.

टॉप-लेयर ओवरले के लिए बनाई गई आधुनिक एचटीएमएल और सीएसएस सुविधाओं पर भरोसा करने के बजाय, एजेंट अक्सर एंट्री और एग्ज़िट स्टेट मशीन, इतिहास के हुक, और बॉडी स्क्रोल लॉक को खुद बनाते हैं. इन्हें मैनेज करना मुश्किल होता है और इनमें यूज़र इंटरफ़ेस (यूआई) से जुड़ी गड़बड़ियां होने की संभावना ज़्यादा होती है.

इन इंटरैक्शन को सही तरीके से इस्तेमाल करने पर, उपयोगकर्ता को खराब अनुभव के बजाय बेहतर अनुभव मिल सकता है. इससे उपयोगकर्ता का भरोसा बढ़ता है. यहां कुछ ऐसी आम गलतियां दी गई हैं जो अक्सर देखने को मिलती हैं:

• सिर्फ़ popover का इस्तेमाल करने के बजाय, कस्टम position:fixed ओवरले बनाना. इनमें मैन्युअल तरीके से क्लिक-आउटसाइड हैंडलर का इस्तेमाल किया जाता है, ताकि लाइट डिसमिस की सुविधा का इस्तेमाल किया जा सके.
• एंट्री और एग्ज़िट ऐनिमेशन बनाने के लिए, सीएसएस ट्रांज़िशन क्लास को टॉगल करना और requestAnimationFrame() और transitionend लिसनर (setTimeout() फ़ॉलबैक के साथ) के साथ कोऑर्डिनेट करना. इसके बजाय, @starting-style और transition-behavior के साथ प्योर सीएसएस में ऐसा करना.
• ओवरस्क्रोल को रोकने के लिए <dialog> एलिमेंट का इस्तेमाल करने के बजाय, <html> पर overflow:hidden सेट करके, खुले हुए मॉडल के पीछे पेज स्क्रोल को लॉक करना.
• Android पर 'वापस जाएं' जेस्चर का पता लगाने और खुले हुए मॉडल बंद करने के लिए, popstate लिसनर जोड़े जा रहे हैं. इसके लिए, मॉडल <dialog> एलिमेंट के नेटिव 'वापस जाएं' बटन की सुविधा का इस्तेमाल नहीं किया जा रहा है.

6. उपयोगकर्ता अनुभव: गहरे रंग वाला मोड और थीम के हिसाब से अडैप्ट होने वाले कंट्रोल

उपयोगकर्ता, गहरे रंग वाले मोड को चालू करते हैं, ताकि उनकी आंखों पर ज़ोर न पड़े और स्क्रीन की चमक कम हो जाए. इसलिए, पेज लोड होने पर तेज़ सफ़ेद रोशनी, बिना थीम वाले फ़ॉर्म कंट्रोल या ओएस की सेटिंग के साथ सिंक न होने वाला टॉगल, उपयोगकर्ता अनुभव को तुरंत खराब कर देता है.

गहरे रंग वाले मोड को टॉगल करना आसान लग सकता है. हालांकि, हमारे आकलन में बिना गाइड वाले मॉडल, प्लैटफ़ॉर्म की उन ज़रूरी जानकारी को लगातार अनदेखा करते हैं जो थीम स्विच करने और नेटिव फ़ॉर्म कंट्रोल को सही तरीके से इस्तेमाल करने के लिए ज़रूरी हैं:

• <head> में <meta name="color-scheme" content="light dark"> मौजूद नहीं है. इस वजह से, गहरे रंग वाले मोड का इस्तेमाल करने वाले उपयोगकर्ताओं को बाहरी स्टाइलशीट लोड होने के दौरान, सफ़ेद कैनवस फ़्लैश दिखता है.
• color-scheme को सेट किए बिना, गहरे रंग वाली थीम या गहरे रंग वाले कॉम्पोनेंट को पसंद के हिसाब से रंगों से स्टाइल करना. इससे नेटिव स्क्रोलबार और फ़ॉर्म कंट्रोल, हल्के रंग वाले मोड में ही रह जाते हैं.
• थीम के हिसाब से अडैप्ट होने वाले कलर टोकन तय करते समय, सीएसएस light-dark() फ़ंक्शन को अनदेखा करना. ये टोकन, चालू color-scheme को अपने-आप फ़ॉलो करते हैं.
• सिर्फ़ बाइनरी लाइट या डार्क टॉगल उपलब्ध कराना, जो localStorage में साफ़ तौर पर बदलाव करता है. साथ ही, ओएस के डिफ़ॉल्ट मोड पर वापस जाने का विकल्प नहीं देता.
• storage इवेंट लिसनर को जोड़ना भूल जाना. इससे, उपयोगकर्ता के थीम बदलने पर, अन्य खुले हुए टैब सिंक नहीं हो पाते.

7. परफ़ॉर्मेंस: रनटाइम रिस्पॉन्सिवनेस और स्मूदनेस

उपयोगकर्ता, वेब पेज के लोड होने के बाद उस पर ज़्यादा समय बिताते हैं. इसलिए, पेज के धीमे इंटरैक्शन और खराब ट्रांज़िशन से उपयोगकर्ता अनुभव पर उतना ही बुरा असर पड़ सकता है जितना कि पेज के शुरुआती लोड होने में लगने वाले समय से पड़ता है.

हमारी जांच में, मॉडल आम तौर पर लोड-टाइम के उन सबसे सही तरीकों का पालन करते हैं जिन्हें Lighthouse जैसे टूल में सालों से प्रमोट किया जा रहा है. साथ ही, वे आम तौर पर साफ़ तौर पर भारी लूप को वेब वर्कर पर ऑफ़लोड करना जानते हैं. उन्हें मुख्य थ्रेड की रिस्पॉन्सिवनेस को मैनेज करने में लगातार परेशानी होती है. यह आईएनपी को ऑप्टिमाइज़ करने के लिए ज़रूरी है: लेआउट के काम को अलग करना, प्राथमिकता के हिसाब से टास्क शेड्यूल करना, और नई एचटीएमएल और सीएसएस सुविधाओं का फ़ायदा लेना, जो मुख्य थ्रेड से रेंडरिंग का काम करती हैं.

उदाहरण के लिए, हम अक्सर एजेंट को ये काम करते हुए देखते हैं:

• बैकग्राउंड में होने वाले या कम प्राथमिकता वाले काम के लिए, कस्टम setTimeout() सूची का इस्तेमाल करना. ऐसा तब करना, जब उपयोगकर्ता को दिखने वाले टास्क को scheduler.postTask() की मदद से प्राथमिकता न दी गई हो या ब्राउज़र के साथ काम करने पर, scheduler.yield() की मदद से टास्क को जारी रखने की सुविधा का फ़ायदा न लिया गया हो.
• content-visibility:auto और contain-intrinsic-size को लागू किए बिना, मुश्किल लेआउट (जैसे, डेंस डेटा ग्रिड) बनाना. इसका मतलब है कि उपयोगकर्ता के इंटरैक्शन के बाद होने वाले अपडेट, पूरे पेज को फिर से रीफ़्लो करते हैं.
• content-visibility:hidden (inert के साथ जोड़ा गया) का इस्तेमाल करने के बजाय, display:none का इस्तेमाल करके, एसपीए के इनऐक्टिव व्यू को छिपाना या उन्हें हटाना. पहले वाले तरीके से, कैश मेमोरी में सेव की गई रेंडरिंग की स्थिति खत्म हो जाती है. इसलिए, वापस स्विच करने पर पूरा लेआउट और पेंट ट्रिगर होता है.
• Intersection Observer कॉलबैक की मदद से, ऑफ़स्क्रीन <canvas> ऐनिमेशन और बैकग्राउंड लूप को रोकना. इसके लिए, content-visibility:auto को contentvisibilityautostatechange इवेंट (जहां उपलब्ध हो) के साथ जोड़ने के बजाय, एलिमेंट के स्क्रोल होने से पहले ब्राउज़र के प्री-रेंडर मार्जिन को छोड़ना.
• scroll इवेंट लिसनर का इस्तेमाल करके, स्क्रोल करने की सुविधा के यूआई हिंट बनाना. ये इवेंट लिसनर, लेआउट की लगातार कैलकुलेशन करते हैं. इसके बजाय, सीएसएस स्क्रोल-स्टेट क्वेरी का इस्तेमाल करना चाहिए (Intersection Observer फ़ॉलबैक के साथ).

8. परफ़ॉर्मेंस: लेआउट में बदलाव और विज़ुअल फ़्लिकर

लेआउट में अचानक होने वाले बदलावों से, कॉन्टेंट पढ़ने वाले व्यक्ति का ध्यान भटक जाता है. साथ ही, ऐसा हो सकता है कि उपयोगकर्ता अनजाने में किसी ऐसे बटन पर क्लिक कर दे जिससे उसे नुकसान हो जाए!

मॉडल, लेआउट शिफ़्ट से बचने के लिए स्टैंडर्ड <img> एलिमेंट में width और height एट्रिब्यूट को भरोसेमंद तरीके से जोड़ते हैं. हालांकि, वे लेआउट शिफ़्ट के अन्य सामान्य सोर्स और <video> एलिमेंट से प्री-पेंट फ़्लैश, वेब फ़ॉन्ट स्वैप, मोबाइल ब्राउज़र टूलबार, और क्लाइंट-साइड एक्सपेरिमेंट को लगातार मिस करते हैं. इन सभी का असर CLS पर पड़ सकता है.

• <video> एलिमेंट पर साफ़ तौर पर width और height एट्रिब्यूट को शामिल न करना (ताकि अनलोड किए गए प्लेयर डिफ़ॉल्ट रूप से 300×150 पर सेट हो जाएं और मेटाडेटा लोड होने के बाद लेआउट शिफ़्ट हो जाए) या मीडिया एलिमेंट पर सीधे aspect-ratio और object-fit सेट करने के बजाय, मीडिया रैपर एलिमेंट को स्टाइल करना.
• font-size-adjust के बिना, वेब फ़ॉन्ट को सिस्टम के फ़ॉलबैक फ़ॉन्ट के साथ जोड़ा जा रहा है. इस वजह से, वेब फ़ॉन्ट के स्वैप होने पर, पैराग्राफ़ और हेडिंग फिर से दिख रही हैं.
• डाइनैमिक या छोटे व्यूपोर्ट यूनिट (dvh, svh) के बजाय स्टैटिक vh यूनिट का इस्तेमाल करके, हीरो सेक्शन और फ़ुल-स्क्रीन लेआउट का साइज़ तय करना. इससे मोबाइल ब्राउज़र टूलबार के बड़ा और छोटा होने पर, कॉन्टेंट जंप होता है.
• क्लाइंट-साइड A/B टेस्ट के लिए, लेगसी opacity:0 या visibility:hidden एंटी-फ़्लिकर स्निपेट और कई सेकंड के टाइम आउट का इस्तेमाल करके कॉन्टेंट छिपाना. इससे एलसीपी में देरी होती है और न दिखने वाले एलिमेंट क्लिक करने लायक रह जाते हैं. इसके बजाय, उपलब्ध होने पर blocking="render" वाली स्क्रिप्ट का इस्तेमाल करें.
• rel="expect" और blocking="render" का इस्तेमाल करके, पहले रेंडर को होल्ड करने के बजाय, पेज के सबसे ऊपर दिखने वाले ज़रूरी मार्कअप को पार्स करने से पहले, क्रॉस-डॉक्यूमेंट व्यू ट्रांज़िशन को ट्रिगर करना. इससे ट्रांज़िशन के बीच में, आधे पार्स किए गए एलिमेंट पॉप-अप होते हैं.

9. सुरक्षा: डीओएम XSS से बचाव और एचटीएमएल सैनिटाइज़ेशन

क्रॉस-साइट स्क्रिप्टिंग (XSS) की एक गड़बड़ी की वजह से, हमलावर आपके उपयोगकर्ताओं के ब्राउज़र में अपनी पसंद का कोड चला सकता है. इससे वह सेशन का डेटा चुरा सकता है या उपयोगकर्ताओं की ओर से कार्रवाइयां कर सकता है. इसलिए, ब्राउज़र से लागू की गई सुरक्षा सुविधाएं बहुत ज़रूरी हैं. जैसे, सुरक्षित एचटीएमएल सैनिटाइज़ेशन, भरोसेमंद टाइप, और सख्त सीएसपी.

मॉडल, सुरक्षा से जुड़ी इन समस्याओं को पहले से हल करने की कोशिश नहीं करते. उदाहरण के लिए, हमारे पूरे इवैलुएशन सुइट में मौजूद सभी टास्क में, मॉडल ने साफ़ तौर पर प्रॉम्प्ट दिए बिना, कॉन्टेंट की सुरक्षा के लिए नीति (सीएसपी) या क्रॉस-ऑरिजिन आइसोलेशन हेडर नहीं जोड़ा.

जब प्रॉम्प्ट में सीधे तौर पर सुरक्षा का अनुरोध किया जाता है, तब भी बिना गाइड किए गए मॉडल, हमारी सुरक्षा जांचों में से आधे से ज़्यादा में फ़ेल हो जाते हैं. इसकी वजह यह है कि वे कमज़ोर कस्टम फ़ॉलबैक या अधूरी नीतियों का इस्तेमाल करते हैं. डीओएम एक्सएसएस से बचाव करते समय यह साफ़ तौर पर दिखता है:

• नेटिव सैनिटाइज़ेशन उपलब्ध न होने पर, DOMPurify जैसी जांची-परखी लाइब्रेरी का इस्तेमाल करने के बजाय, अनुमति वाली सूची में शामिल DOMParser सैनिटाइज़र को खुद लिखना. इन्हें setHTML() फ़ॉलबैक के तौर पर या भरोसेमंद टाइप की नीति के तहत लिखा जा सकता है.
• हर पेज लोड पर DOMPurify को ईगरली बंडल करना. इसके बजाय, नेटिव setHTML() का इस्तेमाल करना और DOMPurify को सिर्फ़ फ़ॉलबैक के तौर पर लेज़ी-लोड करना.
• सिंक एनफ़ोर्समेंट को कमज़ोर करने वाली, अनुमति देने वाली (input) => input पासथ्रू ट्रस्टेड टाइप नीतियों को रजिस्टर करना.
• SHA-256 हैश के साथ इनलाइन स्क्रिप्ट को लॉक करने के बजाय, स्टैटिक पेजों पर भरोसेमंद टाइप को होस्ट-अनुमति वाली सूची script-src 'self' सीएसपी के साथ जोड़ना.
• नॉनस-आधारित script-src कॉन्टेंट की सुरक्षा के लिए बनी नीतियों को कॉन्फ़िगर करते समय, 'strict-dynamic' और 'report-sample' को शामिल नहीं किया गया है.

10. सुरक्षा: पासकी से साइन-इन करना, फिर से पुष्टि करना, और क्रेडेंशियल की लाइफ़साइकल

पासकी से उपयोगकर्ताओं की सुरक्षा बेहतर होती है और कारोबारों के लिए साइन-इन कन्वर्ज़न बढ़ते हैं. हालांकि, इन्हें लागू करना मुश्किल होता है. भले ही, एजेंट की मदद ली जाए.

WebAuthn में सीरियलाइज़ेशन, क्षमता का पता लगाने, और सिग्नल देने वाले खास एपीआई होते हैं. हमारे आकलन में, बिना गाइडेंस वाले मॉडल इन एपीआई को पूरी तरह से मिस कर देते हैं. अगर किसी एआई मॉडल से पासकी की मदद से साइन इन करने, उसे मैनेज करने या फिर से पुष्टि करने की सुविधा जोड़ने के लिए कहा जाता है, तो वह अक्सर मैन्युअल बाइट-एन्कोडिंग हेल्पर लिखता है, मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) पर क्षमता की जांच को छोड़ देता है या क्रेडेंशियल को पासवर्ड मैनेजर के साथ सिंक नहीं करता है:

• atob() और btoa() Base64URL कन्वर्ज़न हेल्पर को मैन्युअल तरीके से रोल करना. ऐसा मुख्य पाथ या रिडंडेंट फ़ॉलबैक बॉयलरप्लेट के तौर पर किया जाता है. इसके लिए, parseCreationOptionsFromJSON(), parseRequestOptionsFromJSON(), और credential.toJSON() जैसे पहले से मौजूद सीरियलाइज़ेशन के तरीकों पर भरोसा नहीं किया जाता.
• साइन-इन के दौरान PublicKeyCredential.signalUnknownCredential() को शामिल न करना, जब सर्वर किसी अनजान क्रेडेंशियल आईडी की रिपोर्ट करता है. इससे उपयोगकर्ताओं के पासवर्ड मैनेजर में, मिटाई गई या रद्द की गई पासकी रह जाती हैं.
• पासकी बनाने और उसे मैनेज करने का यूज़र इंटरफ़ेस (यूआई) रेंडर करने से पहले, PublicKeyCredential.getClientCapabilities() को स्किप किया जा रहा है.
• पासकी से फिर से पुष्टि करने के अनुरोध शुरू करते समय, AbortController और AbortSignal को शामिल नहीं किया गया.
• साइन-इन के लिए अनुरोधों को आसान बनाने के लिए, uiMode:"immediate" के बजाय ऑरिजिन-ट्रायल mediation:"immediate" विकल्प पास करना.

इन कमियों को दूर करना

ये 10 विषय, पूरी सूची का एक छोटा सा हिस्सा हैं. हमें उम्मीद है कि समय के साथ, जानकारी की कमी वाले विषयों में बदलाव होगा. मॉडल बेहतर होते जाएंगे और वेब प्लैटफ़ॉर्म भी बेहतर होता जाएगा.

अच्छी बात यह है कि मॉडर्न वेब गाइडेंस इन सभी कमियों को दूर करता है. साथ ही, आने वाले समय में प्लैटफ़ॉर्म पर होने वाले नए बदलावों के साथ-साथ, यह भी बेहतर होता जाएगा.

मॉडर्न वेब गाइडेंस का इस्तेमाल शुरू करने के लिए, यह कमांड चलाएं या अपने एजेंट के प्लग इन मार्केटप्लेस में इसे खोजें:

npx modern-web-guidance@latest install

क्या आपने मॉडल को वेब डेवलपमेंट से जुड़े अन्य टास्क गलत तरीके से करते हुए देखा है? हम इसके बारे में जानना चाहते हैं. Modern Web Guidance की GitHub रिपॉज़िटरी में कोई समस्या बताएं या प्रोजेक्ट में योगदान देकर, अन्य डेवलपर के लिए इन समस्याओं को हल करने में हमारी मदद करें.