HSTS Header Generator: บังคับ HTTPS ด้วย max-age, includeSubDomains และ preload

ตลอดประวัติศาสตร์ของเว็บ HTTPS เคยเป็นแค่ "ข้อแนะนำ" เบราว์เซอร์โหลดหน้าเว็บผ่าน HTTP ธรรมดาจนกว่าลิงก์จะบอกเป็นอย่างอื่น ซึ่งเปิดช่องให้เกิด downgrade attack และการดักจับ traffic บน Wi-Fi สาธารณะ HTTP Strict Transport Security (HSTS) ปิดช่องโหว่นี้ด้วย response header เพียงบรรทัดเดียว ที่บอกเบราว์เซอร์ว่าโดเมนนี้คุยผ่าน HTTPS เท่านั้น และ request ผ่าน HTTP ธรรมดาต้องถูกอัปเกรดก่อนจะมีอะไรถูกส่งออกไป พูดง่าย ๆ คือ HSTS เปลี่ยน "ควรใช้ HTTPS" ให้กลายเป็น "ต้องใช้ HTTPS" ในทุกการเข้าชมครั้งถัดไป

HSTS Header Generator ช่วยสร้าง header นี้ให้คุณ แทนที่จะพิมพ์พอลิซีแบบคั่นด้วยเซมิโคลอนด้วยมือแล้วภาวนาว่าตัวพิมพ์ หน่วย และลำดับถูกต้อง คุณแค่กรอก max-age สลับ toggle includeSubDomains และ preload แล้วดู header Strict-Transport-Security ที่แน่นอนถูกประกอบขึ้นแบบเรียลไทม์ พร้อมเช็กลิสต์ความพร้อม preload และสนิปเป็ตสำหรับ nginx, Apache และ Express ทุกอย่างทำงานในเบราว์เซอร์ 100%

ความระมัดระวังสำคัญเป็นพิเศษกับ HSTS เพราะความผิดพลาดของมัน "ติดค้าง" เบราว์เซอร์จำพอลิซีไว้จนกว่า max-age จะหมดอายุ ค่าที่ดุเกินไปอาจล็อกผู้ใช้ออกจาก subdomain ที่พังได้นานหลายเดือน คู่มือนี้จะพาไล่วิธีใช้เครื่องมือ สิ่งที่แต่ละ directive ควบคุมจริง ๆ และวิธี rollout ให้ปลอดภัยโดยไม่เปลี่ยนชัยชนะด้านความปลอดภัยให้กลายเป็นเหตุล่ม

ทำไมต้องใช้ HSTS Header Generator?

• Header ถูกต้อง ไร้ความผิดพลาดด้านไวยากรณ์. ผลลัพธ์เป็นพอลิซีที่ valid อย่าง Strict-Transport-Security: max-age=31536000; includeSubDomains; preload — ตัวพิมพ์และเซมิโคลอนจัดการให้หมด
• พรีเซ็ตที่ออกแบบมาเพื่อการไต่ระดับอย่างปลอดภัย. ค่าคลิกเดียวตั้งแต่ 5 นาทีถึง 2 ปี ช่วยให้คุณเริ่มจากเล็กและเพิ่มระดับคอมมิตต์เมื่อแต่ละช่วงนิ่งแล้วเท่านั้น
• เช็กลิสต์ความพร้อม preload ในตัว. เมื่อเปิด preload เครื่องมือจะตรวจว่า max-age ถึงหนึ่งปีและเปิด includeSubDomains แล้ว พร้อมเตือนว่าการถอนออกใช้เวลาหลายเดือน
• สนิปเป็ตสำหรับเซิร์ฟเวอร์ใหญ่สามตัว. พอลิซีเดียวกันเรนเดอร์เป็นบรรทัด add_header ของ nginx ที่มี always, directive Header always set ของ Apache และ middleware ของ Express
• กันความผิดพลาดแบบติดค้าง. เบราว์เซอร์จำพอลิซี HSTS ไว้จนหมดอายุ พิมพ์ผิดปุ๊บไม่ได้แค่รีเฟรชก็จบ การให้เครื่องมือสร้างสตริงแทนการพิมพ์เองตัดปัญหาที่พบบ่อยที่สุดออกไป
• ฟรี เป็นส่วนตัว และทำงานฝั่งไคลเอนต์ทั้งหมด. ไม่ต้องสมัคร ไม่มีการอัปโหลด ไม่มี request ไปเซิร์ฟเวอร์

