AI widget missing SRI

Why it matters

Your page loads a third party's AI widget from its CDN with no Subresource Integrity (`integrity`) attribute, so the browser runs whatever that URL returns without verifying it. The widget script executes with full access to the page — it can read anything a visitor types into it, your DOM, and their session — which means whoever controls that CDN, the vendor or an attacker who compromises it, can push JavaScript that runs on your site. Pin a specific version and add an SRI hash where a third party supports it; if it only offers an auto-updating loader that cannot be pinned, load the widget only on the pages that need it rather than site-wide, so this third party's reach is limited to those pages.

How ShipReady detects it

AI-specific exposure — the product's differentiating module. Covers two distinct failure modes of AI-built applications: 1. Tooling artifacts deployed by accident. AI coding tools generate config and instruction files at the repo root; developers who push a whole repo (rather than just its build output) to static hosting serve them publicly. Some are merely instructions; others hold live API keys. 2. Secrets promoted into the client bundle via a PUBLIC env var prefix. This is the single most characteristic AI-app mistake: AI assistants correctly explain that a variable must be prefixed (NEXT_PUBLIC_, VITE_, ...) to be readable in the browser, and developers apply that prefix to a *server* secret. The bundler then inlines the real value into JavaScript that anyone can read. Both are confirmed by observation, never inferred from framework fingerprints alone.

Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.7.0.

How to fix it

This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.

Your site loads a third-party AI chat/agent widget from a CDN without Subresource Integrity, so that CDN can execute arbitrary JavaScript on your pages — and the widget already has full access to whatever your users type into it. If the vendor publishes a versioned script URL, pin the version and add an SRI hash to the <script> tag: integrity="sha384-..." crossorigin="anonymous" (generate the hash with `openssl dgst -sha384 -binary widget.js | openssl base64 -A`, or from srihash.org). If the vendor only offers an auto-updating loader that can't be pinned, reduce the blast radius instead: load the widget only on the specific pages that need it rather than in your global layout, and treat that vendor as having full code execution on those pages.

Frequently asked questions

What does "AI widget missing SRI" mean?

Your page loads a third party's AI widget from its CDN with no Subresource Integrity (`integrity`) attribute, so the browser runs whatever that URL returns without verifying it.

How serious is it?

ShipReady rates this low. Worth fixing. Small individually, and they accumulate.

How do I fix it?

Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.

Can I check my own site?

Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.

Related checks

• Secret published through a browser-exposed environment variablecritical
• AI provider client is configured to run in the browserhigh
• AI system prompt is hardcoded in the browser bundlemedium
• AI endpoints are reachable from your client codeinfo
• Exposed AI tooling config that can contain credentialshigh
• MCP server is reachable without authenticationhigh