JavaScript Analysis — Security Risks & Best Practices

Why JavaScript needs its own security check

JavaScript runs directly in a visitor's browser, which means anything written into it — including mistakes — is visible to anyone who opens their browser's developer tools. This module looks for three specific, well-known ways JavaScript quietly introduces risk.

What's checked

• Subresource Integrity (SRI) on external scripts — when your page loads a script from a third-party CDN, SRI is a checksum that guarantees the script hasn't been tampered with. Without it, if that third-party CDN is ever compromised, the malicious script would load on your site with no warning.
• eval() usage — a JavaScript function that executes arbitrary text as code. It's a common vector for injection attacks and is almost always avoidable with safer alternatives.
• Hardcoded API keys — secret keys or credentials accidentally written directly into client-side JavaScript, where they're visible to literally anyone who views the page source.
• Outdated library versions — jQuery, Bootstrap, Lodash, and AngularJS are checked against known-CVE version thresholds. Each has well-documented vulnerabilities in older releases, and the version number is typically visible right in the script filename, making this a concrete, reliably-detectable check rather than a vague "keep things updated" suggestion.

Why this matters

Hardcoded API keys are a surprisingly common and costly mistake — a key meant to stay server-side, pasted into frontend code during development and never removed, can lead to unexpected charges or data exposure once discovered by automated scanners that specifically hunt for this pattern.

How to fix it

Add SRI hashes to third-party script tags, replace eval() with safer alternatives, and move any API keys to server-side code where the browser never sees them — your developer can implement all three directly.