A06 — Vulnerable & Outdated Components Insecure

Why it’s bad: old branches (like 1.x) have known issues and lack modern fixes. Plugins may rely on deprecated behaviors and keep you stuck on vulnerable code.

1. Open the insecure demo that uses jquery-1.12.4.min.js.
2. Interact with the page; note any console warnings/quirks.
3. Compare with the secure page (jQuery 3.x) to see the fixed behavior.

Why it’s bad: if the CDN or path is compromised, the browser will happily run tampered code. Without integrity, you have zero content verification.

1. Open the insecure demo; it loads a simulated “compromised” CDN script that can do anything.
2. Watch the page behavior or devtools console to see the effect.
3. Compare with the secure SRI-pinned demo on the other page.

Why it’s bad: loading http:// assets on a secure page allows on-path tampering, and modern browsers block or auto-upgrade these resources causing breakage.

1. Open the insecure demo; it attempts to pull an http:// resource.
2. Check the console for “mixed content” warnings and blocked requests.

Why it’s bad: older releases carry CVEs (e.g., prototype pollution). Keeping them around invites gadget chains and unexpected object mutation.

1. Open the insecure demo using lodash-4.17.15.min.js.
2. Follow the steps on that page to trigger the risky pattern.

Why it’s bad: @latest or floating ranges pull whatever ships next. Your build can change underneath you without review, introducing breaking changes or malware.

1. Open the insecure demo which loads an unpinned “latest.”
2. Note how you can’t verify what actually ran or reproduce the build.