खुद को लॉक आउट किए बिना HSTS कैसे सेट अप करें

HSTS सरल है, जब तक कि वह सरल नहीं रहता

HTTP Strict Transport Security, जिसे आम तौर पर HSTS कहा जाता है, browsers से कहता है: “इस site के लिए, हमेशा HTTPS का उपयोग करें.” जब कोई browser valid HTTPS connection पर header प्राप्त कर लेता है, तो वह आपके बताए हुए समय तक इस rule को याद रखता है.

यह उपयोगी है. यह protocol downgrade attacks को रोकता है, अनजाने insecure requests को कम करता है, और उस अजीब स्थिति से बचाता है जहाँ user example.com टाइप करता है और redirect होने से पहले थोड़ी देर के लिए plain HTTP को छू लेता है.

यह sticky भी है. यदि आप गलत HSTS policy प्रकाशित कर देते हैं, तो browsers आपके server से header हटाने के बहुत बाद तक उसे लागू रख सकते हैं. इसी तरह teams खुद को lock out कर लेती हैं: ठीक-ठीक अपने admin panel से नहीं, बल्कि users के browsers, subdomains, staging systems, legacy endpoints, और भूली हुई services से, जो forced HTTPS के लिए तैयार नहीं हैं.

लक्ष्य HSTS से बचना नहीं है. लक्ष्य इसे migration की तरह deploy करना है, toggle की तरह नहीं.

HSTS header वास्तव में क्या करता है

एक typical HSTS header ऐसा दिखता है:

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

इसके तीन महत्वपूर्ण हिस्से हैं:

• max-age: कितनी देर तक, seconds में, browser को इस host के लिए HTTPS enforce करना चाहिए.
• includeSubDomains: क्या rule हर subdomain पर भी लागू होगा.
• preload: यह signal कि आप domain को browser preload lists में शामिल कराना चाहते हैं.

Browser इस header पर तभी भरोसा करता है जब वह इसे valid HTTPS पर प्राप्त करता है. यदि certificate invalid, expired, या mismatched है, तो browser को उस response से नई HSTS policy स्वीकार नहीं करनी चाहिए.

Policy store हो जाने के बाद, भविष्य में http://example.com पर जाने की कोशिशों को request भेजे जाने से पहले browser https://example.com में upgrade कर देता है. यही privacy win है: insecure request device से बाहर ही नहीं जाती.

जिन lockout scenarios से बचना है

अधिकतर HSTS failures main website के कारण नहीं होते. वे edges पर होते हैं.

1. कोई भूला हुआ subdomain HTTPS-ready नहीं है

includeSubDomains व्यवस्थित लगता है, लेकिन यह पूर्ण है. यदि आप इसे example.com पर set करते हैं, तो यह इन पर लागू होता है:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• उस domain के अंतर्गत कुछ भी और

यदि इनमें से कोई host valid HTTPS serve नहीं कर सकता, तो जिन users के पास HSTS policy cached है वे HTTP पर उन्हें access नहीं कर पाएँगे.

2. Certificate expire हो जाता है

HSTS के बिना, users कभी-कभी certificate warnings को click through कर देते हैं. यह अच्छी security practice नहीं है, लेकिन ऐसा होता है.

HSTS के साथ, modern browsers उस host के लिए certificate errors को आसानी से bypass करने की अनुमति नहीं देते. यही इसका उद्देश्य है. इसका मतलब यह भी है कि certificate renewal boring, monitored, और tested होना चाहिए.

3. Staging या internal tools production domain के अंतर्गत रहते हैं

Internal tools को *.example.com के अंतर्गत रखना तब दर्दनाक हो सकता है जब parent domain includeSubDomains का उपयोग करता है. यदि वे tools self-signed certificates, private certificate authorities, पुराने TLS configurations, या बिल्कुल HTTPS नहीं उपयोग करते, तो HSTS उस shortcut को उजागर कर देगा.

इसी वजह से कई teams internal और experimental systems को एक अलग domain के अंतर्गत रखती हैं, जिसकी अपनी security policy होती है.

4. Preload को routine checkbox माना जाता है

HSTS preload सिर्फ एक और directive नहीं है. इसका मतलब है कि आपका domain browsers के अंदर HTTPS-only के रूप में ship हो सकता है, इससे पहले कि कोई user आपकी site पर आया हो.

यह “first visit” gap को बंद करता है, लेकिन इसे undo करना कहीं कठिन है. Browser release cycles पर निर्भर करते हुए, preload lists से removal users तक पहुँचने में weeks या months ले सकता है. Preload stable, mature domains के लिए उपयुक्त है. यह उस site के लिए उपयुक्त नहीं है जो अभी भी अपनी subdomain inventory खोज रही है.

