Why
Some of the files the API stores for you are HTML that comes from the pages you render, for example page content and screenshots in the html format. Serving them from a subdomain of screenshotone.com mixed content from any website with ScreenshotOne’s own domain.
Stored files now live on a separate domain, screenshotonecache.com, with a stricter security policy:
- stored HTML is served with a sandboxing content security policy, so it never runs scripts and never submits forms;
- browsers never guess a file’s type from its contents, so a file is always handled as the type it is stored with.
What changed
| What | Before | Now |
|---|---|---|
Cached screenshots: cache_url, screenshot_url and the X-ScreenshotOne-Cache-URL header | cache.screenshotone.com | files.screenshotonecache.com |
Page content from metadata_content | content.screenshotone.com | content.screenshotonecache.com |
Only the host changes: the paths, the expiration and the way you request these files stay the same. The API no longer returns URLs on the old cache.screenshotone.com and content.screenshotone.com hosts.
What to check
Most integrations need no changes, because they use the URLs the API returns. Update your configuration if you allow hosts explicitly, for example:
- an
img-srcorconnect-srcdirective in your content security policy; images.remotePatternsin Next.js;- a firewall or proxy allowlist.
Allow files.screenshotonecache.com and content.screenshotonecache.com there. If you build these URLs yourself instead of using the returned ones, switch to the new hosts.
