What if it will be used by malicious code injected by browser extension or XSS?

[JustFly1984]

How do you debug network requests made by code in hidden functions? what if malicious code is in XSS injected service worker, with hidden source code?

[JustFly1984]

What if there is a bug in hidden 3rd party source? how do you debug that case?

[bathos]

Questions regarding third party source have been / are being discussed in other threads, but the browser extension concern is new I think. It’s an interesting concern.

Browser extensions can inject content scripts that are guaranteed to run before any of the site’s own code. They can circumvent CSPs and other protections the site’s authors intended to provide their users and they can patch the environment to achieve pretty much any goal. All security in an ES realm belongs to ‘whoever got there first’. It’s a problem, for sure, but I’m not sure I can think of any cases where these directives bear on the situation because they wouldn’t actually provide any new capabilities to content scripts.

These directives do provide a new primitive capability, but it is not ‘hiding source’ or ‘redacting stacks’. These things are themselves already achievable with JS. The new primitive capability is only that one could ensure that they occur even in a realm where other code has already been evaluated. By virtue of assured first-run-code status, a content script can already reliably achieve the behaviors of both directives through aggressive environmental patching without being observed; the directives would only make this (considerably more) convenient to achieve.

At least, this is my analysis of it — do you know of any new capability this would offer extensions which I’m missing?

[JustFly1984]

@bathos ok, now I want to have immutable functions proposal. for all production deployed code. Forbid to mutate functions.

Bye bye polyfills for any money related business. That is a news for me that browser extensions can bypass CSP. Fucking scary! Is there any reason to setup CSP initially? or is it just hype around subscription to notification service?

Browser extensions is one of main reasons why I'm against storing auth tokens in localStorage or session storage.

Architecture of the web is missing Security by default, and it is freaking killing me.

Couple years ago a heard about some browser extensions which mess with cookies an amazon, and also I constantly hearing about some custom self-signed extensions (installed without google extension library) causing errors on websites, and messing with css and DOM too. In my logs too.

[nicolo-ribaudo]

ok, now I want to have immutable functions proposal.

It's already there!

Object.defineProperty(globalThis, "Array", { writable: false, configurable: false })
Object.defineProperty(Array, "from", { writable: false, configurable: false })
Object.freeze(Array.from);

[michaelficarra]

See https://github.com/tc39/proposal-function-implementation-hiding#how-does-this-affect-devtools-or-other-methods-of-inspecting-a-functions-implementation-details.

[bathos]

Is there any reason to setup CSP initially? or is it just hype around subscription to notification service?

@JustFly1984 A restrictive CSP is potentially very valuable. Although the browser extension hole exists, security-in-practice depends more on mitigation strategies than achieving perfection. It is frustrating that we can’t make a true guarantee about what code is running on our own sites, but extensions are a user’s explicit choice, and in general if they’re found to be malicious, vendors pull/block them. Loading unpacked extensions is possible but not super common afaik — partly because e.g. in Chrome, users have to enable development mode and then they will see a warning about it every time Chrome opens (not just when they first install it).

You are definitely correct to not store auth tokens in localStorage. The storage APIs aren’t intended for use with sensitive data. Cookies can be sensitive, but only with httponly.

My understanding is that newer APIs, like fetch, have been aiming for secure-by-default behavior where possible, but that existing web content precludes making many security measures default — hence explicit opt-in APIs like CSPs, feature-policy, etc.

Hopefully things will continue improving. This particular proposal concerns a feature that would enable some code to become more secure; that’s one of its motivating cases.