New CSP headers caused breaking damages to existing NFTs #175
Comments
tpae
added
kind/bug
|
Hey, thanks for opening this issue. Just a heads up that nftstorage.link is not a protocol (it's not IPFS!) - it's an IPFS gateway. If it's helpful, you can always read data off IPFS via HTTP using other public gateways (or even using your own). |
|
Could you share more info on where you're using nftstorage.link and what's broken as a result? Many major marketplaces use their own dedicated gateways (Pinata offers this option), so would love to hear more about what you mean by "significant amount of NFTs to become useless on major marketplace platforms." We offer nftstorage.link as a fast way for public users to read NFTs off of IPFS, but preventing its use for malicious content was becoming something we couldn't ignore (and since nftstorage.link is public infrastructure, unfortunately we had to make a call that could harm some current users - again, at the infrastructure level, not the protocol level, which we alone don't define). We're looking into offering our own dedicated gateways to users as well. |
@tpae can you elaborate on this point please ? CSPs do prevent loading external URLs (from other origins) but they do not prevent ones from the same origin. E.g. relative URL would work just fine. It is also worth pointing out that it is not just about phishing attacks. If NFT requires a third party URL to function, it is unable to take advantage of the content addressing. There is no guarantee that URL will stick around or that it will continue to serve the intended resource long term. I think we should try and work out a solution that can help building a more resilient NFTs. As for existing NFTs that got broken by this change we could probably work out solution to fix those as well (although that fix may not apply to new NFTs) |
|
Hey, We are also experiencing this for interactive OBJKTs that use WASM (not all strangely), here is an example, uploaded through NFT.storage: WORKS -> https://ipfs.io/ipfs/bafybeid3pwll6qkarrian3ulcua5ve3qyqqqfkxn7whilr3a5hocrtrubi/ |
|
we should be able to whitelist this for WASM given the security constraints in WASM |
Addresses wasm module loading reported in #175 For details see https://github.com/WebAssembly/content-security-policy/blob/main/proposals/CSP.md#the-wasm-unsafe-eval-source-directive
|
Thanks for reporting @melMass, I believe https://github.com/nftstorage/nftstorage.link/pull/176/files should address this. |
@dchoi27 Makes sense, but even after switching the gateway to ipfs.io, the CSP headers were still there, preventing it from loading. nftstorage.link is the most reliable than the others since we're using nft.storage to pin all of our data.
@dchoi27 Here's a broken link: https://opensea.io/assets/ethereum/0x2afb30418504d3c6ecfa2cb40012804e52ced20a/3643
I'm open to ideas, but not using nftstorage.link is probably not a good idea. We rely on nft.storage to host all of our content, and not having this support is a deal breaker. |
|
Sorry you're experiencing this. We're planning on implementing in the coming weeks an allowlist of CIDs where we've verified the content is OK but would otherwise be blocked. Clarifying a few things:
To add on to @Gozala, you might be able to use |
While it's being addressed upstream: nftstorage/nftstorage.link#175
|
@dchoi27
@Gozala it doesn't work that way when it's embedded in iframes.
This is true in an idealistic sense, but in real-world use, NFTs are still early in their concept, and not all marketplaces and platforms currently adopt the best practices. Our goal is to service our collectors and pick the most reliable gateway (so far nftstorage.link has been the best), but this restriction makes it hard for us to leverage it anymore. We will devise a way to deal with this, but it will involve moving away from nftstorage.link gateway as a solution. I still think adding these headers is restrictive, and as a public gateway, it should leave it up to the users to make the decisions. |
|
Totally understand! But just want to flag that thinking that users can make choices on determining what's phishing content for all content they're grabbing through an NFT / gateway is also idealistic - and these users are often ones that we need to protect. The good thing is you have other choices (other gateway providers, dedicated gateways, running your own) that can be used. And check back in next week or so to see if nftstorage.link's allowlist could work for you. Leaving this issue open until we've merged a PR for the allowlist |
|
I was able to fix this issue by having relative paths within the iframe, it worked! |
Relative paths always worked. You must just remove the leading slash (that's the case for all IPFS afaik) |
|
woo! closing this then |
Addresses wasm module loading reported in #175 For details see https://github.com/WebAssembly/content-security-policy/blob/main/proposals/CSP.md#the-wasm-unsafe-eval-source-directive Co-authored-by: Vasco Santos <santos.vasco10@gmail.com>
|
Hi @dchoi27, we are running into a related issue with some web-based nfts on versum.xyz. The issue specifically is that I notice Any chance of getting that added? Thanks! |
|
@vasco-santos mind taking a look? |
|
@vasco-santos Thank you! Really appreciate it! 🙏 |
Reference to #172 that was recently merged. @vasco-santos
This update caused a significant amount of NFTs to become useless on major marketplace platforms.
NFTs can be rendered as an iframe with HTML/CSS/JS:
This change forced
content-security-policyheaders to be overwritten; now, all of those NFTs relying on iframe rendering cannot load content.While I agree with the sentiment mentioned in #172 (wrt @Gozala), IPFS (nftstorage.link) as a protocol should not be responsible for setting security standards that could be damaging to legitimate use cases.
The text was updated successfully, but these errors were encountered: