การฝังตัวดูเอกสารที่ปลอดภัย: 7 คุณสมบัติสำคัญที่นักพัฒนา Front‑End มักพลาด

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

ในคู่มือนี้ เราจะพาคุณผ่าน เจ็ดความสามารถที่เน้นความปลอดภัย ที่คุณควรฝังไว้—พร้อมใช้งานทันที—เมื่อผสานรวมตัวดูเอกสารที่ให้ความเป็นส่วนตัวเป็นหลัก รายการตรวจสอบนี้เขียนสำหรับวิศวกร front‑end ที่ต้องการเสริมความปลอดภัยให้กับการฝังของตนโดยไม่เพิ่มความซับซ้อนที่ไม่จำเป็น

---

1. การเข้ารหัสแบบ End‑to‑End ของสตรีมเอกสาร

ทำไมจึงสำคัญ

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

วิธีการดำเนินการ

ขั้นตอน	การกระทำ
การเข้ารหัสฝั่งเซิร์ฟเวอร์	เข้ารหัสไฟล์ (AES‑256‑GCM เป็นตัวเลือกที่ดี) ก่อนจัดเก็บหรือสตรีม
ความปลอดภัยการส่งข้อมูล	ส่งบล็อบที่เข้ารหัสผ่าน TLS 1.3
การถอดรหัสฝั่งไคลเอนต์	สร้าง Web Worker ที่รับสตรีมที่เข้ารหัส, ถอดรหัสในหน่วยความจำ, แล้วส่งข้อความธรรมดาโดยตรงไปยัง canvas ของตัวดูเอกสาร
ห้ามเปิดเผยคีย์	เก็บคีย์การถอดรหัสในโทเคนที่สร้างโดยเซิร์ฟเวอร์และมีอายุสั้น (ดูคุณลักษณะ #4)

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

2. การกำหนดรายการขาว Content‑Security‑Policy (CSP)

ความเสี่ยง

CSP ที่ผ่อนปรนทำให้ผู้โจมตีสามารถแทรกสคริปต์อันตรายหรือโหลดทรัพยากรที่ไม่พึงประสงค์ซึ่งอาจอ่านข้อมูล canvas ของตัวดูเอกสารได้

• ‘unsafe‑inline’ และ ‘unsafe‑eval’ ไม่ได้รับอนุญาตสำหรับสคริปต์
• เฉพาะ CDN ของตัวดูเอกสาร (หรือบันเดิลที่โฮสต์เอง) เท่านั้นที่อนุญาตให้ให้บริการ JavaScript
• เฟรมถูกจำกัดให้ใช้โดเมนของตัวดูเอกสารที่เชื่อถือได้

CSP ที่เข้มงวดช่วยลดพื้นที่โจมตีของหน้าที่โฮสต์การฝังอย่างมาก

3. การแยก Same‑Origin ผ่าน iframe Sandbox

ทำไมต้องใช้ sandbox?

แม้จะมี CSP แล้ว หน้าที่ถูกทำลายอาจพยายามเข้าถึง DOM ของตัวดูเอกสาร <iframe> ที่แยกออกมาสร้าง กรงความปลอดภัย ที่หน้าโฮสต์ไม่สามารถทำลายได้หากไม่ได้รับอนุญาตอย่างชัดเจน

Sandbox flags to avoid

• allow-top-navigation – ป้องกันไม่ให้ตัวดูเอกสารขโมยการนำทางของหน้าต่างระดับบน
• allow-popups – บล็อกป๊อปอัพที่ไม่คาดคิดซึ่งอาจใช้ในการฟิชชิ่ง

หากตัวดูเอกสารต้องสื่อสารกับหน้าแม่ (เช่น เพื่อซิงค์ UI) ให้ใช้ postMessage พร้อมการตรวจสอบ origin อย่างชัดเจน

4. การควบคุมการเข้าถึงแบบใช้โทเคน

ปัญหาของ URL โดยตรง

URL สาธารณะและคงที่ทำให้ใครก็ตามที่มีลิงก์สามารถดาวน์โหลดไฟล์ได้ตลอดเวลา

เนื่องจากโทเคนถูกเซ็นจากเซิร์ฟเวอร์ การดัดแปลงใด ๆ จะทำให้คำขอไม่ถูกต้องและตัวดูเอกสารจะปฏิเสธการโหลด

5. การใส่วอเตอร์มาร์คและโอเวอร์เลย์แบบไดนามิก

จุดประสงค์

วอเตอร์มาร์คแบบไดนามิกที่ทำงานบนฝั่งไคลเอนต์เพิ่มชั้นความรับผิดชอบโดยไม่ต้องแก้ไขไฟล์ต้นฉบับ

เคล็ดลับการนำไปใช้

• แสดงวอเตอร์มาร์คบน canvas overlay ที่วางอยู่เหนือหน้าของ PDF
• ใช้อีเมลของเซสชันหรือ UUID แบบสุ่มเพื่อให้แต่ละอินสแตนซ์ของตัวดูเอกสารเป็นเอกลักษณ์
• สลับการแสดงโอเวอร์เลย์ด้วยแฟล็กง่าย ๆ เพื่อรักษาความล่าช้าของประสิทธิภาพให้ต่ำที่สุด

หากเอกสารถูกรั่วไหล ตัวระบุที่ฝังไว้จะชี้ตรงไปยังแหล่งที่มาของเอกสาร

6. การจำกัดการดาวน์โหลดและการพิมพ์

ค่าเริ่มต้นของเบราว์เซอร์

เบราว์เซอร์ส่วนใหญ่จะแสดงเมนูคลิกขวาที่สามารถบันทึก canvas เป็นภาพได้ ซึ่งเท่ากับการส่งออกหน้า

สิ่งที่ตัวดูเอกสารทำได้และทำไม่ได้

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

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

7. การบันทึกการตรวจสอบและฮุคเหตุการณ์

คุณค่าของการมองเห็น

แม้ตัวดูเอกสารที่เสริมความปลอดภัยอย่างดีที่สุดก็อาจถูกใช้งานในทางที่ผิด การบันทึกว่าผู้ใดเปิดเอกสารใด, เมื่อไหร่, และทำการอะไรบ้าง จะสร้างร่องรอยทางนิติวิทยาศาสตร์

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

สรุป

การฝังตัวดูเอกสารเป็นความรับผิดชอบด้านความปลอดภัย ไม่ใช่แค่ด้าน UI การเข้ารหัสสตรีมเอกสาร, Content‑Security‑Policy ที่เข้มงวด, iframe sandbox ที่แยกออก, การเข้าถึงแบบ ใช้โทเคน, วอเตอร์มาร์คแบบไดนามิก, การจำกัดการส่งออกที่ถือเป็น UX มากกว่าการป้องกัน, และ การบันทึกการตรวจสอบ คือสิ่งที่แยกความแตกต่างระหว่างการฝังที่คุณสามารถปกป้องได้และที่ไม่สามารถ

สองในเจ็ดข้อนี้เป็นของคุณไม่ว่าคุณจะเลือกตัวดูเอกสารใด: การให้สิทธิ์และการตรวจสอบ ไม่มีส่วนประกอบใดที่สามารถตัดสินใจแทนคุณได้สำหรับ tenancy ของคุณ

พร้อมที่จะสร้างการฝังหรือยัง?

1. เริ่มจากเอกสารของผู้ขายสำหรับเวอร์ชันที่คุณติดตั้ง สำหรับ Doconut, นั่นคือ doconut.com — แพ็กเกจ, คู่มือการตั้งค่าและตัวอย่าง การคัดลอกคีย์การกำหนดค่าจากบทความเป็นสาเหตุที่การบูรณาการล้มเหลวเมื่ออัปเกรด
2. ใส่รายการตรวจสอบ 7 จุดลงในเทมเพลต pull‑request เพื่อให้การตรวจสอบความปลอดภัยเกิดขึ้นก่อนการรวมโค้ด ไม่ใช่หลังเหตุการณ์
3. ทดสอบกรณีเชิงลบก่อน: ตัวระบุเอกสารของผู้เช่าอื่น, เซสชันที่หมดอายุ, การร้องขอโดยตรงไปยังหน้า หรือ endpoint การส่งออก สิ่งเหล่านี้คือการทดสอบที่พบช่องโหว่จริง