ฟีเจอร์หลัก

สามรายละเอียดที่ทำให้ใช้งานราบรื่น:

• พรีเซ็ตถูกออกแบบเป็นช่วงเวลาโดยตั้งใจ ผลักคุณไปสู่การ rollout แบบไต่ขั้นแทนพอลิซีสูงสุดชุดเดียวจบ
• เช็กลิสต์ปรากฏเฉพาะเมื่อเปิด preload จึงทำหน้าที่เป็น "จุดชะลอให้คิด" แบบมีเจตนา ไม่ใช่เสียงพื้นหลัง
• สนิปเป็ตถูกสร้างใหม่จากค่าเดียวกับพรีวิว สิ่งที่คุณทดสอบคือสิ่งที่คุณ deploy แยกกันไม่ได้

วิธีใช้งาน

1. เปิดเครื่องมือ. เข้าไปที่ HSTS Header Generator — ไม่ต้องสมัครสมาชิก
2. ตั้ง max-age. เลือกพรีเซ็ตหรือพิมพ์ค่าเป็นวินาที: 300 (5 นาที) สำหรับ rollout รอบแรก และ 31536000 (1 ปี) เมื่อ HTTPS นิ่งทั้งโดเมนแล้ว
3. สลับ includeSubDomains. เปิดก็ต่อเมื่อยืนยันแล้วว่าทุก subdomain รวมถึง staging ที่ลืมไว้ เสิร์ฟ HTTPS ด้วยใบรับรองที่ valid
4. ตัดสินใจเรื่อง preload. ปล่อยปิดไว้จนกว่าพอลิซีแบบยาวจะรันนิ่งแล้ว จากนั้นค่อยตรวจเช็กลิสต์: max-age หนึ่งปี เปิด includeSubDomains และตระหนักว่าการถอนใช้เวลาหลายเดือน
5. คัดลอกและ deploy. วาง header หรือสนิปเป็ตเซิร์ฟเวอร์ลงคอนฟิก แล้ว deploy และตรวจด้วย curl -I https://yourdomain.com

max-age, includeSubDomains, preload

พอลิซี Strict-Transport-Security ประกอบจากสามส่วนที่มีระดับความเสี่ยงต่างกัน และควรเปิดตามลำดับที่ตั้งใจไว้

max-age: หมุดของการ rollout

max-age คือระยะเวลาที่เบราว์เซอร์จำกฎ HTTPS-only หน่วยเป็นวินาที ตลอดช่วงเวลาดังกล่าวเบราว์เซอร์จะปฏิเสธ URL http:// ของโดเมน — ลิงก์ที่พิมพ์เอง bookmark redirect — และอัปเกรดให้เงียบ ๆ นั่นคือเป้าหมายที่ต้องการพอดี แต่ก็ตัดสองทาง: ถ้า HTTPS พัง ผู้ใช้ที่แคชพอลิซียาวไว้จะเจอความล้มเหลวแบบแข็ง ๆ ไปจนหมดอายุ

ดังนั้นให้ rollout แบบไต่ลำดับ: เริ่มจากห้านาทีแล้วดูหาปัญหาใบรับรองและ mixed content

Strict-Transport-Security: max-age=300

หลังหนึ่งสัปดาห์ที่สะอาด ขยับไปหนึ่งเดือนพร้อมครอบคลุม subdomain

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

จุดที่นิ่งแล้วของโดเมนที่เสถียร — และค่าขั้นต่ำของโปรแกรม preload — คือหนึ่งปีเต็ม

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

เข็มนาฬิกาเป็นแบบ rolling: ทุก response ใหม่ที่มี header จะรีเซ็ตหน้าต่าง ผู้ใช้ประจำจึงได้รับการปกป้องตราบเท่าที่คุณยังส่ง header นี้ออกไป

includeSubDomains: ขยายก่อน แล้วค่อยตรวจ

