ตรวจสอบเว็บแอปพลิเคชันด้วย Reporting API

ใช้ Reporting API เพื่อตรวจสอบการละเมิดความปลอดภัย การเรียก API ที่เลิกใช้งานแล้ว และอื่นๆ

Maud Nalpas

ข้อควรระวัง:

นี่คือคู่มือ API ที่มีตัวอย่างการใช้งานโดยละเอียดสำหรับ Reporting API (v1) ซึ่งใช้ส่วนหัว Reporting-Endpoints

หากคุณใช้ Reporting API แบบเดิม (Report-To header) โปรดอ่านข้อมูลเกี่ยวกับการย้ายข้อมูล API แทน

คุณกำลังมองหาเอกสารประกอบการบันทึกข้อผิดพลาดเกี่ยวกับเครือข่ายใช่ไหม โปรดไปที่การบันทึกข้อผิดพลาดเกี่ยวกับเครือข่ายแทน

ข้อผิดพลาดบางอย่างจะเกิดขึ้นในเวอร์ชันที่ใช้งานจริงเท่านั้น คุณจะไม่เห็นโฆษณาเหล่านี้ในเครื่องหรือระหว่างการพัฒนา เนื่องจากผู้ใช้จริง เครือข่ายจริง และอุปกรณ์จริง จะเปลี่ยนเกม Reporting API ช่วยตรวจหาข้อผิดพลาดบางอย่าง เช่น การละเมิดความปลอดภัย หรือการเรียก API ที่เลิกใช้งานแล้วและกำลังจะเลิกใช้งานในเว็บไซต์ของคุณ และส่งไปยังปลายทางที่คุณระบุ

ซึ่งช่วยให้คุณประกาศสิ่งที่คุณต้องการตรวจสอบโดยใช้ส่วนหัว HTTP และเบราว์เซอร์เป็นผู้ดำเนินการ

การตั้งค่า Reporting API จะช่วยให้คุณมั่นใจได้ว่าเมื่อผู้ใช้พบข้อผิดพลาดประเภทเหล่านี้ คุณจะทราบและแก้ไขได้

โพสต์นี้จะอธิบายว่า API นี้ทำอะไรได้บ้างและวิธีใช้งาน มาเริ่มกันเลย

ภาพรวม

แผนภาพสรุปขั้นตอนด้านล่าง ตั้งแต่การสร้างรายงานไปจนถึงการเข้าถึงรายงานโดยนักพัฒนาแอป — วิธีสร้างและส่งรายงาน

สมมติว่าเว็บไซต์ site.example ของคุณมี Content-Security-Policy และ Document-Policy หากไม่รู้ว่าฟังก์ชันเหล่านี้ทำอะไรได้บ้าง ไม่เป็นไร คุณจะยังคง เข้าใจตัวอย่างนี้ได้

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

โดยคุณจะต้องกำหนดค่าส่วนหัว Reporting-Endpoints และแมปชื่อปลายทางเหล่านี้โดยใช้คำสั่ง report-to ในนโยบายตามที่จำเป็น

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the `default` endpoint

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

ตัวอย่างการละเมิด

index.html

<script src="script.js"></script>
<!-- CSP VIOLATION: Try to load a script that's forbidden as per the Content-Security-Policy -->
<script src="https://example.com/script.js"></script>

script.js โหลดโดย index.html

// DOCUMENT-POLICY VIOLATION: Attempt to use document.write despite the document policy
try {
  document.write('<h1>hi</h1>');
} catch (e) {
  console.log(e);
}
// DEPRECATION: Call a deprecated API
const webkitStorageInfo = window.webkitStorageInfo;

เบราว์เซอร์จะสร้างรายงานการละเมิด CSP, รายงานการละเมิด Document-Policy และรายงานการเลิกใช้งานที่บันทึกปัญหาเหล่านี้

เบราว์เซอร์จะส่งรายงานไปยัง ปลายทางที่กำหนดค่าไว้สำหรับการละเมิดประเภทนี้หลังจากผ่านไปไม่นาน (ไม่เกิน 1 นาที) เบราว์เซอร์จะส่งรายงานนอกแบนด์ด้วยตัวเอง (ไม่ใช่เซิร์ฟเวอร์หรือเว็บไซต์ของคุณ)

อุปกรณ์ปลายทางจะได้รับรายงานเหล่านี้

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

รายงานตัวอย่าง

{
  "age": 2,
  "body": {
    "blockedURL": "https://site2.example/script.js",
    "disposition": "enforce",
    "documentURL": "https://site.example",
    "effectiveDirective": "script-src-elem",
    "originalPolicy": "script-src 'self'; object-src 'none'; report-to main-endpoint;",
    "referrer": "https://site.example",
    "sample": "",
    "statusCode": 200
  },
  "type": "csp-violation",
  "url": "https://site.example",
  "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
}

กรณีการใช้งานและประเภทรายงาน

คุณกำหนดค่า Reporting API เพื่อช่วยตรวจสอบคำเตือนหรือปัญหาที่น่าสนใจหลายประเภทซึ่งเกิดขึ้นทั่วทั้งเว็บไซต์ได้ ดังนี้

ประเภทรายงาน	ตัวอย่างสถานการณ์ที่จะมีการสร้างรายงาน
การละเมิด CSP (ระดับ 3 เท่านั้น)	คุณได้ตั้งค่า `Content-Security-Policy` (CSP) ในหน้าเว็บหน้าหนึ่ง แต่หน้าเว็บพยายามโหลดสคริปต์ที่ CSP ไม่อนุญาต
การละเมิดCOOP	คุณได้ตั้งค่า `Cross-Origin-Opener-Policy` ในหน้าเว็บ แต่หน้าต่างแบบข้ามต้นทางพยายามโต้ตอบกับเอกสารโดยตรง
การละเมิดCOEP	คุณตั้งค่า `Cross-Origin-Embedder-Policy` ในหน้าเว็บ แต่เอกสารมี iframe แบบข้ามต้นทางที่ไม่ได้เลือกให้เอกสารแบบข้ามต้นทางโหลด
การละเมิดนโยบายเอกสาร	หน้าเว็บมีนโยบายเอกสารที่ป้องกันการใช้งาน `document.write` แต่สคริปต์พยายามเรียกใช้ `document.write`
การละเมิดนโยบายสิทธิ์	หน้าเว็บมีนโยบายสิทธิ์ที่ป้องกันการใช้ไมโครโฟน และสคริปต์ที่ขออินพุตเสียง
คำเตือนการเลิกใช้งาน	หน้าเว็บใช้ API ที่เลิกใช้งานแล้วหรือจะเลิกใช้งาน โดยเรียกใช้ API นั้นโดยตรงหรือใช้สคริปต์ของบุคคลที่สามระดับบนสุด
การแทรกแซง	หน้าเว็บพยายามทำบางอย่างที่เบราว์เซอร์ตัดสินใจที่จะไม่ดำเนินการด้วยเหตุผลด้านความปลอดภัย ประสิทธิภาพ หรือประสบการณ์ของผู้ใช้ ตัวอย่างใน Chrome: หน้าเว็บใช้ `document.write` ในเครือข่ายที่ช้า หรือเรียกใช้ `navigator.vibrate` ในเฟรมข้ามต้นทางที่ผู้ใช้ยังไม่ได้โต้ตอบ
รถชน	เบราว์เซอร์ขัดข้องขณะที่เว็บไซต์ของคุณเปิดอยู่

รายงาน

รายงานมีลักษณะอย่างไร

เบราว์เซอร์จะส่งรายงานไปยังปลายทางที่คุณกำหนดค่าไว้ โดยจะส่งคำขอ ที่มีลักษณะดังนี้

POST
Content-Type: application/reports+json

เพย์โหลดของคำขอเหล่านี้คือรายการรายงาน

รายการรายงานตัวอย่าง

