Safe External JavaScript Integration

TL;DR

Integrating external JavaScript can boost your website’s features but introduces security risks. This guide covers best practices to minimise those risks, focusing on Content Security Policy (CSP), Subresource Integrity (SRI), and careful script selection.

1. Understand the Risks

External scripts come from sources you don’t directly control. They could be:

• Malicious: Containing code designed to steal data or harm your users.
• Compromised: A legitimate script that has been hacked and altered.
• Poorly Written: Causing performance issues or conflicts with your website’s code.

2. Content Security Policy (CSP)

CSP is a powerful browser security feature that lets you control which resources your website can load. It’s the most important step.

1. Start with a restrictive policy: Initially, block all scripts and then selectively allow trusted sources.
2. Use a meta tag or HTTP header: The meta tag is easier for testing but less secure than an HTTP header.

   <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://trusted.example.com;">
   

3. `script-src` directive: This is where you define allowed script sources.
   • `’self’`: Allows scripts from your own domain.
   • HTTPS URLs: Specifically allow trusted domains using HTTPS (e.g., https://trusted.example.com). Avoid wildcards like *.example.com unless absolutely necessary.
   • Nonce or Hash: For inline scripts, use a nonce (random string) or hash to identify allowed code blocks.

     script-src 'nonce-{random_value}';
     

     or

     script-src 'sha256-{hash_value}';
     

4. Report violations: Configure CSP to report policy breaches to a specified endpoint.

   Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://trusted.example.com; report-uri /csp-report;
   

5. Test thoroughly: Use a CSP validator (e.g., CSP Evaluator) to ensure your policy is effective and doesn’t break functionality.

3. Subresource Integrity (SRI)

SRI ensures that the files downloaded from external sources haven’t been tampered with.

1. Generate a hash: Use an online SRI generator or command-line tools to create a SHA256, SHA384, or SHA512 hash of the script file.

   openssl dgst -sha256 your_script.js
   

2. Add the `integrity` attribute: Include the generated hash in the <script> tag.

   <script src="https://trusted.example.com/your_script.js" integrity="sha256-YOUR_HASH_VALUE" crossorigin="anonymous">
   

3. `crossorigin=”anonymous”`: This attribute is required for SRI to work correctly. It tells the browser not to use credentials when fetching the script.
4. Monitor: If the hash doesn’t match, the browser won’t execute the script, preventing malicious code from running.

4. Script Selection & Management

1. Choose reputable sources: Use well-known and trusted libraries and CDNs (Content Delivery Networks).
2. Minimise dependencies: Only include the scripts you absolutely need. Fewer scripts mean a smaller attack surface.
3. Keep scripts updated: Regularly update your external scripts to benefit from security patches and bug fixes.
4. Consider self-hosting: If possible, download the script and host it on your own server. This gives you more control over its integrity but requires maintenance.

5. Regular Audits

Periodically review your website’s external scripts and CSP configuration to ensure they remain secure.