एक सुरक्षित rollout plan

Step 1: आपके नियंत्रण में हर hostname का audit करें

includeSubDomains set करने से पहले, domain के अंतर्गत हर hostname की list बनाएँ. DNS records एक शुरुआत हैं, लेकिन पूरी कहानी नहीं. CDN configurations, hosting dashboards, email-related hostnames, पुराने marketing tools, storage buckets, और internal documentation जाँचें.

हर hostname के लिए उत्तर दें:

• क्या यह HTTP, HTTPS, या दोनों serve करता है?
• क्या HTTPS certificate valid है और automatically renewed होता है?
• क्या यह HTTP को HTTPS पर cleanly redirect करता है?
• क्या यह public होना चाहिए?
• क्या इसकी अभी भी जरूरत है?

यदि आपकी team के पास पहले से production header debugging की आदतें हैं, तो यह redirect और header checks के साथ स्वाभाविक रूप से fit होता है. हमने उस workflow को production में redirects और HTTP headers debug करने के लिए एक छोटे toolkit में cover किया है.

Step 2: HSTS जोड़ने से पहले HTTPS ठीक करें

HSTS टूटी हुई HTTPS setup को secure नहीं बनाता. यह केवल HTTPS को mandatory बनाता है.

इसे enable करने से पहले verify करें:

• TLS certificates सही hostnames को cover करते हैं.
• Certificates automatically renew होते हैं.
• HTTP जहाँ संभव हो, single clean hop के साथ HTTPS पर redirect होता है.
• Canonical host redirects consistent हैं, उदाहरण के लिए non-www से www, या उसका उल्टा.
• Application assets insecure http:// URLs पर depend नहीं करते.

Mixed content पहले जितना common नहीं रहा, लेकिन यह अभी भी पुराने CMS themes, analytics snippets, embedded media, और hard-coded image paths में दिखाई देता है.

Step 3: बहुत छोटे max-age से शुरू करें

एक साल से शुरू न करें. पाँच मिनट से शुरू करें:

Strict-Transport-Security: max-age=300

इसे केवल उस hostname पर deploy करें जिसे आप test कर रहे हैं, आम तौर पर canonical production website. अभी includeSubDomains को छोड़ दें.

फिर real browsers और command-line requests से test करें:

curl -I https://example.com

आपको ठीक एक Strict-Transport-Security header दिखना चाहिए. App server और CDN से duplicate HSTS headers confusion का आम source हैं. Browsers आम तौर पर effective policy apply कर देते हैं, लेकिन incident debug कर रहे humans को ambiguity की जरूरत नहीं होती.

Step 4: धीरे-धीरे बढ़ाएँ

यदि कुछ नहीं टूटता, तो duration को stages में बढ़ाएँ:

Strict-Transport-Security: max-age=86400

फिर:

Strict-Transport-Security: max-age=604800

फिर शायद:

Strict-Transport-Security: max-age=2592000

एक practical schedule है:

• 5 minutes
• 1 day
• 1 week
• 1 month
• 6 months या 1 year

जल्दबाजी के लिए कोई prize नहीं है. Staged rollout का पूरा उद्देश्य आपके monitoring, support inbox, और edge cases को इतना समय देना है कि वे बता सकें कि आपकी checklist से क्या छूट गया.

Step 5: includeSubDomains केवल वास्तविक audit के बाद जोड़ें

जब हर public subdomain HTTPS-ready हो जाए, तब आप इस पर विचार कर सकते हैं:

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

यह conservative होने का क्षण है. यदि किसी एक legacy service को अभी भी HTTP चाहिए, तो parent domain में includeSubDomains न जोड़ें. या तो उस service को migrate करें, उसे किसी दूसरे domain पर move करें, या स्वीकार करें कि आपकी HSTS policy को फिलहाल narrower रहना होगा.

Security headers को reality reflect करनी चाहिए. उन्हें उस infrastructure के motivational posters की तरह उपयोग नहीं करना चाहिए, जिसे आप बाद में पाने की उम्मीद रखते हैं.

Step 6: Preload को अलग project की तरह मानें

Preload पर केवल तब विचार करें जब नीचे दी गई सभी बातें सच हों:

• Domain और सभी subdomains valid HTTPS support करते हैं.
• HTTP, HTTPS पर redirect होता है.
• HSTS header कम से कम 31536000 seconds का max-age उपयोग करता है.
• Header में includeSubDomains शामिल है.
• Header में preload शामिल है.
• आपको भरोसा है कि domain के अंतर्गत कहीं भी plain HTTP की जरूरत नहीं पड़ेगी.

Preload-ready header ऐसा दिखता है:

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

Preload list में submit करना long-term commitment है. यदि site एक campaign microsite, temporary product domain, या unclear ownership boundaries वाला domain है, तो इसे छोड़ दें.

Configuration examples

Nginx

always का उपयोग करें ताकि header error responses पर भी भेजा जाए:

add_header Strict-Transport-Security "max-age=300" always;

Rollout stable होने के बाद:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache

mod_headers enabled होने पर:

Header always set Strict-Transport-Security "max-age=300"

बाद में:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN या edge platform

यदि आपका CDN response headers set करता है, तो HSTS को एक ही जगह manage करना बेहतर है. जब तक आपके पास बहुत स्पष्ट कारण न हो, origin पर एक policy और edge पर दूसरी set न करें.

यह भी जाँचें कि CDN headers को redirects, cached errors, और custom error pages पर apply करता है या नहीं. Production site केवल उसका 200 OK response नहीं होती.

HSTS को safely undo कैसे करें

यदि आपको HSTS disable करना हो, तो भेजें:

Strict-Transport-Security: max-age=0

लेकिन एक catch है: उस header को receive करने के लिए browser को valid HTTPS पर site तक successfully पहुँचना होगा. यदि HTTPS itself broken है, तो cached HSTS policy वाले users उस instruction को fetch नहीं कर सकते जो उसे clear करेगा.

इसलिए usual recovery order है:

1. Valid HTTPS restore करें.
2. Strict-Transport-Security: max-age=0 serve करें.
3. Returning users को इसे receive करने के लिए पर्याप्त समय तक इसे place में रखें.
4. Incident resolve होने के बाद header remove या replace करें.

यदि domain preloaded है, तो max-age=0 serve करना new browser profiles के लिए पर्याप्त नहीं है. आपको preload list से removal request करना होगा और browser updates के through उस change के ship होने तक wait करना होगा.

Ship करने से पहले testing checklist

max-age बढ़ाने या includeSubDomains जोड़ने से पहले इस checklist का उपयोग करें:

• Canonical HTTPS URL valid certificate return करता है.
• HTTP, HTTPS पर redirect होता है.
• केवल एक HSTS header है.
• Header redirects और error responses पर जहाँ appropriate हो, दिखाई देता है.
• सभी public subdomains के पास valid HTTPS है.
• Certificate renewal monitored है.
• कोई critical internal system उसी parent domain के अंतर्गत HTTP पर depend नहीं करता.
• Preload पर explicitly चर्चा हुई है, habit से नहीं जोड़ा गया.

Lighthouse कुछ contexts में missing या weak security headers flag कर सकता है, लेकिन यह आपका only verification method नहीं होना चाहिए. यदि आप इसे wider review के हिस्से के रूप में उपयोग करते हैं, तो findings को verdicts के बजाय signals की तरह पढ़ें; यही mindset तब भी लागू होता है जब आप बिना घबराए Lighthouse report पढ़ते हैं.

<!-- tool-cta:start -->

💡 इसे आज़माएँ: हर HSTS बदलाव से पहले और बाद में, Get Headers के साथ Strict-Transport-Security response की जाँच करें ताकि पुष्टि हो सके कि max-age, includeSubDomains और preload आपकी अपेक्षा के अनुसार हैं।

<!-- tool-cta:end -->

HSTS के लिए privacy case

HSTS को अक्सर security header के रूप में frame किया जाता है, और यह है भी. इसका एक privacy benefit भी है: यह इस chance को कम करता है कि user की first request किसी untrusted network पर plain HTTP के जरिए leak हो जाए.

यह airport Wi-Fi, hotel networks, corporate guest networks, और ऐसी हर जगह मायने रखता है जहाँ user का traffic observe या modify किया जा सकता है. Plain HTTP request hostname, path, Secure flag के बिना cookies, और अन्य request details expose कर सकती है. HTTPS magic नहीं है, लेकिन इसे consistently force करना avoidable leakage की पूरी class को हटा देता है.

सबसे अच्छे HSTS deployments uninteresting होते हैं. वे धीरे-धीरे roll out होते हैं, reliable certificates से backed होते हैं, और इतने boring होते हैं कि कोई notice नहीं करता. ठीक यही आप ऐसे header से चाहते हैं जिसका failure mode dramatic हो सकता है.