On various security forums I have seen links to a post about a fictive malicious NPM package harvesting information. The posts title:

I’m harvesting credit card numbers and passwords from your site. Here’s how.

The best quote in the post in my opinion:

Lucky for me, we live in an age where people install npm packages like they’re popping pain killers.

This led to a discussion at our company whether or not a malicious NPM Package would fit into OWASP Top Ten 2017 or not. I think it could fit into the following categories:

  • A6:2017-Security Misconfiguration
    The description says: "Not only must all operating systems, frameworks, libraries, and applications be securely configured...". If you have a malicious library that can do something because your CSP is not configured correctly for example I would have it fall under this category.

  • A7:2017-Cross-Site Scripting (XSS)
    If the library enables an XSS vulnerability it would fall under this category.

  • A9:2017-Using Components with Known Vulnerabilities
    If the library is known to be malicious it would fall under this category.

  • A10:2017-Insufficient Logging&Monitoring
    If the attack is not detected it means we are not logging enough. There are various libraries for logging Client-Side JavaScript and outgoing requests could be checked here. Of course the malicious library could try to disable this but it could still fall under this category.

Is this correct or is a malicious NPM package outside the scope of OWASP Top Ten 2017?

  • Why does this threat have to be covered by the OWASP Top 10? The Top 10 is not the important things that you need to address to the exclusion of other known threats, but the most common problems seen in practice.
    – schroeder
    Commented Jan 10, 2018 at 9:53
  • I hope your dev team is not focusing on the Top 10 as the sole scope of threat analysis and mitigation.
    – schroeder
    Commented Jan 10, 2018 at 9:54
  • @schroeder Does not have to be, the question is if it is. Simple as that and nothing about exclusions.
    – Ogglas
    Commented Jan 10, 2018 at 9:55
  • @schroeder We use the Top 10 as a base for our web applications but of course we do not exclude vulnerabilities that could be outside the scope.
    – Ogglas
    Commented Jan 10, 2018 at 9:56
  • 1
    Then I'm afraid that this might be akin to trying to count "how many angels can dance on the head of a pin". I could replace my entire answer below with "no" because it is not a common threat seen in practice, which is a core requirement for something to rank on the OWASP T10.
    – schroeder
    Commented Jan 10, 2018 at 10:01

1 Answer 1


It seems clear to me that a maliciously coded library is perfectly covered by A9:2017-Using Components with Known Vulnerabilities. I thought that A9 was created for this very use case.

Although the wording from OWASP talks about older libraries that have vulnerabilities discovered over time (Heartbleed) and replaced, there is nothing in the wording that suggests that this must be the reason for the vulnerability. Intentional malicious coding works just as well as a reason.

A debate might arise over whether or not "malicious coding" can be equated to a "vulnerability" since the malicious code could be working as intended without unintended effects. I think this debate is a little pedantic and the spirit of the OWASP Top 10 is supported by equating the two ideas.

Maliciously coded libraries are not a "misconfiguration". A misconfigured library is one that is not vulnerable, per se, but introduces vulnerabilities due to misuse.

Maliciously coded libraries could introduce XSS vulnerabilities, but A7 is too specific in this case.

Insufficient Logging and Monitoring is a meta issue that affects all potential situations and is too broad to be applicable to this threat scenario.

  • I am tempted to agree with you, but I'm not sure if the mitigations prescribed for A9 apply to this trojan horse scenario. Commented Jan 10, 2018 at 9:48
  • @NisargShah I hear you, but the mitigations are meant to be suggestions and guidelines, not strict implementations.
    – schroeder
    Commented Jan 10, 2018 at 9:50
  • @NisargShah "Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component." Although this is tangential, it touches on what I'm talking about
    – schroeder
    Commented Jan 10, 2018 at 9:51
  • 3
    Yup, I can understand your reasoning. But given that the vulnerability is not known and that the mitigations don't work for this problem, I would say that this scenario is not covered. Although, as you mentioned in your comment, whether OWASP explicitly covers this or not, is not important. Commented Jan 10, 2018 at 9:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .