SSL & Static Assets: 3rd Party Risks

TL;DR

Serving static assets (images, CSS, JavaScript) from a third-party domain using compressed SSL/TLS is generally okay, but introduces risks. You’re relying on their cyber security and performance. Mitigate these with proper configuration, monitoring, and Content Security Policy (CSP). If they have issues, your site can be affected.

Understanding the Risks

When you use a third-party domain for static assets, you’re handing control of those files – and their delivery – to someone else. Here’s what could go wrong:

• Downtime: Their server goes down, your site loses key elements.
• Security Breaches: If they are hacked, malicious code could be served to your users.
• Performance Issues: Slow loading times on their end impact your user experience.
• SSL/TLS Configuration Errors: Weak ciphers or expired certificates can expose data.
• Cache Poisoning: A compromised CDN could serve incorrect content.

Solution Steps

1. Choose a Reputable Provider: Select a well-known Content Delivery Network (CDN) or static asset hosting service with a strong cyber security track record. Look for certifications like ISO 27001 and SOC 2 compliance.
2. SSL/TLS Verification: Ensure they use valid, up-to-date SSL/TLS certificates.
   • Use an online SSL checker to verify their certificate details:

     openssl s_client -connect cdn.example.com:443

   • Check the cipher suites they support – prioritise strong, modern ones (TLS 1.2 or higher).
3. HTTP Strict Transport Security (HSTS): Configure HSTS on your main domain to force browsers to use HTTPS for all connections, including assets from the third-party domain.

   # Example Nginx configuration:
   add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
   

4. Content Security Policy (CSP): Implement a CSP to control which sources your browser is allowed to load resources from. This limits the damage if the third party is compromised.
   • Example CSP header:

     Content-Security-Policy: default-src 'self'; img-src 'self' cdn.example.com; script-src 'self' cdn.example.com; style-src 'self' cdn.example.com;

5. Subresource Integrity (SRI): Use SRI tags on your HTML to verify the integrity of loaded assets.

   <script src="https://cdn.example.com/js/app.js" integrity="sha384-YOUR_HASH_VALUE" crossorigin="anonymous"></script>

6. Regular Monitoring: Continuously monitor the third party’s uptime and performance.
   • Use tools like Pingdom, UptimeRobot or similar to check availability.
   • Monitor page load times using Google PageSpeed Insights or WebPageTest.
7. Caching: Configure appropriate caching headers on both your server and the third-party CDN.
   • Ensure cache invalidation works correctly when you update assets.
8. Cross-Origin Resource Sharing (CORS): If necessary, configure CORS properly to allow requests from your domain. However, minimise its use for security reasons.

Compression Considerations

Using compressed SSL/TLS (e.g., using Brotli or Gzip) is good practice – it speeds up asset delivery. The third-party provider should handle this automatically if they are a reputable CDN. Verify that compression is enabled in your browser’s developer tools.