मैंने Next.js 16 के साथ तीन महंगी ऑथ (auth) गलतियाँ कीं
मैंने तीन अलग-अलग प्रोजेक्ट्स में proxy.ts matcher के साथ गड़बड़ी कर दी।
सबसे बुरा हिस्सा? कोई एरर नहीं थे। कोई वार्निंग नहीं। कोई लॉग्स नहीं। सब कुछ तब तक एकदम सही लग रहा था जब तक सुरक्षा में खामियां (security holes) सामने नहीं आईं।
Next.js 16 ने middleware.ts को proxy.ts में बदल दिया है। यह सिर्फ नाम का बदलाव नहीं है। यह रिक्वेस्ट हैंडल करने के तरीके में एक बुनियादी बदलाव है।
अपनी ऑथ (auth) को खराब होने से बचाने के लिए आपको यह जानना ज़रूरी है।
The New Rules Middleware भ्रमित करने वाला था। डेवलपर्स इसका उपयोग डेटाबेस कॉल्स और भारी लॉजिक के लिए करते थे। यह उसका काम नहीं है।
Proxy नेटवर्क बाउंड्री पर स्थित होता है। यह आपके रूट्स तक पहुँचने से पहले ही रिक्वेस्ट को इंटरसेप्ट (intercept) कर लेता है।
- यह डिफ़ॉल्ट रूप से Node.js पर चलता है, Edge runtime पर नहीं।
- आपको पूरा crypto सपोर्ट मिलता है।
- आप बिना किसी वर्कअराउंड (workaround) के किसी भी स्टैंडर्ड JWT लाइब्रेरी का उपयोग कर सकते हैं।
The Silent Failure
यदि आप codemod का उपयोग किए बिना Next.js को अपग्रेड करते हैं, तो आपकी पुरानी middleware.ts फ़ाइल आपके प्रोजेक्ट में रह सकती है। यह TypeScript चेक पास कर लेगी। यह ठीक से कंपाइल भी हो जाएगी।
लेकिन यह कुछ भी नहीं करेगी।
आपके रीडायरेक्ट (redirects) काम नहीं करेंगे। आपकी ऑथ (auth) नहीं चलेगी। आपका ऐप चुपचाप सुरक्षा लेयर (security layer) को बायपास कर देगा।
इन तीन चीज़ों को मैन्युअल रूप से चेक करें:
- सुनिश्चित करें कि
proxy.tsआपके प्रोजेक्ट रूट पर है। - सुनिश्चित करें कि एक्सपोर्ट किए गए फंक्शन का नाम
proxyहै,middlewareनहीं। - पुरानी
middleware.tsफ़ाइल को पूरी तरह से हटा दें।
The Matcher Trap अधिकांश ऑथ सेटअप matcher कॉन्फ़िगरेशन में टूट जाते हैं। यदि आप स्टैटिक फ़ाइलों को एक्सक्लूड (exclude) नहीं करते हैं, तो proxy हर CSS और JS फ़ाइल पर चलता है। इससे एसेट्स (assets) पर अनंत रीडायरेक्ट लूप (infinite redirect loops) बन जाते हैं।
एक्सक्लूड करने के लिए negative lookahead का उपयोग करें:
- _next/static
- _next/image
- favicons और sitemaps
- image extensions (png, jpg, svg)
चेतावनी: केवल हेडर्स (Headers) पर भरोसा न करें यहीं पर मैं मात खा गया।
Proxy रिक्वेस्ट पर x-user-id जैसे हेडर्स सेट करता है। आपके Server Components इन्हें headers() के ज़रिए पढ़ते हैं।
यदि आपके matcher में कोई कमी (gap) रह जाती है, तो एक यूजर अपना खुद का x-user-id हेडर भेज सकता है। Server Component यह अंतर नहीं बता सकता कि हेडर proxy द्वारा सेट किया गया है या क्लाइंट द्वारा भेजा गया है।
एक हमलावर (attacker) किसी अनमैच्ड रूट (unmatched route) पर यूजर आईडी को स्पूफ (spoof) कर सकता है। हो सकता कि वे डेटा न देख पाएं, लेकिन वे ऐसी अनुमतियाँ (permissions) प्राप्त कर सकते हैं जो उनके पास नहीं होनी चाहिए।
The Fix: Proxy आपका तेज़ गेट (gate) है। यह एज (edge) पर भारी काम संभालता है।
लेकिन आपको अपने Server Components के अंदर JWT को फिर से वेरीफाई (verify) करना चाहिए।
- प्रॉक्सी अधिकांश दुर्भावनापूर्ण तत्वों को तेज़ी से रोक देती है।
- यदि मैचर विफल हो जाता है, तो सर्वर कंपोनेंट चेक उस कमी को पूरा कर देता है।
रेडंडेंसी ही सुरक्षा है।