ใช้ Lighthouse ตรวจสุขภาพและความปลอดภัยพื้นฐานของเว็บไซต์

Lighthouse ไม่ได้มีประโยชน์เฉพาะการวัด Performance เท่านั้น รายงานหมวด Best Practices ยังทำหน้าที่เหมือนไฟฉายที่ช่วยส่องหาความผิดปกติและความเสี่ยงพื้นฐานของหน้าเว็บก่อนที่ปัญหาจะไปถึงผู้ใช้จริง แม้มันจะไม่สามารถรับรองว่าเว็บไซต์ปลอดภัยทั้งหมด แต่ก็เป็นด่านตรวจแรกที่ใช้งานง่ายและควรเปิดดูเป็นประจำ

เริ่มตรวจจากหมวด Best Practices

เปิด Chrome DevTools แล้วเลือกแท็บ Lighthouse จากนั้นเลือกหมวด Best Practices เพื่อสร้างรายงาน จะเลือก Performance หรือ SEO เพิ่มพร้อมกันก็ได้ แต่หากต้องการตรวจสุขภาพและความปลอดภัยเบื้องต้น ควรอ่านรายละเอียดในหมวด Best Practices เป็นหลัก ไม่ควรดูเพียงคะแนนรวม เพราะหลักฐานและคำอธิบายของแต่ละรายการจะช่วยระบุต้นเหตุได้มากกว่า

Lighthouse ควรถูกเรียกใช้กับหน้าสำคัญหลายหน้า เนื่องจากแต่ละหน้ามีไฟล์ ทรัพยากร และขั้นตอนการทำงานแตกต่างกัน การที่หน้าแรกผ่านการตรวจจึงไม่ได้หมายความว่าทุกส่วนของเว็บไซต์จะผ่านด้วย หน้าที่ควรตรวจอย่างน้อย ได้แก่

• หน้าแรก
• หน้าเข้าสู่ระบบ
• หน้า checkout หรือชำระเงิน
• หน้า dashboard
• หน้าที่รับหรือแสดงข้อมูลสำคัญของผู้ใช้

HTTPS คือพื้นฐานที่ต้องผ่าน

เว็บไซต์ที่เปิดใช้งานจริงไม่ควรปล่อยให้ผู้ใช้เชื่อมต่อผ่าน HTTP แบบไม่เข้ารหัส เพราะข้อมูลอย่าง token, session cookie และข้อมูลจากแบบฟอร์มเข้าสู่ระบบอาจถูกดักอ่านหรือแก้ไขระหว่างทางได้ หาก Lighthouse แจ้งว่าเว็บไซต์ไม่ได้ใช้ HTTPS ควรถือเป็นปัญหาที่ต้องแก้ ไม่ใช่คำเตือนที่ปล่อยผ่านได้

การแก้ไขอาจอยู่ที่เว็บเซิร์ฟเวอร์ CDN หรือ reverse proxy ตามสถาปัตยกรรมที่ใช้งานอยู่ นอกจากติดตั้งใบรับรอง TLS ให้ถูกต้องแล้ว ควรกำหนด redirect จาก HTTP ไป HTTPS อย่างชัดเจน เพื่อให้ผู้ใช้ทุกคนถูกนำเข้าสู่ช่องทางที่เข้ารหัสเสมอ

ระวัง Mixed Content บนหน้า HTTPS

แม้หน้าเว็บหลักจะเปิดผ่าน HTTPS แต่ก็ยังไม่ปลอดภัยหากโหลดรูปภาพ สคริปต์ ฟอนต์ หรือไฟล์อื่นจากแหล่งที่ใช้ HTTP ปัญหานี้เรียกว่า mixed content และมีความรุนแรงเป็นพิเศษเมื่อทรัพยากรที่ไม่ปลอดภัยเป็น JavaScript เพราะผู้โจมตีอาจดัดแปลงสคริปต์ระหว่างทางและเปลี่ยนพฤติกรรมของหน้าเว็บได้

ตัวอย่างการโหลดสคริปต์ที่ไม่ปลอดภัยมีลักษณะดังนี้

<script src="http://old-cdn.example/app.js"></script>

แนวทางแก้ไขคือเปลี่ยน URL ของทรัพยากรเป็น HTTPS และตรวจสอบว่าแหล่งต้นทางรองรับ TLS อย่างถูกต้อง หากผู้ให้บริการเดิมไม่รองรับ HTTPS ควรย้ายไฟล์ไปยัง CDN หรือพื้นที่จัดเก็บที่ปลอดภัยกว่า รวมถึงค้นหา URL แบบ HTTP ที่อาจฝังอยู่ในโค้ดหรือข้อมูลจากระบบจัดการเนื้อหา

ตรวจสอบไลบรารีเก่าและช่องโหว่ที่รู้จักแล้ว

Lighthouse สามารถส่งสัญญาณเตือนเมื่อหน้าเว็บใช้งานไลบรารีฝั่งเบราว์เซอร์เวอร์ชันเก่าที่มีช่องโหว่ซึ่งมีหมายเลข CVE แล้ว ตัวอย่างที่พบบ่อยคือ jQuery, lodash หรือ Bootstrap เวอร์ชันที่ไม่ได้รับการอัปเดต คำเตือนนี้ควรนำไปสู่การตรวจสอบ dependency และไฟล์ lock เช่น package-lock.json หรือ yarn.lock ต่อไป

ไม่ควรอัปเดต package แบบสุ่มบน production เพราะเวอร์ชันใหม่อาจมี breaking changes หรือส่งผลต่อส่วนอื่นของระบบ กระบวนการที่ปลอดภัยกว่าคืออ่าน changelog ตรวจสอบ dependency ที่เกี่ยวข้อง รันชุดทดสอบ และทยอย deploy เป็นรอบเล็กเพื่อจำกัดผลกระทบ หากเกิดข้อผิดพลาดก็จะย้อนกลับและหาสาเหตุได้ง่ายกว่า

Console Error อาจซ่อนปัญหาใน Flow สำคัญ

หลายทีมมองว่า error ใน console เป็นเพียงรายละเอียดสำหรับนักพัฒนา แต่บางครั้ง error เหล่านี้เป็นสัญญาณของ API ที่ใช้งานไม่ได้ การตั้งค่า CORS ผิด หรือ token หมดอายุโดยที่หน้าเว็บไม่ได้จัดการสถานะอย่างเหมาะสม ผู้ใช้อาจยังมองเห็นหน้าเว็บตามปกติ แต่ขั้นตอนสำคัญอย่างการบันทึกข้อมูลหรือชำระเงินกลับทำงานไม่สำเร็จ

เมื่อ Lighthouse แจ้งปัญหานี้ ควรเปิด DevTools และทำซ้ำขั้นตอนใช้งานจริงเพื่อดู error โดยตรง จากนั้นตรวจทั้งข้อความผิดพลาด network request และสถานะตอบกลับจาก API เป้าหมายไม่ใช่เพียงทำให้ console ว่าง แต่ต้องยืนยันว่า flow ของผู้ใช้ทำงานครบถ้วนและแสดงข้อความที่เข้าใจได้เมื่อระบบล้มเหลว

ขอสิทธิ์จากเบราว์เซอร์เฉพาะเมื่อจำเป็น

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

แนวทางที่เหมาะสมคืออธิบายวัตถุประสงค์และประโยชน์ก่อน แล้วจึงเรียก browser API หลังจากผู้ใช้กดปุ่มหรือเริ่มขั้นตอนที่เกี่ยวข้อง ระบบควรรองรับกรณีที่ผู้ใช้ปฏิเสธสิทธิ์ด้วย โดยไม่ทำให้ทั้งหน้าหยุดทำงานหรือค้างอยู่ในสถานะที่ไปต่อไม่ได้

ใช้ Lighthouse เป็นด่านตรวจใน Pull Request

ทีมพัฒนาสามารถใช้ Lighthouse เป็นด่านแรกก่อนรวมโค้ดหรือปล่อยเว็บไซต์ได้ ระหว่าง review อาจรันผ่าน Chrome DevTools ด้วยตนเอง หรือใช้ package ของ Lighthouse ในระบบ CI เพื่อให้การตรวจเกิดขึ้นโดยอัตโนมัติ วิธีนี้ช่วยให้ปัญหาพื้นฐานถูกพบตั้งแต่ยังอยู่ใน pull request