includeSubDomains ใช้กฎ HTTPS-only กับทุก hostname ใต้โดเมนของคุณ ไม่ใช่แค่ host ที่ส่ง header มา ผู้ใช้ที่เข้า mail.yourdomain.com จะได้รับการปกป้องแม้ host นั้นไม่เคยส่งพอลิซีของตัวเองเลย แต่ก็เป็น toggle ที่เสี่ยงที่สุด เพราะ "ทุก subdomain" รวมถึงตัวที่คุณลืมด้วย: dev box ของเพื่อนร่วมทีม, staging เก่า ๆ หรือเครื่องมือภายในที่ยังวิ่งบน HTTP ธรรมดา เมื่อพอลิซีถูกแคช host เหล่านั้นจะเข้าไม่ได้จนกว่าพอลิซีจะหมดอายุ ตรวจก่อน: ไล่ DNS record และ wildcard โหลดทุก subdomain ผ่าน HTTPS แล้วแก้หรือถอนตัวตกค้างก่อนกดสวิตช์

preload: ประตูบานเดียว

directive preload ทำเครื่องหมายว่าโดเมนเป็นตัวเต็งของ HSTS preload list — แคตตาล็อกโดเมน HTTPS-only ที่ฝังมากับ Chromium, Firefox และเอนจินอื่น ๆ เมื่อติดลิสต์ เบราว์เซอร์จะบังคับ HTTPS ตั้งแต่การเข้าครั้งแรก ปิดช่องว่างเดียวที่ HSTS ธรรมดาเหลือไว้

ข้อแลกเปลี่ยนคือการถอนใกล้เคียงกับประตูบานเดียว คำขอถอนได้รับการพิจารณา แต่การเปลี่ยนแปลงจะไปถึงผู้ใช้ผ่านการอัปเดตเบราว์เซอร์เป็นเดือน ๆ และคนที่ใช้ build เก่ายังคงพอลิซีเข้มงวดต่อไปอีกนาน ก่อนสมัครให้ยืนยันทุกข้อในเช็กลิสต์ — max-age หนึ่งปี เปิด includeSubDomains ใบรับรอง valid ทุกที่ — แล้วส่งเฉพาะรูปแบบที่แข็งสมบูรณ์:

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

ห้ามใส่ preload ตั้งแต่วันแรก สมัครเมื่อพอลิซีหนึ่งปีรันสะอาดมาแล้วหลายเดือนใน production เท่านั้น

กรณีการใช้งานจริง

เส้นฐานความปลอดภัยของเว็บใหม่

กำลังเปิดตัวเว็บการตลาดหรือผลิตภัณฑ์ SaaS? Deploy ด้วย max-age สั้นในสัปดาห์แรก ขยับไปหนึ่งปีบวก includeSubDomains เมื่อโดเมนนิ่ง และเพิ่ม preload เมื่อพร้อมคอมมิตกับลิสต์เท่านั้น แต่ละขั้นคือการแก้คอนฟิกบรรทัดเดียว

ทำให้ร้านค้าออนไลน์ที่มีอยู่แข็งแรงขึ้น

เว็บอีคอมเมิร์ซมีหน้าเก่า ๆ, widget บุคคลที่สาม และลิงก์ http:// สะสมหลายปี HSTS ขจัดหน้าต่าง downgrade หลังการเข้าครั้งแรก ปกป้อง flow การชำระเงินบนเครือข่ายสาธารณะ ไต่ max-age พร้อมจับตา mixed-content warnings แล้วล็อกพอลิซีหนึ่งปี

Dashboard หลาย subdomain

มี app., api. และ docs. อยู่ใต้โดเมนเดียว? หลังตรวจแล้วว่าทุก subdomain เสิร์ฟ HTTPS ที่ valid header เดียวที่มี includeSubDomains จะปกป้องทั้งอสังหาริมทรัพย์ดิจิทัลของคุณ รวมถึง host ที่เพิ่มทีหลัง โดยไม่ต้องตั้งค่าทีละเซิร์ฟเวอร์

Hardening หลังเกิดเหตุ

หลังใบรับรองหมดอายุหรือมีรายงานการดักจับ traffic HSTS คือวิธีแก้เชิงโครงสร้างที่กันเหตุซ้ำ Deploy พอลิซีแบบเข้มแต่ยังไม่ preload แล้วตรวจด้วย curl -I ทุกจุดรับ connection ว่า header รอดจากพร็อกซี CDN และหน้า error

แนวปฏิบัติที่ดีที่สุด

