If you’re integrating Filestack into a production app, you’ve probably run into this problem: your Content Security Policy (CSP) blocks uploads because the browser refuses to talk to domains it doesn’t recognize. This guide walks through exactly which domains to whitelist and why, so uploads work reliably for users anywhere in the world.
Why CSP blocks Filestack in the first place
CSP is a browser security feature that restricts which external sources your page is allowed to load scripts, styles, images, and network requests from. It’s a great defense against XSS and data exfiltration, but it also means any service you integrate, including Filestack, needs to be explicitly allowed.
Filestack uploads touch more than one domain during a single upload. There’s the Filestack API and dialog itself, the upload endpoint that actually receives your file, and (if you’re using direct to cloud storage uploads) the storage bucket the file lands in. Miss any one of these in your CSP, and the upload silently fails or throws a console error that looks unrelated to CSP at all.
The two groups of domains you need
1. Filestack’s own domains
These handle the picker UI, the API calls, and the upload transport layer:
api.filestackapi.com
upload.filestackapi.com
dialog.filestackapi.com
static.filestackapi.com
cloud.filestackapi.com
cdn.filestackcontent.com
process.filestackapi.com
assets.filestackapi.com
Filestack also load balances uploads by region for performance, so depending on where your users are, requests may route through:
upload-us-east-1.filestackapi.com
upload-us-west-2.filestackapi.com
upload-eu-west-1.filestackapi.com
upload-ap-northeast-1.filestackapi.com
upload-ap-southeast-2.filestackapi.comIf you want uploads to work for a global user base, include all of these rather than just the region closest to you. A user in Tokyo shouldn’t be routed to an upload endpoint your CSP only allows for us-east-1.
2. Your S3 destination buckets
If your storage location is Amazon S3, the browser also needs permission to talk directly to your bucket, since Filestack’s client uploads straight to storage after the API hands off a signed request.
Here’s the part that trips people up: AWS supports a few different URL formats for the same bucket, and depending on your SDK version, region, or how a request gets constructed, you might see any of them in practice. So for each bucket you need to allow all three:
- Virtual hosted style (regional): https://<bucket>.s3.<region>.amazonaws.com
- Virtual hosted style (legacy dash format): https://<bucket>.s3-<region>.amazonaws.com
- Virtual hosted style (no region in hostname): https://<bucket>.s3.amazonaws.com
These aren’t three different destinations, they’re three different ways of writing an address to the same bucket. AWS has changed its recommended format over the years, and some tooling still defaults to the older ones, so allowing only the newest format is a common cause of intermittent upload failures.
Applied to a naming pattern like filestack-uploads-production-<region>, across five regions, that gives you:
https://filestack-uploads-production-us-east-1.s3.us-east-1.amazonaws.com
https://filestack-uploads-production-us-east-1.s3-us-east-1.amazonaws.com
https://filestack-uploads-production-us-east-1.s3.amazonaws.com
https://filestack-uploads-production-us-west-2.s3.us-west-2.amazonaws.com
https://filestack-uploads-production-us-west-2.s3-us-west-2.amazonaws.com
https://filestack-uploads-production-us-west-2.s3.amazonaws.com
https://filestack-uploads-production-eu-west-1.s3.eu-west-1.amazonaws.com
https://filestack-uploads-production-eu-west-1.s3-eu-west-1.amazonaws.com
https://filestack-uploads-production-eu-west-1.s3.amazonaws.com
https://filestack-uploads-production-ap-northeast-1.s3.ap-northeast-1.amazonaws.com
https://filestack-uploads-production-ap-northeast-1.s3-ap-northeast-1.amazonaws.com
https://filestack-uploads-production-ap-northeast-1.s3.amazonaws.com
https://filestack-uploads-production-ap-southeast-2.s3.ap-southeast-2.amazonaws.com
https://filestack-uploads-production-ap-southeast-2.s3-ap-southeast-2.amazonaws.com
https://filestack-uploads-production-ap-southeast-2.s3.amazonaws.comAdjust the bucket names and regions to match your own naming convention. If you’re on a different storage provider (Google Cloud Storage, Azure Blob, DigitalOcean Spaces), the same principle applies: whitelist the exact host your provider uses to serve uploads, and check whether it has a legacy URL format still in use.
Putting it together in a CSP header
A working connect-src and img-src directive covering both groups looks like this:
Content-Security-Policy:
connect-src 'self'
api.filestackapi.com
upload.filestackapi.com
dialog.filestackapi.com
static.filestackapi.com
cloud.filestackapi.com
cdn.filestackcontent.com
process.filestackapi.com
assets.filestackapi.com
upload-us-east-1.filestackapi.com
upload-us-west-2.filestackapi.com
upload-eu-west-1.filestackapi.com
upload-ap-northeast-1.filestackapi.com
upload-ap-southeast-2.filestackapi.com
https://filestack-uploads-production-us-east-1.s3.us-east-1.amazonaws.com
https://filestack-uploads-production-us-east-1.s3-us-east-1.amazonaws.com
https://filestack-uploads-production-us-east-1.s3.amazonaws.com
https://filestack-uploads-production-us-west-2.s3.us-west-2.amazonaws.com
https://filestack-uploads-production-us-west-2.s3-us-west-2.amazonaws.com
https://filestack-uploads-production-us-west-2.s3.amazonaws.com
https://filestack-uploads-production-eu-west-1.s3.eu-west-1.amazonaws.com
https://filestack-uploads-production-eu-west-1.s3-eu-west-1.amazonaws.com
https://filestack-uploads-production-eu-west-1.s3.amazonaws.com
https://filestack-uploads-production-ap-northeast-1.s3.ap-northeast-1.amazonaws.com
https://filestack-uploads-production-ap-northeast-1.s3-ap-northeast-1.amazonaws.com
https://filestack-uploads-production-ap-northeast-1.s3.amazonaws.com
https://filestack-uploads-production-ap-southeast-2.s3.ap-southeast-2.amazonaws.com
https://filestack-uploads-production-ap-southeast-2.s3-ap-southeast-2.amazonaws.com
https://filestack-uploads-production-ap-southeast-2.s3.amazonaws.com;
img-src 'self' data: cdn.filestackcontent.com static.filestackapi.com;
frame-src dialog.filestackapi.com cloud.filestackapi.com;
script-src 'self' static.filestackapi.com;Notes on the directives:
- connect-src covers the actual upload and API calls, this is the one that matters most for the “upload fails silently” problem.
- img-src is needed if you’re rendering previews or thumbnails served from Filestack’s CDN.
- frame-src is only required if you’re using the Filestack picker in an iframe (the hosted dialog or cloud picker UI).
- script-src is needed if you’re loading the Filestack JS client from their CDN rather than bundling it yourself.
A note on maintenance
Bucket lists like this grow as you add regions or rotate infrastructure, and CSP headers with 25+ entries get hard to audit by eye. A couple of practical habits help:
- Keep the CSP config in version control as a single source of truth, generated from your list of active buckets and regions rather than hand edited each time.
- Test with the CSP in report only mode (Content-Security-Policy-Report-Only) before enforcing it, so you catch missing domains without breaking uploads for users.
- Check your browser console for Refused to connect errors after any AWS SDK or Filestack client version bump, since URL format defaults can change between versions.
Once this is in place, uploads should route cleanly to the nearest Filestack endpoint and land in the correct regional bucket, for users anywhere in the world.
Key Takeaways
- One upload touches several domains, not one. A single Filestack upload hits the API, the upload transport, the picker dialog, the CDN, and your storage bucket. Allowing only api.filestackapi.com is the most common mistake, and it fails in ways that don’t look like CSP errors.
- Whitelist every regional upload endpoint, not just your own. Filestack load balances uploads by region. Uploads work fine in your testing and break for a user in Tokyo, because their request routes through an endpoint your policy never allowed.
- Each S3 bucket needs three URL formats allowed. Regional dot, legacy dash, and no-region-in-hostname are three ways of addressing the same bucket. AWS has changed its recommended format over the years and some tooling still defaults to the old ones, so allowing only the newest format causes intermittent, hard-to-reproduce failures.
- connect-src is the directive that matters most. It covers the actual upload and API calls, and it’s the one behind “the upload silently fails.” img-src, frame-src and script-src handle previews, the picker iframe, and the hosted client separately.
- Roll it out in report-only mode first. Content-Security-Policy-Report-Only surfaces every missing domain without breaking uploads for real users. Generate the list from version control rather than hand-editing it, and re-check the console after any AWS SDK or Filestack client version bump.
Favour is a Developer Relations engineer with 3+ years of experience helping developers adopt and succeed with technical products. Combining a strong software engineering background with a passion for community building, content creation, and developer education, he specializes in translating complex technologies into clear, engaging experiences for developer audiences.
Read More →