How npm audit works, in miniature
Each advisory here is a range [from, fixed). chart-kit@3.2.0 is past its vulnerable range, but it pulls in color-parse@0.9.3, a transitive dependency you never chose. That's why audits read the lockfile (the exact tree), not package.json, and why overrides exist. Real ranges use full semver syntax, including pre-releases.
Most of your app's code was written by strangers, so keep dependencies few, locked and audited (npm audit, lockfiles, npm ci, pinning, controlled install scripts), and add browser-enforced walls: a Content Security Policy that only runs your own scripts, and Subresource Integrity for anything loaded from a CDN.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write a CI job (GitHub Actions) that installs reproducibly, fails on high-severity production vulnerabilities, and builds.
Write a starting CSP for a Vite React SPA that calls https://api.shop.example and shows images from https://img.shop.example.
You must load a chart library from a CDN. Write the tag safely, and explain the better alternative.
Explain it without notes
What is a software supply chain attack, and give three ways one can reach a React app?
What do lockfiles and npm ci protect against, and why pin versions?
What is a Content Security Policy, and why does it suit React apps?
What is Subresource Integrity, and when can't you use it?
Preview
Console
Nothing logged yet.Expected console output
high tiny-date@1.4.1 -> node_modules/tiny-date
moderate color-parse@0.9.3 -> node_modules/chart-kit/node_modules/color-parse
2 vulnerabilities