CORB message on Chrome 88

Hello

We have set up DD RUM on our web application accordingly to the documentation. However we have faced some issues with ad-blockers, so as a work-around it was decided to proxy all requests targetted to DD through our server so that the URL would always contain our domain. Our default server configuration adds a few headers as a security measure, notably x-content-type-options: nosniff. Raw response from DD:

HTTP/2 200 
content-type: application/json
content-length: 2
access-control-allow-origin: *
date: Tue, 02 Mar 2021 15:19:43 GMT
via: 1.1 google
alt-svc: clear

{}

Response when going through our server:

HTTP/2 200 
date: Tue, 02 Mar 2021 15:11:53 GMT
content-type: application/json
content-length: 2
access-control-allow-origin: *
via: 1.1 google
alt-svc: clear
strict-transport-security: max-age=15724800; includeSubDomains
expect-ct: max-age=86400, enforce
referrer-policy: no-referrer
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
x-frame-options: DENY

{}

When browsing from Chrome, we are noticing a CORB message:

According to my understanding, this mecanism triggers because of the presence of X-Content-Type-Options header and because the browser assessed that there is some mismatch between the MIME type being adverdised application/json and the content {}.

The documentation mentions:

Because the JSON syntax is derived from and overlaps with JavaScript, care must be taken to handle the possibility of JavaScript/JSON polyglots. CORB handles the following cases for JSON: […] Other JSON literals: The remaining subset of the JSON syntax (for example, null or [1, 2, “3”]) also happens to be valid JavaScript syntax. In particular, when evaluated as script, they are value expressions that should have no side effects. Thus, if they can be detected, they can be CORB- protected. Detection here is possible, but requires implementing a validator that understands the full JSON syntax: […] If the response is indeed labeled with a JSON Content Type, CORB may decide to sniff the response to confirm it is valid JSON, only up to a certain number of bytes. This would avoid buffering and parsing in an unbounded amount of memory.

I don’t quite understand why this protection fires up as the content seems to be a valid JSON document and matches the MIME type being advertised. Am I missing something?

[BenoitZugmeyer]

There is no “mismatch between the MIME type and reality”. This is a Chrome bug as stated here. We might do something about it, but the best solution would be that Chrome fixes the issue.

[BenoitZugmeyer]

Please refer to the documentation