Reporting-API (Reporting-Endpoints) support

[bkotsopoulossc]

Problem Statement

Chrome 96 supports a new reporting API for CSP violations and other bad things. Is Sentry considering supporting this? Having a way to ingest and display these reports?

https://web.dev/reporting-api/

Solution Brainstorm

This could be similar to how sentry supports the report-uri directive, with the sentry.io/api/security/ endpoint

[bkotsopoulossc]

CC @bhollis

[AbhiPrasad]

Hey! We do support the Reporting API via ReportingObservers, but the headers sounds super interesting.

We already support a variety of headers for security reporting, and I think it would be good for us to support Reporting-Endpoints as well.

This requires changes to the Sentry product and Relay (our event ingestion system) - so I'll transfer this GH issue to that repo!

[getsentry-release]

Routing to @getsentry/ingest for triage. ⏲️

[jjbayer]

Thanks @bkotsopoulossc for reporting this! This does sound like something Sentry will support eventually. We will discuss it internally and get back to you.

[bkotsopoulossc]

That is awesome! I didn’t even realize the JS API existed. The main value I see with the header based API is for crashes. I imagine that if a browser tab crashes, it would be challenging for the browser to fire the report to a URL registered through JS. Even though the docs for the JS one mention supporting crashes, they say “and crash (although this last type usually isn't retrievable via a ReportingObserver”. Does that line up with what you’d expect as well?

[AbhiPrasad]

Does that line up with what you’d expect as well

Yup, crashes are probably the most useful thing we'd get here if we instrument this - it'll unlock a whole category of issues that previously weren't visible because we rely on JS to be running on the page.

For others who are following along, you can do this yourself while you wait for Sentry to build out a 1st class solution. You would:

1. create a reporting API endpoint of yourself, easiest is probably a serverless function
2. use a Sentry SDK with the sendEvent method that sends an event using our format (https://develop.sentry.dev/sdk/event-payloads/) to a Sentry project
   ...
3. Profit

So you would try mapping the report API format -> a Sentry event, and then sending that Sentry event to Sentry!

[bkotsopoulossc]

I love that idea! We were thinking of building a custom UI to view these events that we infest on our server but sending right back to our sentry project sounds way better!

[AbhiPrasad]

Alright some additional context when we eventually take this on. Reporting-Endpoints is the v1 header for the reporting API, the legacy reporting API, v0, was named Report-To as per: https://web.dev/reporting-api-migration/

We probably want to skip out on using Report-To and move directly to Reporting-Endpoints, no need to support legacy.

There is also Network Error Logging, which isn't supported by Reporting-Endpoints but is by Report-To. As per:

To set up Network Error Logging for your site, you will need to use the legacy Reporting API that relies on the Report-To header. This is because the new Reporting API, that relies on the Reporting-Endpoints header, does not support Network Error Logging. Learn more in Browser support. Instead, a new mechanism for Network Error Logging will be developed in the future. Once that becomes available, switch from the legacy Reporting API to that new mechanism.

We can just wait till that new mechanism is decided and use that!

Some internal links for Sentry folks - sorry open source people this has Sentry Saas customer info so we can't share them publicly.

https://getsentry.atlassian.net/browse/FEEDBACK-251 - feedback ticket about Report-To

https://sentry.zendesk.com/agent/tickets/15696 - Report-To header
https://sentry.zendesk.com/agent/tickets/18546 - report-uri deprecation
https://sentry.zendesk.com/agent/tickets/22523 - Reporting API feedback

[danielkhan]

@AbhiPrasad and @smeubank please start product discovery and pick up the existing threads on this topic as well.

[smeubank]

excuse me while I post here some musings around CSP reporting and related :)

CSP has come up in a number of different places and I believe could stand for a more holistic approach to understanding the problem space and how best to surface them to users and enable devs to use more of Sentry to make CSP events more actionable. Meaning SDK and Sentry product work

Some of these links are surely conflated, the problem space needs to be mapped out better (I need to understand it better :) ) to understand what needs to be improved from the perspective of:

• our JS browser SDKs

  • capture and send
  • what data is the most valuable?

• reporting to Sentry

  • ingestion and scrubbing the valuable data

• elevating in the product

  • what should a CSP issue look like?
  • Are there types which are only relevant at certain thresholds?
  • Metrics alert ticket below is a good example a specific use case. Can we describe more of these?

• Mark impossible CSP reports as such #31507

• Add support for CSP reports with extended effective-directive relay#1973

• [Metric Alerts] Add event.type:csp as an event filter option. #44375

• https://github.com/getsentry/customer-feedback/issues/98

• Support browser reports submitted via Reporting API #5471

• 'Unknown Content-type' when logging CSP violations in Firefox 62 #10202

[olksdr]

@AbhiPrasad @smeubank Are you actively working on this issue? Can we remove assignees?

[AbhiPrasad]

We are not actively working on this, will remove.

[guidobouman]

@danielkhan Any intentions for Sentry to put this on the roadmap somewhere soon? Right now we're building a separate lambda as per the workaround. But we have issues with Sentry marking the events originating from the lambda, instead of from the client itself.

[hubertdeng123]

Hm, not sure if there's a good product area that this should belong to, Settings - Security and Privacy seem the closest. However, the product owners there don't match up with who is responding in this thread. I'll follow up on this through a DM.

[hubertdeng123]

Looks like @danielkhan is out of office. @AbhiPrasad or @smeubank, would either of you be able to answer the question?

[AbhiPrasad]

This is a little unowned right now, but we can figure that out.

Right now we're building a separate lambda as per the workaround. But we have issues with Sentry marking the events originating from the lambda, instead of from the client itself.

@guidobouman do you mind describing this workaround and what you are doing with the lambda? How is that related to the reporting API?

[danielkhan]

I am assigning this to me for now. Let's clarify the Lambda use case as @AbhiPrasad suggested. I will discuss this with @smeubank.

[guidobouman]

As the Reporting API is not yet supported with the ingestion endpoints, we've created our own minimal endpoint in which we receive the reports and manually send that into Sentry as a workaround. It's not a bug, just a feature request, so we don't have to maintain our own custom reporting endpoint.

[guidobouman]

Basically we've implemented the workaround from @AbhiPrasad's message:

Yup, crashes are probably the most useful thing we'd get here if we instrument this - it'll unlock a whole category of issues that previously weren't visible because we rely on JS to be running on the page.

For others who are following along, you can do this yourself while you wait for Sentry to build out a 1st class solution. You would:

1. create a reporting API endpoint of yourself, easiest is probably a serverless function

2. use a Sentry SDK with the sendEvent method that sends an event using our format (https://develop.sentry.dev/sdk/event-payloads/) to a Sentry project

So you would try mapping the report API format -> a Sentry event, and then sending that Sentry event to Sentry!

One minor problem we run into is the origin of those events.

[guidobouman]

One minor problem we run into is the origin of those events.

Actually, that origin from my previous comment is more of an issue. Because we're using a service (that has its own Sentry project) as a relay for the reporting API, we have problems linking the custom sendEvent to the correct project. Right now the crash reports get connected to the service Sentry project, instead of the frontend application Sentry project.

We've managed to impersonate the other project from our service, and can now send events into sentry on behalf of another project. Still, it's a manual proxy implementation, and would prefer to actually use the Sentry reporting endpoint when possible.