HTTP सुरक्षा हेडर: CSP, HSTS और बाकी हेडर की पूरी गाइड

किसी वेबसाइट की सुरक्षा का बड़ा हिस्सा उसके कोड में रहता है, पर HTTP रिस्पॉन्स हेडर का एक छोटा समूह तय करता है कि कोड पहुँचने के बाद ब्राउज़र उसके साथ क्या करने को तैयार है। यही अंतर है एक इंजेक्ट किए गए <script> के चलने और उसी स्क्रिप्ट को चलाने से ब्राउज़र के इनकार में; और बिना एन्क्रिप्शन वाले HTTP पर हुई पहली यात्रा और उस यात्रा में, जो पता-पट्टी छोड़ने से पहले ही HTTPS पर उठा दी जाती है।

और इन्हें लागू करना असामान्य रूप से सस्ता है। हेडर कॉन्फ़िगरेशन हैं, कोड नहीं: इनमें से अधिकतर आपके वेब सर्वर, CDN या फ़्रेमवर्क में एक पंक्ति हैं, और एक ही बार में हर रिस्पॉन्स पर लागू हो जाते हैं। यह गाइड बताती है कि हर हेडर क्या करता है, कौन से अपनी कीमत वसूल करते हैं, अपनी ही साइट तोड़े बिना Content-Security-Policy कैसे लागू करें, और यह कैसे जाँचें कि आप आज क्या भेज रहे हैं।

सुरक्षा हेडर क्यों मायने रखते हैं

हेडर ब्राउज़र को दिया गया निर्देश है, और उपयोगकर्ता की मशीन पर उसे लागू करा सकने वाला एकमात्र पक्ष ब्राउज़र ही है। इससे हेडर बचाव की वह दूसरी पंक्ति बन जाते हैं जो तब भी टिकती है जब उससे पहले कुछ गड़बड़ हो चुका हो:

• ये पहले से हो चुकी गलतियों को सीमित कर देते हैं। Content-Security-Policy किसी XSS छिद्र को ठीक नहीं करती, पर इंजेक्ट किए गए स्क्रिप्ट को चलने से या कुछ भी वापस भेजने से रोक सकती है।
• ये पूरे-पूरे हमले-वर्ग बंद कर देते हैं। क्लिकजैकिंग, MIME भ्रम और HTTP पर लौटना आपके कोड की खामियाँ नहीं हैं; ये ब्राउज़र के वे व्यवहार हैं जिनसे आपको स्पष्ट रूप से बाहर निकलना पड़ता है।
• ये चुपचाप होने वाला डेटा रिसाव रोकते हैं। रेफ़रर नीति के बिना किसी निजी पेज की पूरी URL हर उस तीसरे पक्ष तक पहुँचती है जिससे आप कोई छवि लोड करते हैं।
• ऑडिटर सबसे पहले इन्हें देखता है। गायब हेडर हर स्वचालित स्कैन, सुरक्षा प्रश्नावली और विक्रेता समीक्षा में दिख जाते हैं, क्योंकि यह सबसे सस्ता संभव निष्कर्ष है।

पेच यह है कि इन्हें लगभग-सही कर देना आसान है। unsafe-inline वाली CSP बहुत कम रोकती है; एक दिन की अवधि वाला HSTS हेडर लगभग किसी को नहीं बचाता। मूल्य विवरण में है।

सबसे ज़्यादा मायने रखने वाले हेडर

छह हेडर लगभग पूरा उपयोगी काम कर देते हैं। बाकी या पुराने पड़ चुके हैं, या बहुत सीमित दायरे के हैं, या अब बेहतर विकल्पों से बदल दिए गए हैं।

नीचे से शुरू करें। चारों सस्ते हेडर एक-एक पंक्ति के हैं और लगभग कभी कुछ नहीं तोड़ते, इसलिए इन्हें आज ही भेजना ठीक रहेगा; योजना जिसकी ज़रूरत है, वह CSP है।

Content-Security-Policy

CSP एक अनुमति-सूची है जो ब्राउज़र को बताती है कि हर तरह का संसाधन कहाँ से आ सकता है। एक ठीक-ठाक सख़्त नीति इस तरह दिखती है:

default-src 'self'; script-src 'self' 'nonce-r4nd0m'; style-src 'self'; img-src 'self' data:; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; object-src 'none'

इसे निर्देश दर निर्देश पढ़ें। default-src 'self' पूर्व-निर्धारित विकल्प है: जिसका स्पष्ट उल्लेख नहीं, वह केवल आपके ही मूल से लोड हो सकता है। script-src सबसे अहम है, क्योंकि हमलावर चलाना स्क्रिप्ट ही चाहता है। frame-ancestors 'none' कहता है कि कोई और साइट आपके पेज को iframe में नहीं रख सकती, और यह X-Frame-Options का आधुनिक विकल्प है। object-src 'none' और base-uri 'self' दो पुराने चोर-रास्ते बंद कर देते हैं, जिन्हें बंद करने में कोई लागत नहीं।