[
  {
    "age": 420,
    "body": {
      "columnNumber": 12,
      "disposition": "enforce",
      "lineNumber": 11,
      "message": "Document policy violation: document-write is not allowed in this document.",
      "policyId": "document-write",
      "sourceFile": "https://site.example/script.js"
    },
    "type": "document-policy-violation",
    "url": "https://site.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  },
  {
    "age": 510,
    "body": {
      "blockedURL": "https://site.example/img.jpg",
      "destination": "image",
      "disposition": "enforce",
      "type": "corp"
    },
    "type": "coep",
    "url": "https://dummy.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  }
]

ข้อมูลที่คุณดูได้ในรายงานแต่ละฉบับมีดังนี้

ช่อง	คำอธิบาย
`age`	จำนวนมิลลิวินาทีระหว่างการประทับเวลาของรายงานกับเวลาปัจจุบัน
`body`	ข้อมูลรายงานจริงที่แปลงเป็นสตริง JSON ฟิลด์ที่อยู่ใน `body` ของรายงานจะกำหนดโดย `type` ของรายงาน ⚠️ รายงานประเภทต่างๆ จะมีเนื้อหาแตกต่างกัน
`type`	ประเภทรายงาน เช่น `csp-violation` หรือ `coep`
`url`	ที่อยู่ของเอกสารหรือ Worker ที่สร้างรายงาน ระบบจะนำข้อมูลที่ละเอียดอ่อนออกจาก URL นี้ เช่น ชื่อผู้ใช้ รหัสผ่าน และส่วนย่อย
`user_agent`	`User-Agent` ส่วนหัวของคำขอที่สร้างรายงาน

รายงานที่ต้องใช้ข้อมูลเข้าสู่ระบบ

ปลายทางการรายงานที่มีต้นทางเดียวกัน กับหน้าเว็บที่สร้างรายงานจะได้รับข้อมูลเข้าสู่ระบบ (คุกกี้) ใน คำขอที่มีรายงาน

ข้อมูลเข้าสู่ระบบอาจให้บริบทเพิ่มเติมที่เป็นประโยชน์เกี่ยวกับรายงาน เช่น บัญชีของผู้ใช้ที่เฉพาะเจาะจงทําให้เกิดข้อผิดพลาดอย่างต่อเนื่องหรือไม่ หรือหาก ลําดับการดําเนินการที่เฉพาะเจาะจงในหน้าอื่นๆ ทําให้เกิดรายงานในหน้านี้

เบราว์เซอร์จะส่งรายงานเมื่อใดและอย่างไร

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

ซึ่งหมายความว่าคุณไม่ต้องกังวลเรื่องประสิทธิภาพเมื่อใช้ Reporting API

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

ปัญหาเกี่ยวกับบุคคลที่สามและบุคคลที่หนึ่ง

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

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

ตัวอย่างที่มีการเลิกใช้งาน

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

การสนับสนุนเบราว์เซอร์

ตารางต่อไปนี้สรุปการรองรับเบราว์เซอร์สำหรับ Reporting API v1 ที่มีส่วนหัว Reporting-Endpoints การรองรับเบราว์เซอร์สำหรับ Reporting API v0 (ส่วนหัว Report-To) จะเหมือนกัน ยกเว้นรายงานประเภทหนึ่งคือข้อผิดพลาดของเครือข่าย การบันทึกไม่รองรับใน Reporting API ใหม่ อ่านรายละเอียดได้ในคำแนะนำ ในการย้ายข้อมูล

ประเภทรายงาน	Chrome	Chrome iOS	Safari	Firefox	Edge
การละเมิด CSP (ระดับ 3 เท่านั้น)*	✔ ได้	✔ ได้	✔ ได้	✘ ไม่	✔ ได้
การบันทึกข้อผิดพลาดเกี่ยวกับเครือข่าย	✘ ไม่	✘ ไม่	✘ ไม่	✘ ไม่	✘ ไม่
การละเมิด COOP/COEP	✔ ได้	✘ ไม่	✔ ได้	✘ ไม่	✔ ได้
ประเภทอื่นๆ ทั้งหมด: การละเมิดนโยบายเอกสาร การเลิกใช้งาน การแทรกแซง ข้อขัดข้อง	✔ ได้	✘ ไม่	✘ ไม่	✘ ไม่	✔ ได้

ตารางนี้สรุปเฉพาะการรองรับ report-to ที่มีส่วนหัว Reporting-Endpoints ใหม่ อ่านเคล็ดลับการย้ายข้อมูลการรายงาน CSP หากคุณต้องการ ย้ายข้อมูลไปยัง Reporting-Endpoints

การใช้ Reporting API

เลือกตำแหน่งที่จะส่งรายงาน

คุณมี 2 ตัวเลือกดังนี้

ส่งรายงานไปยังบริการรวบรวมรายงานที่มีอยู่
ส่งรายงานไปยังเครื่องมือรวบรวมการรายงานที่คุณสร้างและดำเนินการด้วยตนเอง

ตัวเลือกที่ 1: ใช้บริการรวบรวมรายงานที่มีอยู่

ตัวอย่างบริการรวบรวมรายงาน ได้แก่

หากทราบวิธีแก้ปัญหาอื่นๆ โปรดเปิดปัญหาเพื่อแจ้งให้เราทราบ แล้วเราจะ อัปเดตโพสต์นี้

นอกเหนือจากราคาแล้ว ให้พิจารณาประเด็นต่อไปนี้เมื่อเลือกเครื่องมือรวบรวมรายงาน 🧐

เครื่องมือรวบรวมข้อมูลนี้รองรับรายงานทุกประเภทไหม เช่น โซลูชันปลายทางการรายงานบางอย่างไม่รองรับรายงาน COOP/COEP
คุณสะดวกใจที่จะแชร์ URL ของแอปพลิเคชันกับ ผู้รวบรวมรายงานบุคคลที่สามไหม แม้ว่าเบราว์เซอร์จะลบข้อมูลที่ละเอียดอ่อนออกจาก URL เหล่านี้ แต่ข้อมูลที่ละเอียดอ่อนอาจรั่วไหลด้วยวิธีนี้ หากคุณคิดว่าการดำเนินการนี้มีความเสี่ยงมากเกินไปสำหรับแอปพลิเคชัน ให้ใช้งานปลายทางการรายงานของคุณเอง

ตัวเลือกที่ 2: สร้างและใช้งานเครื่องมือรวบรวมรายงานของคุณเอง

การสร้างเซิร์ฟเวอร์ของคุณเองที่รับรายงานไม่ใช่เรื่องง่าย หากต้องการเริ่มต้นใช้งาน คุณสามารถ Fork บอยเลอร์เพลตแบบเบาของเราได้ สร้างขึ้นด้วย Express และ รับและแสดงรายงานได้

เมื่อสร้างเครื่องมือรวบรวมรายงานของคุณเอง ให้ทำดังนี้

มองหาคำขอ POST ที่มี Content-Type ของ application/reports+json เพื่อระบุคำขอรายงานที่เบราว์เซอร์ส่ง ไปยังปลายทางของคุณ
หากปลายทางอยู่ในต้นทางอื่นที่ไม่ใช่เว็บไซต์ของคุณ ให้ตรวจสอบว่าปลายทางนั้นรองรับคำขอ CORS Preflight

ตัวเลือกที่ 3: รวมตัวเลือกที่ 1 และ 2

คุณอาจต้องการให้ผู้ให้บริการรายใดรายหนึ่งดูแลรายงานบางประเภท แต่มีโซลูชันภายในสำหรับรายงานอื่นๆ

ในกรณีนี้ ให้ตั้งค่าปลายทางหลายรายการดังนี้

Reporting-Endpoints: endpoint-1="https://reports-collector.example", endpoint-2="https://my-custom-endpoint.example"

กำหนดค่าส่วนหัว `Reporting-Endpoints`

ตั้งค่าส่วนหัวการตอบกลับ Reporting-Endpoints ค่าต้องเป็นคู่คีย์-ค่าที่คั่นด้วยคอมมาอย่างใดอย่างหนึ่งหรือหลายรายการ

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

หากคุณย้ายข้อมูลจาก Reporting API เดิมไปยัง Reporting API ใหม่ คุณอาจต้องตั้งค่าทั้ง Reporting-Endpoints และ Report-To ดูรายละเอียดได้ในคำแนะนำในการย้ายข้อมูล โดยเฉพาะอย่างยิ่ง หากคุณใช้การรายงานการละเมิด Content-Security-Policy โดยใช้เฉพาะคำสั่ง report-uri ให้ตรวจสอบขั้นตอนการย้ายข้อมูลสำหรับการรายงาน CSP

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
Report-To: ...

คีย์ (ชื่อปลายทาง)

แต่ละคีย์อาจเป็นชื่อที่คุณเลือก เช่น main-endpoint หรือ endpoint-1 คุณสามารถเลือกตั้งค่าปลายทางที่มีชื่อต่างกันสำหรับรายงานประเภทต่างๆ ได้ เช่น my-coop-endpoint, my-csp-endpoint ซึ่งจะช่วยให้คุณ กำหนดเส้นทางรายงานไปยังปลายทางต่างๆ ได้ตามประเภทของรายงาน

หากต้องการรับรายงานการแทรกแซง การเลิกใช้งาน ข้อขัดข้อง หรือ การผสมผสานของรายงานเหล่านี้ ให้ตั้งค่าปลายทางชื่อ default

หากส่วนหัว Reporting-Endpoints ไม่ได้กำหนดปลายทาง default ระบบจะไม่ส่งรายงานประเภทนี้ (แม้ว่าจะมีการสร้างรายงานก็ตาม)

ประเด็นสำคัญ: แม้จะมีชื่อว่า default แต่ก็ไม่ใช่ปลายทางสำรอง ตัวอย่างเช่น หากคุณตั้งค่า report-to my-endpoint สำหรับ Document-Policy และไม่ได้กำหนด my-endpoint ใน Reporting-Endpoints ระบบจะสร้างรายงานการละเมิด Document-Policy แต่จะไม่ส่งเนื่องจากเบราว์เซอร์ไม่ทราบว่าจะส่งไปที่ใด

ค่า (URL)

ค่าแต่ละค่าคือ URL ที่คุณเลือกซึ่งจะใช้เป็นปลายทางในการส่งรายงาน URL ที่จะตั้งค่าที่นี่ขึ้นอยู่กับสิ่งที่คุณตัดสินใจในขั้นตอนที่ 1

URL ปลายทาง

ต้องขึ้นต้นด้วยเครื่องหมายทับ (/) ไม่รองรับเส้นทางที่เกี่ยวข้อง
อาจเป็นแบบข้ามต้นทาง แต่ในกรณีนี้ระบบจะไม่ส่งข้อมูลเข้าสู่ระบบพร้อมกับรายงาน

ตัวอย่าง

Reporting-Endpoints: my-coop-endpoint="https://reports.example/coop", my-csp-endpoint="https://reports.example/csp", default="https://reports.example/default"

จากนั้นคุณจะใช้แต่ละปลายทางที่มีชื่อในนโยบายที่เหมาะสม หรือใช้ปลายทางเดียวในนโยบายทั้งหมดก็ได้

จะตั้งค่าส่วนหัวได้ที่ไหน

ใน Reporting API ใหม่ ซึ่งเป็น API ที่กล่าวถึงในโพสต์นี้ รายงานจะกำหนดขอบเขตไว้ที่เอกสาร ซึ่งหมายความว่าสำหรับต้นทางหนึ่งๆ เอกสารต่างๆ เช่น site.example/page1 และ site.example/page2 สามารถ ส่งรายงานไปยังปลายทางที่แตกต่างกันได้

หากต้องการรับรายงานการละเมิดหรือการเลิกใช้งานที่เกิดขึ้นในหน้าใดก็ตามของเว็บไซต์ ให้ตั้งค่าส่วนหัวเป็นมิดเดิลแวร์ในการตอบกลับทั้งหมด

ตัวอย่างใน Express

const REPORTING_ENDPOINT_BASE = 'https://report.example';
const REPORTING_ENDPOINT_MAIN = `${REPORTING_ENDPOINT_BASE}/main`;
const REPORTING_ENDPOINT_DEFAULT = `${REPORTING_ENDPOINT_BASE}/default`;

app.use(function (request, response, next) {
  // Set up the Reporting API
  response.set(
    'Reporting-Endpoints',
    `main-endpoint="${REPORTING_ENDPOINT_MAIN}", default="${REPORTING_ENDPOINT_DEFAULT}"`,
  );
  next();
});

หมายเหตุ: การดำเนินการนี้แตกต่างจาก Reporting API แบบเดิม (ส่วนหัว Report-To) ซึ่งคุณ สามารถตั้งค่าปลายทาง "โดยรอบ" สำหรับหน้าเว็บหนึ่งหน้า และรับรายงานสำหรับ หน้าเว็บใดก็ได้ในต้นทางเดียวกันโดยอัตโนมัติ หากคุณกำลังย้ายข้อมูลจาก Reporting API เดิม ไปยัง Reporting API ใหม่ โปรดดูคำแนะนำในการย้ายข้อมูล

แก้ไขนโยบาย

เมื่อกำหนดค่าส่วนหัว Reporting-Endpoints แล้ว ให้เพิ่มคำสั่ง report-to ลงในส่วนหัวของนโยบายแต่ละรายการที่คุณต้องการรับรายงานการละเมิด ค่าของ report-to ควรเป็นหนึ่งในปลายทางที่มีชื่อที่คุณกำหนดค่าไว้

คุณใช้ปลายทางหลายรายการสำหรับนโยบายหลายรายการ หรือใช้ปลายทางที่แตกต่างกันในนโยบายได้

สําหรับแต่ละนโยบาย ค่าของ report-to ควรเป็นปลายทางที่มีชื่อที่คุณกําหนดค่าไว้

ไม่จำเป็นต้องใช้ report-to สำหรับรายงานการเลิกใช้งาน การแทรกแซง และข้อขัดข้อง รายงานเหล่านี้ไม่ได้เชื่อมโยงกับนโยบายใดๆ ระบบจะสร้างข้อมูลนี้ตราบใดที่ ตั้งค่าdefaultปลายทางและส่งไปยังdefaultปลายทางนี้

ตัวอย่าง

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0;report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the default endpoint

คำเตือน: การใช้ไวยากรณ์ report-to ให้ถูกต้องอาจเป็นเรื่องยาก เนื่องจากนโยบายบางอย่างไม่ได้ใช้ โครงสร้างส่วนหัวเดียวกัน ไวยากรณ์ที่ถูกต้องอาจเป็น report-to=main-endpoint หรือ report-to main-endpoint

โดยขึ้นอยู่กับนโยบาย

แก้ไขข้อบกพร่องในการตั้งค่าการรายงาน

สร้างรายงานโดยเจตนา

เมื่อตั้งค่า Reporting API คุณอาจต้องจงใจละเมิดนโยบาย เพื่อตรวจสอบว่าระบบสร้างและส่งรายงานตามที่คาดไว้หรือไม่

ประหยัดเวลา

ระบบอาจส่งรายงานโดยมีความล่าช้าประมาณ 1 นาที ซึ่งถือเป็นเวลานาน เมื่อทำการแก้ไขข้อบกพร่อง 😴 โชคดีที่เมื่อแก้ไขข้อบกพร่องใน Chrome คุณสามารถใช้ค่าสถานะ --short-reporting-delay เพื่อรับรายงานทันทีที่ระบบสร้างรายงาน

เรียกใช้คำสั่งนี้ในเทอร์มินัลเพื่อเปิดใช้ฟีเจอร์นี้

YOUR_PATH/TO/EXECUTABLE/Chrome --short-reporting-delay

ใช้เครื่องมือสำหรับนักพัฒนาเว็บ

ใน Chrome ให้ใช้ DevTools เพื่อดูรายงานที่ส่งแล้วหรือจะส่ง

ฟีเจอร์นี้ยังอยู่ในขั้นทดลอง ณ เดือนตุลาคม 2021 หากต้องการใช้ฟีเจอร์นี้ ให้ทำตามขั้นตอนต่อไปนี้

ใช้ Chrome เวอร์ชัน 96 ขึ้นไป (ตรวจสอบโดยพิมพ์ chrome://version ใน เบราว์เซอร์)
พิมพ์หรือวาง chrome://flags/#enable-experimental-web-platform-features ในแถบที่อยู่ของ Chrome
คลิกเปิดใช้
รีสตาร์ทเบราว์เซอร์
เปิดเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
เปิดการตั้งค่าในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ในส่วนการทดสอบ ให้คลิกเปิดใช้แผง Reporting API ในแผงแอปพลิเคชัน
โหลดเครื่องมือสำหรับนักพัฒนาเว็บซ้ำ
โหลดหน้าเว็บซ้ำ รายงานที่สร้างขึ้นโดยหน้าเครื่องมือสำหรับนักพัฒนาเว็บจะเปิดขึ้นในแผงแอปพลิเคชันของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ภายในReporting API

ภาพหน้าจอของเครื่องมือสำหรับนักพัฒนาเว็บที่แสดงรายงาน — เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome จะแสดงรายงานที่สร้างขึ้นในหน้าเว็บและสถานะของรายงาน

สถานะรายงาน

คอลัมน์สถานะจะแจ้งให้ทราบว่าระบบส่งรายงานสำเร็จหรือไม่

สถานะ	คำอธิบาย
`Success`	เบราว์เซอร์ได้ส่งรายงานแล้ว และปลายทางตอบกลับด้วยรหัสที่ระบุความสำเร็จ (`200` หรือรหัสการตอบกลับที่ระบุความสำเร็จอื่นๆ `2xx`)
`Pending`	เบราว์เซอร์กำลังพยายามส่งรายงาน
`Queued`	ระบบได้สร้างรายงานแล้วและเบราว์เซอร์ไม่ได้พยายามส่งรายงาน รายงานจะปรากฏเป็น `Queued` ในกรณีใดกรณีหนึ่งต่อไปนี้ รายงานนี้เป็นรายงานใหม่และเบราว์เซอร์กำลังรอเพื่อดูว่ามีรายงานเพิ่มเติมมาถึงหรือไม่ก่อนที่จะพยายามส่ง รายงานไม่ใช่รายงานใหม่ เบราว์เซอร์พยายามส่งรายงานนี้แล้วแต่ไม่สำเร็จ และกำลังรอเพื่อลองอีกครั้ง
`MarkedForRemoval`	หลังจากลองส่งอีกครั้งสักพัก (`Queued`) เบราว์เซอร์ได้หยุดพยายามส่งรายงานแล้ว และจะนำรายงานออกจากรายการรายงานที่จะส่งในเร็วๆ นี้

ระบบจะนำรายงานออกหลังจากผ่านไปสักระยะ ไม่ว่าจะส่งสำเร็จหรือไม่ก็ตาม

ประเด็นสำคัญ: สถานะQueuedไม่ได้ให้ข้อมูลเสมอไป เนื่องจากไม่ได้ระบุอย่างชัดเจนว่าการส่งล้มเหลวหรือยังไม่ได้ลองส่ง การใช้ความล่าช้าในการรายงานสั้นๆ จะช่วยให้รายงานที่ยังคงQueuedในกรณีนั้นๆ มีแนวโน้มที่จะบ่งบอกว่าการส่งล้มเหลว

การแก้ปัญหา

ระบบไม่สร้างรายงานหรือไม่ได้ส่งไปยังปลายทางตามที่คาดไว้ใช่ไหม เคล็ดลับบางส่วนในการแก้ปัญหานี้มีดังนี้

ระบบไม่สร้างรายงาน

รายงานที่แสดงในเครื่องมือสำหรับนักพัฒนาเว็บได้รับการสร้างอย่างถูกต้อง หากรายงานที่คุณคาดหวังไม่ปรากฏในรายการนี้ ให้ทำดังนี้

ดูreport-toในนโยบาย หากกำหนดค่าไม่ถูกต้อง ระบบจะไม่สร้างรายงาน ไปที่แก้ไขนโยบายเพื่อแก้ไขปัญหานี้ อีกวิธีในการแก้ปัญหานี้คือการตรวจสอบคอนโซล DevTools ใน Chrome หากมีข้อผิดพลาดปรากฏในคอนโซลสำหรับการละเมิดที่คุณ คาดไว้ แสดงว่าอาจมีการกำหนดค่านโยบายอย่างถูกต้อง
โปรดทราบว่าเฉพาะรายงานที่สร้างขึ้นสำหรับเอกสารที่เปิดใน DevTools เท่านั้นที่จะแสดงในรายการนี้ ตัวอย่างเช่น หากเว็บไซต์ของคุณ site1.exampleฝัง iframe site2.example ที่ละเมิดนโยบายและ ทำให้เกิดรายงาน รายงานนี้จะแสดงในเครื่องมือสำหรับนักพัฒนาเว็บก็ต่อเมื่อคุณ เปิด iframe ในหน้าต่างของตัวเองและเปิดเครื่องมือสำหรับนักพัฒนาเว็บสำหรับหน้าต่างนั้น

ระบบสร้างรายงานแล้วแต่ไม่ได้ส่งหรือไม่ได้รับ

จะเกิดอะไรขึ้นหากคุณเห็นรายงานในเครื่องมือสำหรับนักพัฒนาเว็บ แต่ปลายทางไม่ได้รับรายงาน

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

โปรดใช้การหน่วงเวลาสั้นๆ สาเหตุที่คุณไม่เห็นรายงานอาจเป็นเพราะยังไม่มีการส่งรายงาน
ตรวจสอบการกำหนดค่าส่วนหัว Reporting-Endpoints หากมีปัญหา กับรายงาน ระบบจะไม่ส่งรายงานที่สร้างอย่างถูกต้อง ในเครื่องมือสำหรับนักพัฒนาเว็บ สถานะของรายงานจะยังคงเป็น Queued (อาจเปลี่ยนเป็น Pending แล้วกลับไปเป็น Queued อย่างรวดเร็วเมื่อมีการพยายามนำส่ง) ในกรณีนี้ ข้อผิดพลาดที่พบบ่อยซึ่งอาจทำให้เกิดปัญหานี้มีดังนี้
มีการใช้ปลายทางแต่ไม่ได้กำหนดค่า ตัวอย่าง

รหัสที่มีข้อผิดพลาด

 Document-Policy: document-write=?0;report-to=endpoint-1;
 Reporting-Endpoints: default="https://reports.example/default"

ควรรายงานการละเมิด Document-Policy ไปที่ endpoint-1 แต่ไม่ได้กำหนดค่าชื่อปลายทางนี้ใน Reporting-Endpoints

ไม่มีปลายทาง default ระบบจะส่งรายงานบางประเภท เช่น รายงานการเลิกใช้งาน และการแทรกแซง ไปยังปลายทางที่ชื่อ default เท่านั้น อ่านเพิ่มเติมได้ที่กำหนดค่าส่วนหัว Reporting-Endpoints
มองหาปัญหาในไวยากรณ์ของส่วนหัวนโยบาย เช่น เครื่องหมายคำพูดที่ขาดหายไป ดู รายละเอียด
ตรวจสอบว่าปลายทางของคุณจัดการคำขอที่เข้ามาได้
- ตรวจสอบว่าปลายทางรองรับคำขอ CORS Preflight หากไม่ได้เปิดใช้ ก็จะรับรายงานไม่ได้
- ทดสอบลักษณะการทำงานของปลายทาง หากต้องการทำเช่นนั้น คุณสามารถจำลองเบราว์เซอร์ได้โดยการส่งคำขอที่ดูเหมือนสิ่งที่เบราว์เซอร์จะส่งไปยังอุปกรณ์ปลายทางแทนที่จะสร้างรายงานด้วยตนเอง เรียกใช้ คำสั่งต่อไปนี้
```
curl --header "Content-Type: application/reports+json" \
  --request POST \
  --data '[{"age":420,"body":{"columnNumber":12,"disposition":"enforce","lineNumber":11,"message":"Document policy violation: document-write is not allowed in this document.","policyId":"document-write","sourceFile":"https://dummy.example/script.js"},"type":"document-policy-violation","url":"https://dummy.example/","user_agent":"xxx"},{"age":510,"body":{"blockedURL":"https://dummy.example/img.jpg","destination":"image","disposition":"enforce","type":"corp"},"type":"coep","url":"https://dummy.example/","user_agent":"xxx"}]' \
  YOUR_ENDPOINT
```
ปลายทางควรตอบกลับด้วยรหัสที่ระบุความสำเร็จ (200 หรือรหัสการตอบกลับที่ระบุความสำเร็จอื่นๆ 2xx) หากไม่เป็นเช่นนั้น แสดงว่าการกำหนดค่ามีปัญหา

กลไกการรายงานที่เกี่ยวข้อง

รายงานเท่านั้น

-Report-Only ส่วนหัวของนโยบายและ Reporting-Endpoints ทำงานร่วมกัน

อุปกรณ์ปลายทางที่กำหนดค่าใน Reporting-Endpoints และระบุในฟิลด์ report-to ของ Content-Security-Policy Cross-Origin-Embedder-Policy และ Cross-Origin-Opener-Policy จะได้รับรายงานเมื่อมีการละเมิดนโยบายเหล่านี้

คุณยังระบุปลายทางที่กำหนดค่าไว้ใน Reporting-Endpoints ได้ในฟิลด์ report-to ของ Content-Security-Policy-Report-Only Cross-Origin-Embedder-Policy-Report-Only และ Cross-Origin-Opener-Policy-Report-Only นอกจากนี้ ผู้ดูแลระบบยังจะได้รับรายงานเมื่อมีการละเมิดนโยบายเหล่านี้ด้วย

แม้ว่าระบบจะส่งรายงานในทั้ง 2 กรณี แต่ส่วนหัว -Report-Only จะไม่บังคับใช้นโยบาย: จะไม่มีสิ่งใดหยุดทำงานหรือถูกบล็อกจริง แต่คุณจะได้รับรายงานเกี่ยวกับสิ่งที่อาจหยุดทำงานหรือถูกบล็อก

หมายเหตุ: หากคุณใช้ส่วนหัว -Report-Only และกําหนดค่าปลายทางการรายงานโดยใช้ส่วนหัวเดิม Report-To ให้ย้ายข้อมูลไปยัง Reporting-Endpoints หากทําได้ อ่านเพิ่มเติมในคำแนะนำในการย้ายข้อมูล

`ReportingObserver`

ReportingObserver JavaScript API ช่วยให้คุณสังเกตคำเตือนฝั่งไคลเอ็นต์ได้

ReportingObserver และส่วนหัว Reporting-Endpoints จะสร้างรายงานที่มีลักษณะเหมือนกัน แต่จะเปิดใช้กรณีการใช้งานที่แตกต่างกันเล็กน้อย

ใช้ ReportingObserver ในกรณีต่อไปนี้

คุณต้องการตรวจสอบเฉพาะการเลิกใช้งานหรือการแทรกแซงของเบราว์เซอร์ ReportingObserver แสดงคำเตือนฝั่งไคลเอ็นต์ เช่น การเลิกใช้งาน และการแทรกแซงของเบราว์เซอร์ แต่ต่างจาก Reporting-Endpoints ตรงที่ไม่ได้ บันทึกรายงานประเภทอื่นๆ เช่น การละเมิด CSP หรือ COOP/COEP
คุณต้องตอบสนองต่อการละเมิดเหล่านี้แบบเรียลไทม์ ReportingObserver ทำให้แนบ การเรียกกลับกับ เหตุการณ์การละเมิดได้
คุณต้องการแนบข้อมูลเพิ่มเติมในรายงานเพื่อช่วยในการแก้ไขข้อบกพร่อง โดยใช้callback ที่กำหนดเอง

ความแตกต่างอีกอย่างคือ ReportingObserver จะได้รับการกำหนดค่าฝั่งไคลเอ็นต์เท่านั้น คุณใช้ได้แม้ว่าจะไม่มีสิทธิ์ควบคุมส่วนหัวฝั่งเซิร์ฟเวอร์และตั้งค่า Reporting-Endpoints ไม่ได้

อ่านเพิ่มเติม

รูปภาพหลักโดย Nine Koepfer / @enka80 ใน Unsplash (แก้ไขแล้ว) ขอขอบคุณ Ian Clelland, Eiji Kitamura และ Milica Mihajlija สำหรับการตรวจสอบและคำแนะนำ ในเอกสารนี้

ภาพรวม

กรณีการใช้งานและประเภทรายงาน

รายงาน

รายงานมีลักษณะอย่างไร

รายงานที่ต้องใช้ข้อมูลเข้าสู่ระบบ

เบราว์เซอร์จะส่งรายงานเมื่อใดและอย่างไร

ปัญหาเกี่ยวกับบุคคลที่สามและบุคคลที่หนึ่ง

ตัวอย่างที่มีการเลิกใช้งาน

การสนับสนุนเบราว์เซอร์

การใช้ Reporting API

เลือกตำแหน่งที่จะส่งรายงาน

ตัวเลือกที่ 1: ใช้บริการรวบรวมรายงานที่มีอยู่

ตัวเลือกที่ 2: สร้างและใช้งานเครื่องมือรวบรวมรายงานของคุณเอง

ตัวเลือกที่ 3: รวมตัวเลือกที่ 1 และ 2

กำหนดค่าส่วนหัว Reporting-Endpoints

คีย์ (ชื่อปลายทาง)

ค่า (URL)

ตัวอย่าง

จะตั้งค่าส่วนหัวได้ที่ไหน

แก้ไขนโยบาย

ตัวอย่าง

แก้ไขข้อบกพร่องในการตั้งค่าการรายงาน

สร้างรายงานโดยเจตนา

ประหยัดเวลา

ใช้เครื่องมือสำหรับนักพัฒนาเว็บ

สถานะรายงาน

การแก้ปัญหา

ระบบไม่สร้างรายงาน

ระบบสร้างรายงานแล้วแต่ไม่ได้ส่งหรือไม่ได้รับ

กลไกการรายงานที่เกี่ยวข้อง

รายงานเท่านั้น

ReportingObserver

อ่านเพิ่มเติม

กำหนดค่าส่วนหัว `Reporting-Endpoints`

`ReportingObserver`