Paano i-set up ang HSTS nang hindi nalolock out ang sarili

Simple ang HSTS hanggang sa hindi na

Ang HTTP Strict Transport Security, na karaniwang pinaikli bilang HSTS, ay nagsasabi sa mga browser: “para sa site na ito, laging gumamit ng HTTPS.” Kapag natanggap ng browser ang header sa pamamagitan ng valid na HTTPS connection, tatandaan nito ang panuntunan sa tagal na itatakda mo.

Kapaki-pakinabang iyon. Pinipigilan nito ang mga protocol downgrade attack, binabawasan ang aksidenteng insecure requests, at iniiwasan ang alanganing sandali kung saan tina-type ng user ang example.com at sandaling dumadaan sa plain HTTP bago ma-redirect.

Malagkit din ito. Kung mag-publish ka ng maling HSTS policy, maaaring patuloy itong ipatupad ng mga browser kahit matagal mo nang inalis ang header mula sa server. Ganoon nalolock out ang mga team: hindi eksaktong mula sa sarili nilang admin panel, kundi mula sa mga browser ng user, mga subdomain, staging system, legacy endpoint, at mga nakalimutang serbisyo na hindi pa handa para sa sapilitang HTTPS.

Ang layunin ay hindi iwasan ang HSTS. Ang layunin ay i-deploy ito na parang migration, hindi parang toggle.

Ano talaga ang ginagawa ng HSTS header

Ganito ang karaniwang HSTS header:

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

May tatlong mahalagang bahagi ito:

• max-age: gaano katagal, sa segundo, dapat ipatupad ng browser ang HTTPS para sa host na ito.
• includeSubDomains: kung nalalapat din ba ang panuntunan sa bawat subdomain.
• preload: isang signal na gusto mong maisama ang domain sa mga browser preload list.

Pinagkakatiwalaan lang ng browser ang header na ito kapag natanggap ito sa valid na HTTPS. Kung invalid, expired, o hindi tugma ang certificate, hindi dapat tumanggap ang browser ng bagong HSTS policy mula sa response na iyon.

Kapag na-store na ang policy, ang mga susunod na pagtatangkang bisitahin ang http://example.com ay ina-upgrade ng browser sa https://example.com bago ipadala ang request. Iyon ang panalo sa privacy: hindi kailanman umaalis sa device ang insecure request.

Mga senaryong lockout na dapat iwasan

Karamihan sa mga HSTS failure ay hindi dulot ng pangunahing website. Nangyayari ang mga ito sa mga gilid.

1. Hindi HTTPS-ready ang isang nakalimutang subdomain

Maayos pakinggan ang includeSubDomains, pero absolutong-absoluto ito. Kung itatakda mo ito sa example.com, nalalapat ito sa:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• anumang iba pa sa ilalim ng domain na iyon

Kung alinman sa mga host na iyon ay hindi makapag-serve ng valid na HTTPS, ang mga user na may naka-cache na HSTS policy ay hindi makakaabot sa kanila sa HTTP.

2. Nag-expire ang certificate

Kung walang HSTS, minsan nagki-click through ang mga user sa certificate warnings. Hindi iyon magandang security practice, pero nangyayari ito.

Sa HSTS, hindi pinapayagan ng modernong mga browser ang madaling bypass ng certificate errors para sa host na iyon. Iyon ang punto. Nangangahulugan din ito na dapat maging boring, monitored, at tested ang certificate renewal.

3. Ang staging o internal tools ay nasa ilalim ng production domain

Maaaring maging masakit ang paglalagay ng internal tools sa ilalim ng *.example.com kapag gumagamit na ng includeSubDomains ang parent domain. Kung ang mga tool na iyon ay gumagamit ng self-signed certificates, private certificate authorities, lumang TLS configurations, o wala talagang HTTPS, ilalantad ng HSTS ang shortcut.

Isa itong dahilan kung bakit pinananatili ng maraming team ang internal at experimental systems sa ilalim ng hiwalay na domain na may sarili nitong security policy.

4. Itinuturing ang preload bilang karaniwang checkbox

Ang HSTS preload ay hindi basta isa pang directive. Nangangahulugan ito na maaaring maisama ang iyong domain sa loob ng mga browser bilang HTTPS-only bago pa man bumisita ang sinumang user sa site mo.

Isinasara nito ang “first visit” gap, pero mas mahirap itong bawiin. Ang pag-alis mula sa mga preload list ay maaaring umabot ng ilang linggo o buwan bago makarating sa mga user, depende sa mga browser release cycle. Ang preload ay angkop para sa stable at mature na mga domain. Hindi ito angkop para sa site na inaalam pa lang ang imbentaryo ng mga subdomain nito.

