6/12/2023 0 Comments Web monitor alalyize response![]() You've set a Content-Security-Policy (CSP) on one of your pages, but the page is trying to load a script that's not allowed by your CSP. You're ready to start troubleshooting the problem that's affecting your users.Įxample of a situation where a report would be generated You can now access the reports on these endpoints and monitor what went wrong. The endpoint(s) receive(s) these reports. The reports are sent out-of-band by the browser itself (not by your server nor by your site). With a short delay-up to a minute-the browser then sends the reports to the endpoint that was configured for this violation type. The browser generates a CSP violation report, a Document-Policy violation report, and a Deprecation report that capture these issues. Script.js, loaded by index.html // DOCUMENT-POLICY VIOLATION: Attempt to use document.write despite the document policyĬonst webkitStorageInfo = window. Something unforeseen happens, and these policies get violated for some of your users. # these reports are always sent to the `default` endpoint # Deprecation reports don't need an explicit endpoint because Reporting-Endpoints : main-endpoint="", default="" # Content-Security-Policy violations and Document-Policy violationsĬontent-Security-Policy : script-src 'self' object-src 'none' report-to main-endpoint ĭocument-Policy : document-write=?0 report-to=main-endpoint To do so, you configure a Reporting-Endpoints header, and map these endpoint names via the report-to directive in your policies where needed. You decide to monitor your site in order to know when these policies are violated, but also because you want to keep an eye on deprecated or soon-to-be-deprecated APIs your codebase may be using. Don't know what these do? That's okay, you'll still be able to understand this example. Let's assume that your site, site.example, has a Content-Security-Policy and a Document-Policy. # Overview How reports are generated and sent. Reporting-Endpoints on this page is set to send reports to the demo reporting endpoint mentioned above. It also intentionally violates its own policies, uses deprecated APIs, and does other bad things in order to generate reports. This page uses the new Reporting API with the Reporting-Endpoints header. See the Reporting API in action starting from Chrome 96 and newer (Chrome Beta or Canary, as of October 2021). This post covers what this API can do and how to use it. Setting up the Reporting API gives you peace of mind that when users experience these types of errors, you'll know, so you can fix them. It lets you declare what you'd like to monitor via HTTP headers, and is operated by the browser. The Reporting API helps catch some of these errors-such as security violations or deprecated and soon-to-be-deprecated API calls across your site, and transmits them to an endpoint you've specified. You won't see them locally or during development because real users, real networks, and real devices change the game. If you're using the legacy Reporting API ( Report-To header), read about API migration instead.Īre you looking for Network Error Logging documentation? Head over to Network Error logging instead. This is an API guide with detailed usage examples for the Reporting API (v1), which uses the Reporting-Endpoints header.
0 Comments
Leave a Reply. |