Hacker News new | past | comments | ask | show | jobs | submit login

Because if you ever have a broken upload system that allows you to drop a JS file somewhere accessible by the file system routing, you have remote code execution. Additionally, you now have to write guards in every non-endpoint JS file so that it doesn't get executed just by a misplaced HTTP request.

And as for automatic dependency resolution, this means you're not even aware of what transitive dependencies you're pulling in, what version they are and have no way to vet anything - everything is hidden behind a wall of magic.




Make your application directory read-only to the user running the application, as it ought to be anyway.

Automatic dependency resolution however... Fantastic for experimentation, but that's a dealbreaker for production. Maybe it would be OK if it actually wrote the package-lock.json to the application directory, I'd have to think about that.


In this case the application also tries to auto-install dependencies, so making it read-only removes one of the stated features.

I think this framework hasn't been written with security in mind at all.


Whatever it's doing, it's not writing the packages into the application directory.


If it can write to the applications dependencies isn't that as good as writing to the application?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: