The ability of script context to override its own calls is a pretty fundamental part of the web platform that allows polyfills, logging shims, and the like.

Unless a function's specification directly states that it is Unforgeable and cannot be overridden [1], I don't think there's an actual problem here. It looks like this was discussed in the past [2].

kenjibaheux@: Do you agree that this is working as expected?

[1] https://heycam.github.io/webidl/#Unforgeable
[2] https://github.com/w3c/ServiceWorker/issues/535

+Jake and Domenic in case they have opinions.

Indeed, this is working as expected. Comment #1 points to the basic reasoning. For the concrete spec text that causes these properties to be writable/configurable, see https://heycam.github.io/webidl/#define-the-operations steps 3/4.

The reproduction case involves someone running script on your page. However, if an attacker is able to run script on your page, you have already lost. Instead, ensure that attackers are not able to run JavaScript on your page.

SSL/TLS is one of many technologies to help with this. It ensures that network attackers cannot modify your page to run their own JavaScript. But it is not the right technology for protecting against other attackers; for example, if you are writing a third-party component, you are always at the mercy of the person hosting you, and if they are the attacker, then you probably shouldn't be serving them script.

Agreed. A third party script can do anything a first party script can do. Being able to overwrite `fetch` is pretty minor compared to other things it can do by design.

You can use CSP and subresource integrity to control third party resources.

I don't think this issue needs to be private.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot