DocsAUTO
Deploy Auto safely
Deploy Auto into your browser app in three steps: pick a versioning strategy, install the script ahead of any request-making code, and allow its script and proxy origins in your CSP.
Choose aliases or a pinned release
https://cors.dev/auto.js and https://cors.dev/auto.mjs follow the latest release under a five-minute cache lifetime. Point at them if your project tolerates continuous updates. When you need predictable, deliberate upgrades, pin a specific release or vendor the ESM artifact.
<script src="https://cors.dev/auto/5bc7e0a6178b9e7e036207ff/auto.js"></script>
<script src="/app.js"></script>The release manifest publishes current version, script, and module paths. Pull and review those targets during your deployment workflow instead of resolving fresh URLs on every client visit. Pinned assets carry immutable one-year cache headers, and the corresponding ESM path ends in auto.mjs.
Merge the required CSP sources
script-src 'self' https://cors.dev;
connect-src 'self' https://proxy.cors.dev https://api.example.com;Append these sources to your existing directives; do not replace the rest of your policy with this example. Swap api.example.com for whatever native API origins your application actually calls. The proxy origin also handles Auto’s managed capability lookup.
Vendoring the artifact locally means allowing your own script origin rather than cors.dev. Inline bootstrap scripts still demand whatever nonce or hash your policy enforces, though pulling that bootstrap from an external file dodges the requirement. Auto cannot bypass CSP.
Preserve startup order
- Classic scripts: load Auto first, followed by third-party libraries and your application code. Do not use async for this dependency chain.
- ESM: call installAuto before dynamically importing your application. Static sibling imports evaluate too early to provide that guarantee.
- Bundlers: isolate the vendored Auto import inside a compact bootstrap entry, then dynamically import request-making application modules afterward.
- Configure production origins and API hosts on your Connection before shipping a managed client. Keep localhost entries explicit for local development.
Exercise three scenarios in staging: a direct native request, a supported proxied read, and one of your managed requests. Verify the Network path, HTTP status, and completed response body for each. Keep an eye on CSP reports and console errors alongside the visible output.
Roll back without replaying requests
Keep the previous pinned URL or vendored file in source control. A standard application rollback restores that asset for subsequent page loads. When you need to shut down routing inside an active tab, invoke the installation handle’s uninstall() method, or CorsAuto.uninstall() if you loaded the classic script.
Calling uninstall does not cancel in-flight requests or alter their pending transport selection. Code that already captured a patched wrapper can still hold that reference; a fresh page load establishes a clean startup. Do not automatically replay writes during rollback. Reconcile uncertain operations with the upstream API first.