दो मान तय करते हैं कि आपकी नीति असली है या नहीं। script-src में 'unsafe-inline' किसी भी इनलाइन <script> की अनुमति देता है, उस स्क्रिप्ट की भी जो हमलावर ने डाली है, और यही वह चीज़ है जिसे रोकने के लिए CSP बनी है। 'unsafe-eval' eval() और उसके सगे-संबंधियों की अनुमति देता है। इनमें से किसी एक वाली नीति भी गैर-स्क्रिप्ट निर्देशों के लिए उपयोगी है, पर वह आपको XSS से नहीं बचा रही।

रास्ता है nonce या hash। nonce हर रिस्पॉन्स के लिए बनाया गया यादृच्छिक मान है, जो हेडर और हर वैध <script nonce="..."> दोनों पर लगाया जाता है; ब्राउज़र केवल वही स्क्रिप्ट चलाता है जिन पर वह मान है, और इंजेक्ट किया स्क्रिप्ट उसका अनुमान नहीं लगा सकता। जो स्क्रिप्ट कभी बदलते नहीं, उनके लिए hash उसी तरह काम करते हैं। यदि आपका फ़्रेमवर्क इनलाइन स्क्रिप्ट बनाता है, तो लगभग निश्चित रूप से उसमें nonce की सुविधा पहले से है; उसे चालू करना आमतौर पर एक कॉन्फ़िग विकल्प भर है।

Strict-Transport-Security

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

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age सेकंड में होता है; एक वर्ष आम लक्ष्य है, और कुछ महीनों से कम से बहुत कम लाभ मिलता है। includeSubDomains नियम को हर सबडोमेन तक बढ़ा देता है, जो इसे प्रभावी बनाता है और जिसे पहले जाँच लेना भी ज़रूरी है: जो भी सबडोमेन अब भी HTTP पर है, वह टूट जाएगा। preload उस सूची में शामिल होने का अनुरोध करता है जो ब्राउज़र के साथ ही आती है, जिससे पहली यात्रा भी सुरक्षित रहती है।

HSTS को कठिनाई से पलटने वाली चीज़ मानें। जिस ब्राउज़र ने एक वर्ष की नीति देख ली, वह उसे एक वर्ष लागू करेगा, आप बाद में कुछ भी भेजें। इसे छोटे max-age के साथ लागू करें, पुष्टि करें कि कुछ टूटा नहीं, फिर बढ़ाएँ। और चूँकि HSTS का मतलब तभी है जब पीछे का प्रमाणपत्र वैध हो, लंबी नीति पर टिकने से पहले SSL प्रमाणपत्र जाँचकर्ता से प्रमाणपत्र और उसकी समाप्ति जाँच लें।

छोटे हेडर

ये चार एक-एक पंक्ति के हैं और इन पर विवाद कम ही होता है:

• X-Content-Type-Options: nosniff — ब्राउज़र को किसी रिस्पॉन्स का प्रकार उसकी सामग्री से अनुमान लगाने से रोकता है। इसके बिना, .txt के रूप में अपलोड की गई फ़ाइल स्क्रिप्ट बनकर चल सकती है, यदि ब्राउज़र को लगे कि वह वैसी दिखती है।
• Referrer-Policy: strict-origin-when-cross-origin — पूरी URL आपके ही मूल को भेजता है, अन्य HTTPS साइटों को केवल मूल, और HTTP पर उतरने पर कुछ भी नहीं। यह आधुनिक पूर्व-निर्धारित विकल्प है और निजी पथ तथा प्रश्न-डेटा को तीसरे पक्ष तक जाने से रोकता है।
• Permissions-Policy: camera=(), microphone=(), geolocation=() — उन डिवाइस सुविधाओं को बंद कर देता है जिन्हें आपकी साइट उपयोग नहीं करती, आपके पेज के लिए और आपके जोड़े हुए किसी भी कंटेंट के लिए।
• Cross-Origin-Opener-Policy: same-origin — उन पेजों के साथ विंडो-संबंध काट देता है जिन्हें आप खोलते हैं या जो आपको खोलते हैं, जिससे विंडो-पार हमलों का एक पूरा परिवार रुक जाता है, और यह ब्राउज़र की कुछ अलगाव सुविधाओं की पूर्व-शर्त भी है।

पुराने ब्राउज़रों के लिए X-Frame-Options: DENY अब भी सूची में जगह रखता है, पर आपकी CSP में frame-ancestors उसकी जगह ले लेता है और अधिक लचीला है। दोनों भेजें; इनमें टकराव नहीं होता।