• ห้ามส่ง preload ตั้งแต่วันแรก. รันพอลิซี max-age ยาวที่นิ่งก่อน การถอนใช้เวลาหลายเดือน จึงควรมอง toggle นี้เป็นหมุดหมาย ไม่ใช่ค่าเริ่มต้น
• ตรวจทุก subdomain ก่อนใช้ includeSubDomains. ไล่ DNS record และ wildcard — dev และ staging ที่ถูกลืมคือเหยื่อคลาสสิก
• รักษาเว็บให้ HTTPS-only ตั้งแต่ต้นจนจบ. asset ทุกชิ้นควรโหลดผ่าน HTTPS อยู่แล้วเพื่อไม่ให้ผู้ใช้เจอ mixed-content warnings
• ไต่ max-age ทีละขั้น. นาที แล้ววัน แล้วเดือน แล้วหนึ่งปี แต่ละช่วงซื้อหลักฐานว่าช่วงถัดไปปลอดภัย
• ทดสอบด้วย curl -I หลัง deploy ทุกครั้ง. ยืนยัน header บน response จริง รวมถึง redirect และ error เพราะพร็อกซีและ CDN ตัด header ออกเงียบ ๆ ได้
• ใส่ header นี้ไว้ในเช็กลิสต์ release. header HSTS ที่หายไปล้มเหลวอย่างเงียบ ๆ จึงควรทำให้การตรวจเป็นกิจวัตร

ล็อก HTTPS ตั้งแต่วันนี้

HSTS เป็นหนึ่งในมาตรการความปลอดภัยที่ให้มูลค่าสูงที่สุดที่คุณส่งได้ในคอนฟิกบรรทัดเดียว — ตราบใดที่บรรทัดนั้นถูก เปิด HSTS Header Generator ตั้ง max-age ตรวจ includeSubDomains และ preload กับเช็กลิสต์ในตัว แล้ววางสนิปเป็ตสำหรับสแตกของคุณ

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• Security Headers Generator — สร้างชุด header ตาม OWASP ครบชุด มี HSTS รวมอยู่ในรอบเดียว
• CSP Generator — ประกอบ Content-Security-Policy ที่บล็อกสคริปต์แทรกและควบคุมแหล่งโหลด resource
• Permissions-Policy Generator — ปิดฟีเจอร์เบราว์เซอร์ที่ทรงพลังอย่างกล้องและ geolocation ด้วย header แบบประกาศ

บังคับ HTTPS ให้ครบทุกหน้า!

คำถามที่พบบ่อย

ถ: HSTS ปกป้องการเข้าครั้งแรกของผู้ใช้หรือไม่?

ตอบ: ด้วยตัวมันเองยังไม่ เบราว์เซอร์บังคับใช้พอลิซีหลังจากได้รับ header อย่างน้อยหนึ่งครั้งแล้ว การเชื่อมต่อแรกจึงยังถูกดักจับได้ — ช่องว่างแบบ trust-on-first-use การติด HSTS preload list จะปิดช่องนี้ เพราะกฎ HTTPS-only ถูกฝังไว้ในเบราว์เซอร์ก่อน request แรกจะเกิดขึ้น

ถ: flag always ในสนิปเป็ต nginx ทำอะไร?

ตอบ: โดยค่าเริ่มต้น nginx ใส่ header ปกติเฉพาะบาง response code พารามิเตอร์ always บังคับให้แนบ Strict-Transport-Security กับทุก response รวมถึง redirect และ error อย่าง 404 และ 503 พอลิซีจึงถูกรีเฟรชต่อเนื่องไม่ว่าแอปจะตอบอะไร

ถ: ถอนการสมัคร preload ย้อนกลับได้ไหม?

ตอบ: ถอนได้แต่ช้า คำขอถอนมีอยู่จริง แต่การเปลี่ยนแปลงจะไปถึงผู้ใช้เมื่อ browser update ถูกเผยแพร่ไปเป็นเดือน ๆ และ build เก่ายังคงพอลิซีเข้มงวดได้อีกนาน — เหตุผลที่เช็กลิสต์ให้ถือว่า preload เป็นการตัดสินใจที่ต้องตั้งใจ

ถ: includeSubDomains ครอบคลุม subdomain ของ subdomain ด้วยหรือไม่?

ตอบ: ใช่ กฎผูกทุก hostname ใต้โดเมนที่ส่ง header ทุกความลึก รวมถึงชื่อที่มีอยู่แค่ใน DNS ภายใน โดยไม่สนใจ DNS wildcard ใด ๆ