ตัวอย่างกติกาที่นำไปใช้ได้คือกำหนดให้คะแนน Best Practices ต้องไม่ต่ำกว่า 90 หากคะแนนลดลง ระบบควรแนบรายงานหรือหลักฐานไว้ใน pull request เพื่อให้ผู้พัฒนาเห็นว่ารายการใดเปลี่ยนไป อย่างไรก็ตาม คะแนนควรเป็นสัญญาณเริ่มต้นสำหรับการตรวจสอบ ไม่ใช่เป้าหมายที่ต้องเพิ่มด้วยการซ่อนหรือหลีกเลี่ยงคำเตือน

เปลี่ยนรายงานให้เป็นงานที่แก้ไขได้

หลังจากได้รายงานแล้ว ควรเปิดอ่านรายละเอียดของแต่ละคำเตือน คลิกดู evidence และตามไปยังไฟล์หรือ dependency ที่เป็นต้นเหตุ จากนั้นแปลงปัญหาให้เป็นรายการงานที่มีขอบเขตชัดเจนและตรวจสอบผลลัพธ์ได้ ตัวอย่างเช่น

• เปลี่ยน URL ของ CDN จาก HTTP เป็น HTTPS
• อัปเดต lodash ไปยังเวอร์ชันที่แก้ช่องโหว่แล้ว
• แก้การจัดการ token หมดอายุในหน้า checkout
• เลื่อนการขอสิทธิ์ตำแหน่งไปหลังจากผู้ใช้กดเริ่มค้นหา
• ปิดหรือลบ source map จาก production หากไม่ได้ตั้งใจเปิดเผย

การเขียน action ให้เฉพาะเจาะจงช่วยให้ทีมมอบหมายงาน ติดตามผล และตรวจซ้ำได้ง่าย เมื่อแก้ไขแล้วควรรัน Lighthouse บนหน้าเดิมอีกครั้ง พร้อมทดสอบ flow สำคัญด้วยตนเองเพื่อยืนยันว่าการแก้ปัญหาไม่ได้สร้างผลกระทบใหม่

เข้าใจข้อจำกัดของ Lighthouse

Lighthouse ไม่ใช่เครื่องมือ penetration testing และไม่เข้าใจ business logic ของระบบ มันไม่สามารถยืนยันได้ว่า endpoint โอนเงินตรวจสอบสิทธิ์ถูกต้องหรือไม่ ไม่รู้ว่า admin API ถูกเปิดเผยเกินความจำเป็นหรือเปล่า และไม่สามารถค้นหาช่องโหว่ทุกประเภทในระบบหลังบ้านได้

สิ่งที่ Lighthouse ทำได้ดีคือการจับปัญหาพื้นฐานที่มองเห็นได้จากหน้าเว็บ เช่น HTTPS, mixed content, ไลบรารีเสี่ยง, console error และการใช้ permission ของเบราว์เซอร์ ผลตรวจจึงควรถูกใช้ร่วมกับการตรวจ dependency การทดสอบสิทธิ์เข้าถึง การ review โค้ด และการประเมินความปลอดภัยในระดับระบบ

สรุป

Lighthouse เปรียบเสมือนไฟฉาย ไม่ใช่ยามที่ปกป้องเว็บไซต์ได้ตลอดเวลา การเปิดใช้มันบ่อย ๆ กับหน้าสำคัญและนำหลักฐานในรายงานไปแก้ที่ต้นเหตุ จะช่วยลดความผิดพลาดและช่องโหว่พื้นฐานก่อนปล่อยระบบจริงได้อย่างคุ้มค่า คะแนนที่ดีมีประโยชน์ แต่สิ่งสำคัญกว่าคือเว็บไซต์ใช้ HTTPS อย่างถูกต้อง ไม่มี mixed content จัดการ dependency และ error อย่างรอบคอบ และขอสิทธิ์จากผู้ใช้อย่างโปร่งใส