ตัววิเคราะห์ Security Headers

Response headers ถือแนวนโยบายความปลอดภัยที่บังคับใช้จริงในเบราว์เซอร์สำหรับเว็บไซต์ส่วนใหญ่ แต่การอ่านด้วยตาเปล่ามักพลาดได้ง่าย: Content-Security-Policy อาจดูเข้มงวดเมื่อมองผ่านๆ แต่กลับยอมให้ unsafe-inline scripts อย่างเงียบๆ ขณะที่ Strict-Transport-Security header อาจปรากฏอยู่ แต่มี max-age สั้นมากจนแทบไม่ช่วยอะไร เครื่องมือนี้รับ raw header block ที่คุณวางเข้ามา — คัดลอกจาก curl -I, Postman หรือแท็บ Network ของ DevTools — แล้วประมวลผลผ่านการตรวจสอบประเภทเดียวกับที่ผู้ตรวจสอบ header ออนไลน์ชื่อดังใช้ โดยทำงานในเบราว์เซอร์ของคุณทั้งหมด ไม่มีการดึงข้อมูล: สิ่งที่คุณวางลงไปเท่านั้นที่ถูกวิเคราะห์ หมายความว่ามันทำงานเหมือนกันสำหรับไซต์จริงที่เปิดสาธารณะ, staging server ภายใน หรือปลายทางหลังไฟร์วอลล์ที่สแกนเนอร์ภายนอกไม่มีทางเข้าถึง

หัวใจหลักคือตัวแยกวิเคราะห์ไวยากรณ์ของ Content-Security-Policy จริง ไม่ใช่ checklist ค่าของ header จะถูกแบ่งด้วยเครื่องหมายอัฒภาคเป็น directives แล้วรายการแหล่งที่มาของแต่ละ directive จะถูกแบ่งและตรวจสอบในแบบของตัวเอง: directives ที่เกี่ยวข้องกับ script และ style จะถูกตั้งข้อสังเกตหากยอมให้ 'unsafe-inline' หรือ 'unsafe-eval', directive ใดๆ จะถูกตั้งข้อสังเกตเมื่อมีไวลด์การ์ด '*' เปล่า (ความรุนแรงเพิ่มขึ้นหากไวลด์การ์ดนั้นอยู่บน script-src, object-src, base-uri หรือ default-src), แหล่งที่มาแบบ scheme กว้างๆ อย่าง 'https:' บน directive ของ script จะถูกระบุว่าเกือบจะไม่ต่างจากการใช้ไวลด์การ์ด, และนโยบายโดยรวมจะถูกตรวจสอบว่าขาด default-src fallback หรือไม่ รวมถึง directive ที่เลิกใช้งานแล้ว (block-all-mixed-content, plugin-types, referrer, reflected-xss) ที่เบราว์เซอร์สมัยใหม่ไม่สนใจแล้ว CSP ที่ส่งมาเป็น Content-Security-Policy-Report-Only เท่านั้น จะถูกตรวจพบและระบุว่ายังไม่ได้ถูกบังคับใช้จริง แตกต่างจากการไม่มีนโยบายเลย

นอกเหนือจาก CSP เครื่องมือจะตรวจสอบ Strict-Transport-Security โดยแยกวิเคราะห์ directive max-age ของตัวเอง และตั้งข้อสังเกตหากค่าน้อยกว่าประมาณหกเดือนว่าสั้นเกินกว่าจะมีประสิทธิผลอย่างมีความหมาย รวมถึงตรวจสอบว่าได้ตั้งค่า includeSubDomains และ preload หรือไม่ X-Content-Type-Options จะต้องเป็นสตริง 'nosniff' ตรงตัวเท่านั้น มิฉะนั้นจะถูกระบุว่าเบราว์เซอร์ไม่สนใจ X-Frame-Options ถูกตรวจสอบหา DENY หรือ SAMEORIGIN แต่เครื่องมือยังรับรู้ด้วยว่า CSP frame-ancestors directive เป็นตัวทดแทนสมัยใหม่สำหรับการป้องกัน click-jacking — หากมี directive นั้น X-Frame-Options จะถือว่าครอบคลุมแล้วแม้ตัว legacy header เองจะหายไป Referrer-Policy ถูกตรวจสอบเทียบกับรายการคีย์เวิร์ดที่ถูกต้องจริง และแจ้งเตือนหากตั้งค่าเป็น 'unsafe-url' ที่รั่วไหล URL, Permissions-Policy ถูกตรวจสอบว่ามีอยู่หรือไม่ และทุกบรรทัด Set-Cookie ที่พบจะถูกวิเคราะห์หา Secure, HttpOnly และ SameSite attributes รวมถึงกฎเฉพาะที่ว่า SameSite=None cookies ที่ไม่มี Secure จะถูกเบราว์เซอร์ปฏิเสธอย่างเงียบๆ

ทุกการตรวจสอบให้ผลลัพธ์ที่ตรงไปตรงมา 1 ใน 3 แบบ — ดี, ต้องใส่ใจ, หรือ ขาดหายไป — พร้อมคำอธิบายแบบภาษาคนว่าทำไม header นั้นจึงสำคัญกับการโจมตีจริง (XSS, clickjacking, การขโมยคุกกี้, การลดระดับโปรโตคอล) และเกรดโดยรวม A-F คือผลรวมคะแนนต่อ header อย่างโปร่งใส ไม่ใช่คะแนนแบบกล่องดำ รายงานทั้งหมดสามารถคัดลอกเป็นข้อความธรรมดาได้ในคลิกเดียวเพื่อนำไปวางใน pull request, ticket หรือการตรวจสอบด้านความปลอดภัย และเพราะการวิเคราะห์ทำจากข้อความที่วางทั้งสิ้น เครื่องมือนี้มีประโยชน์เท่าเทียมกันในการตรวจสอบ headers ของไซต์คุณเอง, ทบทวน response ของผู้ให้บริการก่อนเชื่อมต่อด้วย, หรือตรวจสอบการเปลี่ยนแปลง config อีกครั้งก่อนนำขึ้นจริง