1. 5
  1.  

  2. 6

    require(‘@vdeturckheim/exploic’);

    Where does that come from???

    Is this another way of saying that people who can edit th code to your app can edit the code to your app?

    1. 3

      I believe the author is pointing out a specific technique whereby a module that you require can do unexpected malicious things by hijacking the require function itself. Suppose you depend upon module A, which depends on A.1. Someone releases a new version of A.1 to hijack require so that it detects authentication modules and dynamically rewrites them to send passwords to a third party server. Because of npm’s default installation strategy, new versions of A.1 can be installed without the user’s knowledge.

      The point (I believe) is that one careless owner of a dependency deep in your dependency tree getting hacked can potentially compromise your application. If npm locked dependencies to specific versions by default this wouldn’t be as big of a problem.

      1. 7

        This is always the case in any language that evaluates code when importing a module. Whether you hijack require directly or just install malware with the current system user’s rights doesn’t matter in the end.

        1. 1

          Agreed.