Don't forget about tests. That'll run code for every package that is imported. Yes, imported, because in JS importing means "run all the top level code in this file". So to continue exploiting you just place your malicious code in index.js instead of a postinstall script. Not as guaranteed to run but still very likely.

Build tooling still runs though. Your bundler plugin or PostCSS transform gets full fs access at build time, nobody's auditing that.

"First run" certainly exists in web apps, it's just running JS in a browser rather than a shell script on a developer or CI machine.

There is plenty of malicious stuff you can do from the browser.

> So for that entire class of packages this change makes them safe.

This is misleading. The change addresses one important attack vector. But if one runs the application directly on the host for development, if the package is imported like pointed out in the other comments or the package intends to steal user credentials from production, it is far from "being safe". Safer, but still needs scrutiny.

But this is npm, the execution environment is not the browser, but the server.

Most packages are imported via import/require, even if it's a browser only package. Because of SSR and reasons.

Or maybe not, let's look at a random browser only example, angular and react will use SSR, so they will execute in the server, let's check Jquery:

https://www.npmjs.com/package/jquery

Docs suggest just using a script tag instead of npm, when using npm install, they suggest to run import statement, which can execute arbitrary code.

The bottom line seems to be that if you are using npm, it's cause you are using node, and therefore you will run the imported code in the server, otherwise you would use a script tag.

But maybe there's a way to define a browser only package or .js URL such that it is only downloaded and served but never executed server side?

In any case, not a huge usecase of npm, which again, is designed for node which is backend.

Randome example,

include