next.js: CORS error fetching external CSS on 9.5.3
Bug report
Describe the bug
After upgrading to next@9.5.3, the initial load of our page throws when requesting CSS from our CDN.
To Reproduce
- Create an app with a stylesheet, css or scss.
- Import that stylesheet into a component as a module.
- Build and upload your assets to a CDN using
assetPrefixinnext.config.js. Deploy your app and run in production mode. - Notice that your initial page load throws with a CORS error.
Expected behavior
Preloading css should work cross domain or it should fail gracefully.
Screenshots
Developer Tools:
Elements View:
System information
- OS: [e.g. macOS, Windows]
- Browser: chrome
- Version of Next.js: 9.5.3
- Version of Node.js: 10
Additional context
I believe it’s related to this PR: https://github.com/vercel/next.js/pull/16581#issuecomment-691362392
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 16
- Comments: 33 (11 by maintainers)
We’ve had some success by discovering an undocumented prop that can be passed into
<Head>in a custom document - make sure that it is theHeadfromnext/document.You can pass in the
crossOriginprop with a value of eitheranonymousoruse-credentials(see relevant MDN). The fetch was successful 👍edit: just found out that is deprecated - apparently you can add it in
next.config.jsinstead - see relevant errorHi 👋
Same issue here too. Downgrading to v9.5.2.
I have the same issue. Compiled file have a “registerPage” function，it use fetch to acquire external CSS. ps: downgrading to v9.5.2 can fix the issue
@Timer I’ve tried 10.0.1 and am still seeing the CORS error.
have same issue, interesting why one chunk is preloaded using fetch, while we have preload link in html? BTW if smbd like me needs quick fix - downgrading to v9.5.2 fixes issue. as issue author states basically.
It seems to be solved by specifying
Access-Control-Allow-Originheader as * in CDN.I’m still having this error in 10.0.4
Wasn’t NextJS sending the correct CORS response before?
We just upgraded from 9.4 to 9.5 and started to have this issue. Then upgraded to 10.0.4 thinking it would solve it but no.
Do we need to do extra configuration now in our server?
We have an ASSET_PREFIX set to static.ourdomain.com but it is being served by the same NextJS server. (We have a custom server.js to handle cache-control header and OPTIONS verb, but then requests go to NextJs).
@inside I tested our setup removing the crossOrigin: ‘anonymous’ setting in next.config.js and it stopped giving errors. No further action was needed. On the other hand, if we had that option, we had to implement responding the access-control header. So in short, I rolled back the workaround I had for 9.5 and left 10.0.4 config as it was before, and it works.
No problem! I setup a S3 bucket and confirmed Next.js worked correctly with an
assetPrefixconfigured to be S3. Seems this is fully fixed in the latest Next.js canaries!Thrilled there’s a workaround. Not all hero’s wear capes 😂 thank youu
thanks for the explanation @sophiekoonin . are you saying that by adding that config to my
next.config.jsall assets are loaded with CORS anonymous?that’s an interesting workaround!
v9.5.2, v9.5.3 have a CVE out: https://nvd.nist.gov/vuln/detail/CVE-2020-15242 v9.5.4, 9.5.5 failed due this CORS error
We were forced to downgrade to v9.4.4 until this gets fixed…
Downgrading to 9.5.2 is blocked for us by this CVE: https://nvd.nist.gov/vuln/detail/CVE-2020-15242
Ive got this issue too, upgraded to webpack 5 and suspected it was something to do with crossOrigin loading, but it’s the same cssRule issue mentioned here.
This is impacting PR environments that proxy through a stage URL with a query string or cookie value being placed to route assets from deploy locations (CDN) back to the PR env.