Repository: create-react-app
Issue: Help, `npm audit` says I have a vulnerability in react-scripts!
Labels: issue: announcement

### `npm audit` is broken for front-end tooling by design

Bad news, but it's true. See [here](https://overreacted.io/npm-audit-broken-by-design/) for a longer explanation.

### If you think you found a real vulnerability in `react-scripts`

If you **know** that it affects CRA users because you **understand** what the vulnerability is, report it [here](https://github.com/facebook/create-react-app/blob/master/SECURITY.md) as soon as possible.

If you're **not sure** but your CI is failing or you're worried about what `npm audit` tells you, keep reading.

**Do not** file new issues based on `npm audit` if you don't 100% understand the problem.
They will be closed (see why below). If you really need to discuss it, reply in this thread instead.

### `npm audit` says there's a warning about vulnerabilities in my project

Open `package.json`. You will find this:

```js
  "dependencies": {
    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "react-scripts": "4.0.3"
  }
```

Take `react-scripts` and **move it to `devDependencies`** (if you don't have it, create it):

```js
  "dependencies": {
    "react": "^17.0.2",
    "react-dom": "^17.0.2"
  },
  "devDependencies": {
    "react-scripts": "4.0.3"
  },
```

Then, **ensure you run `npm audit --production` rather than `npm audit.`** 

This will fix your warnings.

### But isn't this just ignoring the problem?

No.

Create React App is a **build tool**. In other words, it doesn't produce a running Node application. It runs at the build time during development, and produces static assets.

However, `npm audit` is designed for **Node apps** so it flags issues that can occur when you run actual Node code in production. That is categorically **not** how Create React App works.

This means that **the overwhelming amount of "vulnerability" reports we receive for transitive dependencies are false positives**. Despite [literally a hundred issues](https://github.com/facebook/create-react-app/issues?q=is%3Aissue+%22npm+audit%22+is%3Aclosed) with thousands of comments about `npm audit` warnings in `react-scripts`, throughout the years **not a single one of them** (to the best of our knowledge) has ever been a real vulnerability for CRA users.

This is a huge waste of everyone's time. Mostly of yours, but of ours too.

### But I still see these warnings when creating a new project or running `npm install`

Yes, unfortunately that's how `npm` works since v6. You can [bring it up with npm](https://github.com/npm/cli/issues). If enough people complain, maybe they'll rethink this decision. It is unfortunately actively hostile to build tooling.

Note that you can run `npm install --no-audit` to suppress them.

### I know the transitive dependency has a fix, how can I try it?

If you already know that `some-library@x.y.z` has the fix that you need, but `react-scripts` hasn't yet updated to it, you can try your luck using that version forcefully. With Yarn, you can do it using [resolutions](https://classic.yarnpkg.com/en/docs/selective-version-resolutions/). With npm, you might need to wait for [overrides](https://github.com/npm/rfcs/blob/latest/accepted/0036-overrides.md) or [npm audit fix overrides integration](https://github.com/npm/rfcs/blob/latest/accepted/0037-audit-overrides.md) to land first (it's not implemented yet). You can also try [npm-force-resolutions](https://www.npmjs.com/package/npm-force-resolutions).

### But can't a build tool have vulnerabilities, too?

Yes, in principle.

The few times there was an _actual_ vulnerability, it was reported separately, and we released patches as soon as it was possible. You can always report real vulnerabilities [here](https://github.com/facebook/create-react-app/blob/master/SECURITY.md), but please do this if you _understand_ the difference between a real vulnerability and a false positive. For example, a "Regex DDOS attack" can never be a real vulnerability for a development-time tool. If you're not sure, you're welcome to ask in this thread, but please keep it brief and to the point so that the thread doesn't become unreadable.

Really, the worst problem is that _when_ there is a real attack poisoning the build toolchain, we won't know about it because it will be buried underneath the 99.9% of false positives.