CSP सुरक्षित तरीके से कैसे लागू करें

अनुमान से लिखी CSP आपकी ही साइट की किसी ज़रूरत को रोक देगी। «पहले रिपोर्ट» का रास्ता इसे पूरी तरह टाल देता है:

1. चारों सस्ते हेडर आज ही भेजें। nosniff, एक रेफ़रर नीति, एक अनुमति नीति, और छोटे max-age वाला HSTS। आम तौर पर इनमें से कोई चालू साइट को नहीं तोड़ता।
2. Content-Security-Policy-Report-Only जोड़ें। वाक्य-रचना वही, पर ब्राउज़र उल्लंघनों को रोकने के बजाय केवल रिपोर्ट करता है। आपकी साइट ठीक पहले जैसी ही चलती है।
3. एक-दो सप्ताह रिपोर्ट जुटाएँ। वे हर उस तीसरे-पक्ष स्क्रिप्ट, फ़ॉन्ट, एनालिटिक्स एंडपॉइंट और इनलाइन हैंडलर का नाम बता देंगी जिन्हें आप भूल गए थे। लोग यही चरण छोड़ देते हैं, और यही वह चरण है जो बाकी सब आसान बना देता है।
4. जब तक रिपोर्ट शांत न हो जाएँ, कसते जाएँ। जिन स्रोतों की सच में ज़रूरत है उन्हें जोड़ें, और जिनकी नहीं, उन्हें हटा दें। किसी एक रिपोर्ट को चुप कराने के लिए निर्देश को * तक चौड़ा करने के लालच से बचें।
5. लागू करने वाले मोड पर जाएँ। हेडर का नाम बदलकर Content-Security-Policy करें। जब आगे किसी सख़्त नीति का परीक्षण करना हो, तो केवल-रिपोर्ट वाला संस्करण साथ बनाए रखें।
6. unsafe-inline सबसे अंत में हटाएँ। असली काम यही है: इनलाइन स्क्रिप्ट को फ़ाइलों में ले जाना या उन्हें nonce देना। इससे पहले का सब तैयारी है; XSS रोकने वाला चरण यही है।

एक व्यावहारिक बात: हेडर प्रति रिस्पॉन्स होते हैं, इसलिए उन्हें किनारे पर सेट करें — अपने CDN, रिवर्स प्रॉक्सी या फ़्रेमवर्क मिडलवेयर में — पेज-दर-पेज नहीं। एक ही जगह सेट करना यह पक्का करने का एकमात्र तरीका भी है कि आपके त्रुटि पेज और रीडायरेक्ट भी उन्हें साथ रखें, और वहीं वे आमतौर पर गायब रहते हैं।

जो हेडर भेजना बंद कर सकते हैं

कुछ सलाहें बुरी तरह पुरानी पड़ चुकी हैं, और मरा हुआ हेडर भेजना हानिरहित नहीं है: यह बाइट जोड़ता है और ऑडिट को पूरा दिखा देता है, जबकि वह पूरा नहीं है।

• X-XSS-Protection — जिन ब्राउज़र फ़िल्टरों को यह नियंत्रित करता था, वे अब नहीं हैं। किसी भी वर्तमान ब्राउज़र में यह कुछ नहीं करता, और पुराने mode=block मान ने एक समय अपनी ही समस्याएँ पैदा की थीं। इसे हटा दें और CSP पर भरोसा करें।
• Public-Key-Pins — HPKP ब्राउज़रों से हटा दिया गया है। इससे अपने ही डोमेन से बाहर हो जाना आसान था, इसीलिए इसे छोड़ दिया गया।
• Expect-CT — प्रमाणपत्र पारदर्शिता अब डिफ़ॉल्ट रूप से लागू होती है, इसलिए यह हेडर अनावश्यक है।
• Feature-Policy — इसका नाम बदलकर Permissions-Policy हो गया है, और वाक्य-रचना भी अलग है। नया भेजें; पुराना केवल तब रखें जब किसी बहुत पुराने परिवेश को समर्थन देना ज़रूरी हो।

दूसरी ओर, हटाने लायक एक चीज़ वह जानकारी है जो आप खुद दे देते हैं: आपके फ़्रेमवर्क का ठीक-ठीक संस्करण बताने वाला Server या X-Powered-By हेडर हमलावर को बता देता है कि पहले कौन से एक्सप्लॉइट आज़माए जाएँ। यह कोई भेद्यता नहीं है, पर इसे प्रकाशित करने की कोई वजह भी नहीं।

अपने हेडर कैसे जाँचें

हेडर सार्वजनिक होते हैं, इसलिए किसी भी साइट का विन्यास जाँचने में सेकंड लगते हैं:

