The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Approve only the specific dependencies whose install hooks you have read and genuinely need, at the version you reviewed, and leave the rest blocked. npm’s documentation publishes no universal safe list, so no package gets approved because of its name or popularity. The method below is one you run against your own dependency tree. It is not an audit of a real project, and it names no packages as safe or unsafe.
The headline needs one correction: npm v12 did not stop running all scripts. It blocks install-time lifecycle scripts of dependencies unless your project’s allowScripts policy permits them. npm’s install-scripts documentation says it directly: “Dependency install scripts are blocked by default.”
As an Amazon Associate I earn from qualifying purchases.
What npm v12 actually blocks
According to npm’s current CLI documentation (which listed v12.1.0 as the latest release when this was written), the policy covers the install-time lifecycle scripts preinstall, install and postinstall. It also covers prepare for non-registry dependencies. In a project, npm reads the allowScripts field in package.json, or a policy configured in .npmrc. Matching uses the dependency’s resolved identity, not the name the package reports for itself.
It does not remove scripts you run yourself. A developer typing npm run build is not what this policy governs.
#1 Best Overall
Don’t carry v11 advice over
The npm v11.21.0 legacy documentation describes allowScripts as advisory. That release warned about unreviewed scripts, and blocking was described as future behavior. If a guide tells you a warning is harmless to ignore, it may be describing v11. In v12 the script is skipped.
The review workflow, step by step
- List what is pending. Run
npm install-scripts ls. It is read-only and lists dependencies whose install scripts are not yet covered by your policy. - Identify exactly what you have. For each entry, find the resolved package and version in your lockfile and installed tree. You are reviewing that release, not the package in general.
- Read the hook and what it calls. Open the package’s lifecycle script declarations and the files they invoke. Ask what files it writes, which network endpoints it contacts, which binaries it downloads or executes, and what environment data it reads. This checklist is general security practice. npm does not verify script behavior for you.
- Decide whether the behavior is needed. Native bindings and platform-specific setup are common legitimate reasons for an install hook. But nothing in npm’s documentation establishes that any named dependency is safe, so confirm the package source and release yourself. If the project works without the hook, leave it blocked.
- Approve narrowly. Run
npm install-scripts approve <pkg>for each reviewed package. By default npm pins the approval to the version you examined. A later version should prompt a fresh review instead of inheriting a permanent name-only approval. - Record refusals. Run
npm install-scripts deny <pkg>for packages that should stay blocked. Explicit denials surviveapprove --all, so a later blanket approval will not quietly reverse them. - Maintain the list. After dependency changes, run
npm install-scripts lsagain.npm install-scripts pruneremoves approvals and denials that no longer match an installed package with an install script. Preview withprune --dry-runfirst.
A decision framework for each pending script
| Question | If yes | If no or unclear |
|---|---|---|
| Does the project break or lose a feature without the hook? | Candidate for approval, subject to the checks below | Leave it blocked or deny it |
| Can you read the script and everything it invokes? | Continue the review | Do not approve |
| Does it fetch or run code from the network that you cannot pin or inspect? | Treat as higher risk; approve only with a clear justification | Lower concern, still read it |
| Is the resolved version the one you intend to ship? | Approve that version | Fix the dependency first, then review |
Treat npm install-scripts approve --all as a last step, not a review step. npm documents it as approving every package with unreviewed install scripts at once. It is reasonable only after your team has independently reviewed every pending package and deliberately chosen to approve them together.
Scope: project policy versus one-off flags
- Projects: use the
allowScriptsfield inpackage.jsonor the project.npmrc. - One-off and global use:
--allow-scriptsis documented for contexts such asnpm exec,npxandnpm install -g. Passing it to project-scopedinstall,ci,updateorrebuildis an error. - Workspaces: npm’s documentation says the install-scripts command is unaware of workspaces. In a monorepo, check which
package.jsonowns the policy, and don’t assume one run covered every workspace.
Enforcement settings and escape hatches
| Setting | Effect | Guidance |
|---|---|---|
strict-allow-scripts |
Turns unreviewed dependencies from warnings into install failures | Useful in CI so new unreviewed hooks cannot slip in |
--ignore-scripts |
Overrides the allowScripts policy |
Skips scripts regardless of approvals |
--dangerously-allow-all-scripts |
Overrides the policy to allow everything | npm calls it a migration escape hatch and strongly discourages it. Don’t use it as a routine fix for skipped scripts. |
One limit on what is known: npm’s documentation reports no prevalence or effectiveness statistics for install-script attacks or for this policy. Treat the approach as a way to narrow what runs on your machines, not as a guarantee against malicious packages.
Quick Recap
Rank #4
Rank #3
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