Isang ligtas na plano sa rollout

Step 1: I-audit ang bawat hostname na kontrolado mo

Bago itakda ang includeSubDomains, ilista ang bawat hostname sa ilalim ng domain. Panimula ang DNS records, pero hindi iyon ang buong kuwento. Suriin ang mga configuration ng CDN, hosting dashboard, email-related hostnames, lumang marketing tools, storage buckets, at internal documentation.

Para sa bawat hostname, sagutin:

• Nagse-serve ba ito ng HTTP, HTTPS, o pareho?
• Valid ba ang HTTPS certificate at awtomatiko bang nire-renew?
• Malinis ba nitong nire-redirect ang HTTP papuntang HTTPS?
• Dapat ba itong maging public?
• Kailangan pa ba ito?

Kung mayroon nang production header debugging habits ang team mo, natural itong isama sa redirect at header checks. Tinalakay namin ang workflow na iyon sa isang maliit na toolkit para sa pag-debug ng redirects at HTTP headers sa production.

Step 2: Ayusin ang HTTPS bago magdagdag ng HSTS

Hindi ginagawang secure ng HSTS ang sirang HTTPS setup. Ginagawa lang nitong mandatory ang HTTPS.

Bago ito i-enable, i-verify:

• Sakop ng TLS certificates ang tamang hostnames.
• Awtomatikong nare-renew ang certificates.
• Nagre-redirect ang HTTP papuntang HTTPS sa isang malinis na hop kung maaari.
• Consistent ang canonical host redirects, halimbawa non-www papuntang www, o kabaliktaran.
• Hindi umaasa ang application assets sa insecure na http:// URLs.

Mas hindi na karaniwan ang mixed content kaysa dati, pero lumilitaw pa rin ito sa lumang CMS themes, analytics snippets, embedded media, at hard-coded image paths.

Step 3: Magsimula sa napakaikling max-age

Huwag magsimula sa isang taon. Magsimula sa limang minuto:

Strict-Transport-Security: max-age=300

I-deploy lang iyon sa hostname na sinusubukan mo, karaniwan ang canonical production website. Huwag munang isama ang includeSubDomains.

Pagkatapos ay mag-test sa totoong browsers at gamit ang command-line requests:

curl -I https://example.com

Dapat mong makita ang eksaktong isang Strict-Transport-Security header. Karaniwang pinagmumulan ng kalituhan ang duplicate HSTS headers mula sa app server at CDN. Sa pangkalahatan, ina-apply ng mga browser ang effective policy, pero hindi kailangan ng mga taong nagde-debug ng incident ang ambiguity.

Step 4: Dagdagan nang paunti-unti

Kung walang nasisira, dagdagan ang tagal nang paunti-unti:

Strict-Transport-Security: max-age=86400

Pagkatapos:

Strict-Transport-Security: max-age=604800

Pagkatapos marahil:

Strict-Transport-Security: max-age=2592000

Isang praktikal na iskedyul ay:

• 5 minuto
• 1 araw
• 1 linggo
• 1 buwan
• 6 na buwan o 1 taon

Walang premyo sa pagmamadali. Ang buong punto ng staged rollout ay bigyan ng oras ang monitoring mo, support inbox, at edge cases na sabihin sa iyo kung ano ang nakaligtaan ng checklist mo.

Step 5: Idagdag lang ang includeSubDomains kapag tunay na ang audit

Kapag HTTPS-ready na ang bawat public subdomain, maaari mong ikonsidera:

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

Ito ang sandaling dapat maging konserbatibo. Kung may isang legacy service na kailangan pa rin ng HTTP, huwag idagdag ang includeSubDomains sa parent domain. I-migrate ang serbisyong iyon, ilipat ito sa ibang domain, o tanggapin na dapat manatiling mas makitid muna ang iyong HSTS policy.

Dapat sumalamin sa realidad ang security headers. Hindi dapat gamitin ang mga ito bilang motivational posters para sa infrastructure na inaasahan mong magkakaroon ka balang araw.

Step 6: Ituring ang preload bilang hiwalay na proyekto

Ikonsidera lang ang preload kapag totoo ang lahat ng sumusunod:

• Sinusuportahan ng domain at lahat ng subdomain ang valid na HTTPS.
• Nagre-redirect ang HTTP papuntang HTTPS.
• Gumagamit ang HSTS header ng max-age na hindi bababa sa 31536000 segundo.
• Kasama sa header ang includeSubDomains.
• Kasama sa header ang preload.
• Kumpiyansa kang hindi mo kakailanganin ang plain HTTP saanman sa ilalim ng domain.

Ganito ang preload-ready na header:

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

Ang pagsusumite sa preload list ay pangmatagalang commitment. Kung ang site ay campaign microsite, pansamantalang product domain, o domain na malabo ang ownership boundaries, laktawan ito.

Mga halimbawa ng configuration

Nginx

Gamitin ang always para maipadala rin ang header sa error responses:

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

Kapag stable na ang rollout:

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

Apache

Kapag naka-enable ang mod_headers:

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

Sa kalaunan:

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

CDN o edge platform

Kung nagse-set ng response headers ang CDN mo, mas mainam na pamahalaan ang HSTS sa iisang lugar. Huwag magtakda ng isang policy sa origin at isa pa sa edge maliban kung may napakalinaw kang dahilan.

Suriin din kung ina-apply ng CDN ang headers sa redirects, cached errors, at custom error pages. Ang production site ay hindi lang ang 200 OK response nito.

Paano ligtas na i-undo ang HSTS

Kung kailangan mong i-disable ang HSTS, ipadala:

Strict-Transport-Security: max-age=0

Pero may catch: kailangang matagumpay na maabot ng browser ang site sa valid na HTTPS para matanggap ang header na iyon. Kung sira mismo ang HTTPS, hindi makukuha ng mga user na may naka-cache na HSTS policy ang instruction na maglilinis nito.

Kaya ang karaniwang recovery order ay:

1. Ibalik ang valid na HTTPS.
2. I-serve ang Strict-Transport-Security: max-age=0.
3. Panatilihin ito nang sapat na tagal para matanggap ito ng bumabalik na mga user.
4. Alisin o palitan ang header pagkatapos ma-resolve ang incident.

Kung preloaded ang domain, hindi sapat ang pag-serve ng max-age=0 para sa mga bagong browser profile. Kailangan mo ring humiling ng removal mula sa preload list at hintaying maipadala ang pagbabagong iyon sa pamamagitan ng browser updates.

Testing checklist bago ka mag-ship

Gamitin ang checklist na ito bago dagdagan ang max-age o idagdag ang includeSubDomains:

• Nagbabalik ng valid na certificate ang canonical HTTPS URL.
• Nagre-redirect ang HTTP papuntang HTTPS.
• Iisa lang ang HSTS header.
• Lumilitaw ang header sa redirects at error responses kung saan angkop.
• May valid na HTTPS ang lahat ng public subdomains.
• Minomonitor ang certificate renewal.
• Walang critical internal system na umaasa sa HTTP sa ilalim ng parehong parent domain.
• Napag-usapan nang tahasan ang preload, hindi idinagdag dahil sa nakagawian.

Maaari ring mag-flag ang Lighthouse ng nawawala o mahinang security headers sa ilang context, pero hindi ito dapat ang tanging verification method mo. Kung gagamitin mo ito bilang bahagi ng mas malawak na review, basahin ang findings bilang signals sa halip na verdicts; nalalapat ang parehong mindset kapag nagbabasa ka ng Lighthouse report nang hindi nagpapanic.

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

💡 Subukan ito: Bago at pagkatapos ng bawat pagbabago sa HSTS, suriin ang Strict-Transport-Security response gamit ang Get Headers para kumpirmahin na ang max-age, includeSubDomains at preload ay ayon sa inaasahan mo.

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

Ang privacy case para sa HSTS

Madalas ilarawan ang HSTS bilang security header, at ganoon nga ito. May benepisyo rin ito sa privacy: binabawasan nito ang tsansang mag-leak ang unang request ng user sa plain HTTP sa isang untrusted network.

Mahalaga iyon sa airport Wi-Fi, hotel networks, corporate guest networks, at saanman maaaring maobserbahan o mabago ang traffic ng user. Maaaring ilantad ng plain HTTP request ang hostname, path, cookies na walang Secure flag, at iba pang detalye ng request. Hindi magic ang HTTPS, pero ang consistent na pagpupuwersa nito ay nag-aalis ng buong klase ng maiiwasang leakage.

Ang pinakamahuhusay na HSTS deployment ay hindi kapansin-pansin. Mabagal ang rollout ng mga ito, sinusuportahan ng maaasahang certificates, at sapat na boring para walang makapansin. Iyon mismo ang gusto mo mula sa isang header na maaaring maging dramatiko ang failure mode.