node.js - How to send Reporting API reports cross-origin (Report-To) header - TagMerge
3How to send Reporting API reports cross-origin (Report-To) headerHow to send Reporting API reports cross-origin (Report-To) header

How to send Reporting API reports cross-origin (Report-To) header

Asked 1 years ago
3 answers

Your code appears to be correct, but there is currently a bug in Chrome/Chromium's implementation of CORS for the Reporting API, which is likely to be causing your problem. See Chromium issue #1152867. The gist of the bug is that the CORS implementation used here requires that an Access-Control-Allow-Methods: POST header exists on the response, which is not compliant with the CORS spec, as POST is a "simple" method.

If you are able to modify the CORS implementation on your server, you can modify it to always include the Access-Control-Allow-Methods: POST header on the OPTIONS response, which should work around the bug.

Otherwise, you will have to either not use a cross-domain request for reporting, or fall back to only using the deprecated Report-Uri directive until the fix is released. The latter shouldn't be too much of an issue, as Firefox and Safari don't support the new Report-To header yet anyway.

Source: link


CSP reporting API is not a subject of CORS, because no resources are loaded from the server. Browser just send a report and does not expect any headers/response from CSP reporting API. To show this you return the 204 No content header so that the browser does not expect a response.

Why do you think that you have a CORS issue? When you proxying site via, it injects into all pages a NEL/Report-to (the same as CSP/Report-to) headers with CF's own domain without any CORS issue: enter image description here I had implemented a lot of endpoints for report-uri and never face any CORS issues.

Note that report-uri is obsolete in favour report-to directive, but browsers does not supports report-to except Chrome.

When you simulate sending a report for testing purposes, do not use an ordinary ajax POST request - it is subject to CORS.
To imitate sending real report, generate a page on third-party domain:

<script>alert('inline success')</script>

and send it with CSP header:

Content-Security-Policy: "default-src 'report-sample' report-uri;"

When debug it's easier to use report-uri not report-to.

Source: link


When configured with a report-to directive, CSP reports will use the Reporting API to send the reports. The browser will require CORS for cross-origin reports in that case, and it's possible that your server is not correctly configured to negotiate CORS on that URL. (I don't know the details of the npm package you're using, but that would be my suspicion).

The browser will send a pre-flight request of the form:

OPTIONS /csp-report HTTP/1.1
Access-Control-Request-Headers: content-type
Access-Control-Request-Method: POST

And your server needs to respond with something like:

200 OK HTTP/1.1
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Methods: POST
Access-Control-Max-Age: 3600

If that happens, then the second request (with the actual report) will be sent.

The Chrome NetLog viewer can be useful for debugging these sorts of problems.

As well, recent versions of Chrome have experimental support in DevTools for Reporting. You should be able to see configured endpoints, as well as reports which have been queued. (Chrome 96 instructions: Open devtools, click the gear icon for settings, and under "experiments" there is an option labeled "Enable Reporting API panel in the Application panel")

Source: link

Recent Questions on node.js

    Programming Languages