1. curl -I https://example.com। HEAD अनुरोध पेज डाउनलोड किए बिना हर रिस्पॉन्स हेडर छाप देता है। रीडायरेक्ट के बजाय अंतिम URL देखने के लिए -L जोड़ें।
2. ब्राउज़र का नेटवर्क पैनल। डेवलपर टूल खोलें, पेज फिर लोड करें, मुख्य दस्तावेज़ चुनें और रिस्पॉन्स हेडर वाला भाग पढ़ें। कंसोल हर CSP उल्लंघन को उस निर्देश के साथ दर्ज करता है जिसने उसे रोका, और किसी नीति की डीबगिंग का यही सबसे तेज़ तरीका है।
3. परिणाम को आँकने वाला जाँचकर्ता। हमारा सुरक्षा हेडर जाँचकर्ता किसी URL को लाकर बताता है कि कौन से हेडर मौजूद हैं, कौन से गायब हैं, और कहाँ कोई मौजूद हेडर दिखने से कमज़ोर है।

केवल होमपेज से आगे जाँचें। हेडर अक्सर मुख्य ऐप्लिकेशन पर सेट होते हैं, पर स्थिर फ़ाइल होस्ट, त्रुटि पेज, API सबडोमेन या www से मुख्य डोमेन भेजने वाले रीडायरेक्ट पर नहीं। इसी दौरान यह भी पुष्टि कर लें कि रीडायरेक्ट की कड़ी सही है; HTTP स्टेटस कोड संदर्भ बताता है कि स्थायी बदलाव पर कौन सा कोड ठीक रहता है।

सिंटैक्स याद किए बिना नीति लिखने के लिए हमारे CSP जनरेटर से शुरू करें, जो उसे कमज़ोर करने वाली सेटिंग भी बताता है।

बचने योग्य आम गलतियाँ

• script-src में unsafe-inline वाली CSP। यह अधिकतर स्वचालित जाँचों में पास हो जाती है और लगभग कोई XSS नहीं रोकती। nonce या hash का उपयोग करें।
• एक रिपोर्ट ठीक करने के लिए निर्देश को * कर देना। इसके बजाय वही एक मूल जोड़ें; * पूरे निर्देश को छोड़ देने जैसा है।
• पहले ही दिन लंबे max-age वाला HSTS। प्रकाशित अवधि तक यह व्यवहार में अपरिवर्तनीय है। छोटे से शुरू करें।
• सबडोमेन जाँचे बिना includeSubDomains। जो कुछ अब भी HTTP पर है, भीतरी औज़ार भी, वह लोड होना बंद कर देता है।
• ऐप पर हेडर, किनारे पर नहीं। त्रुटि पेज, रीडायरेक्ट और फ़ाइल होस्ट असुरक्षित रह जाते हैं, और हमलावर इन्हीं रिस्पॉन्स तक पहुँचते हैं।
• एक ही हेडर दो बार सेट करना। दो CSP हेडर जुड़ते नहीं, उनका प्रतिच्छेदन होता है, इसलिए परिणाम दोनों से सख़्त होता है और आमतौर पर कुछ तोड़ देता है; X-Frame-Options के दो विरोधी मान पूरी तरह अनदेखे भी किए जा सकते हैं।
• अब भी X-XSS-Protection भेजकर काम पूरा मान लेना। मरा हुआ हेडर रिपोर्ट में झूठा दिलासा देता है।
• केवल-रिपोर्ट मोड से कभी आगे न बढ़ना। जिन रिपोर्टों पर आप कार्रवाई नहीं करते, वे किसी को नहीं बचातीं।

अपने हेडर जाँचें

सुरक्षा हेडर वेब पर उपलब्ध सबसे अच्छा सुरक्षा-और-मेहनत अनुपात देते हैं: इनमें चार एक-एक पंक्ति के हैं, और पाँचवाँ, CSP, मुख्य रूप से यह मामला है कि कुछ भी लागू करने से पहले आप अपने ही उल्लंघन रिपोर्ट सुन लें। पहले देखें कि आपकी साइट आज क्या भेजती है, सस्ते हेडर तुरंत जोड़ें, फिर केवल-रिपोर्ट मोड में CSP लगाएँ और उसे बताने दें कि आपकी नीति में क्या होना चाहिए।

संबंधित टूल और गाइड:

• सुरक्षा हेडर जाँचकर्ता — देखें कि कोई URL कौन से हेडर भेजता है और कौन से गायब हैं।
• SSL प्रमाणपत्र जाँचकर्ता — अपनी HSTS नीति के पीछे का प्रमाणपत्र जाँचें।
• HTTP स्टेटस कोड — पक्का करें कि आपका HTTPS रीडायरेक्ट सही कोड लौटाता है।
• DNS लुकअप: पूरी गाइड — आपकी नीति के हर होस्टनेम के पीछे के रिकॉर्ड।

अक्सर पूछे जाने वाले प्रश्न