Security proposition

Problem:

node-postgres depends (directly and recursively) on 16 other packages. May any of these become controlled by an attacker, the baddies can easily control your application’s backend via node-postgres.

This is well-known and serious attack:

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

https://schneid.io/blog/event-stream-vulnerability-explained/

It scares me anytime I hit npm install.

Solution:

Most of the dependencies have quite short codes, so it’s trivial to ‘embed’ them to the project directly. I consider success even partial dependency elimination, as it reduces the attack surface.

Realization:

If agreed, I’m happy to do the change and submit PR.

[abenhamdine]

I’m more than a little confused and this is probably not the right place but wanted to surface it at least somewhere; there’s a npm package called node-postgres which is not this pg package npmjs.com/package/node-postgres. Aside from general confusion, just wanted to make sure you’re aware of this and the potential for users to be misled.

Definitely worrying to see that. Name usurpation/confusion is obviously an easy vector attack.

[benjie]

Agree with @charmander (except using yarn.lock); vendoring non-trivial dependencies raises issues due to using stale code which may have vulnerabilities in - it massively increases the work required of the maintainer to keep things up to date and makes it harder for users to patch their own systems using tools like Snyk to upgrade/patch certain dependencies.

When you run code in the node ecosystem, using a lockfile is critical, and when you upgrade modules you should review their changelogs and ensure they’re safe.