cli
cli copied to clipboard
npm
npm audit vulnerabilities categories
A package can be either a webapp (javascript) running in a browser or a backend application (node) running on a server , or both, or a component lib / framework for frontend usage, or a lib for backend usage, or a build tool etc ...
Currently i have a webapp where the build shows vulnerabilities
- i do not suceeded to remove them all
- i don't feel like it is relevent issues
I wish the npm audit could distinguish the vulnerabilities that can occur in the browser and the vulnerabilities that can occur in a server.
vulnerabilities should be categorise from the declaration. Then the user knows (writer of the package) if what he's building can/will be shipped to the browser, and filter the vulnerabilities accordingly.
For instance, 'Cross-site Scripting' is only relevant in a browser and 'Regular expression denial of service' is only relevant in a server as DoS is a server concern (or at least its severity would be lower in that case)
Vulnerabilities can happen in any environment - the CVE authors can't know which that will be.
what about 'Cross-site Scripting'... in a server ? it just cannot happen. The provider of a lib don't always know how it will be used (except the component framework case), but the final user surely does.
To be more specific 'Cross-site Scripting' would be marked as BROWSER from its specification. 'Regular expression denial of service' would be marked as SERVER When a end-user run npm audit , he can do npm audit --browser-only npm audit --server-only npm audit (would give both and this is retro-compatible)
regex DOS can be browser also, and cross-site scripting can be server too if running puppeteer or similar.
A pupeteer run would be considered as both categories in that case. A regex vulnerability on the browser would cause the browser tab to hang, but without any impact for other users, so at the end not a Denial Of Service. We took just 2 exemples and it seems not sufficient to convince in the benefits I would be interested if someone can go through all the vulnerabilities to see if that make sense for any of them.
The browser could be running WebRTC, which could indeed impact other users.
The reality is that every vuln could apply to every environment, just with different degrees of likelihood.