Add CORS headers to CDN images

[gildaswise]

Is your feature request related to a problem? Please describe.

I'm using Flutter to develop deck.blue (@redsolver's also using it for SkyFeed) and there's two options for the renderer toolkit: the HTML renderer and the CanvasKit renderer. The CanvasKit renderer is more performant in a number of ways, and there's a growing push to use it instead of the HTML renderer. But there's a catch: the CanvasKit renderer needs proper access to the image bytes in order to render them, instead of just accessing them via the <img> HTML tag.

Currently, all images in Bluesky's CDN don't have any CORS headers and this is what happens when I try to use the CanvasKit renderer:

Is there any reason for them to not have those headers? Would it be an issue to have them? I think Twitter also had this same issue.

Additional context

I've had a talk with @kevmoo about this, so I'm pinging him here so he can answer any Flutter-related questions. If this is a client-side issue, please let me know what I could do instead.

[bnewbold]

I assume this would be a CDN config thing, not directly controlled by code in this repo.

Is there any reason for them to not have those headers?

I'm generally hesitant to intervene in the web platform security model without a solid understanding of why it is the way it is. If it is definitely safe, why doesn't the browser allow it by default, regardless of CORS headers?

One specific area of concern is around PNG images, which are notoriously flexible and probably an easy mechanism to ship Javascript, WASM, or other payloads. What are the security implications of shipping near-arbitrary user-uploaded bytes from a *.bsky.app domain with CORS headers set?

[bnewbold]

cc: @pfrazee in on this one. This is probably the correct repo for this to be filed and discussed, but has front-end aspects.

I'm surprised that canvas rendering of images (vs browser's own rendering?) would be performant, but trust you on this. And do want to support both deck.blue and SkyFeed!

[kevmoo]

@bnewbold – CORS is tricky here. Without Access-Control-Allow-Origin: * ONLY DOM-based <img> tags will be able to render images. By enabling CORS, you allow any Canvas/WebGL/WebGPU based experience to use the image contents.

As long as you have correct mime-types set on the content, browsers do a great job of making sure arbitrary PNG files (for example) are not executable as JS and/or Wasm (for example)

[pfrazee]

Ahhh this is one of those things that'll be about the details, but here's my top-of-head response:

• For a CDN a common concern is people taking advantage of free hosting. That one's a bit tricky for us, we're being pretty permissive at the moment (<img> tags do work) and we need to be for the kinds of usages we want. We'll put that aside for now because I don't think we intend to change policies there.
• For file security, setting mime headers correctly and using CSP headers are pretty key. Anything else would be processing on the files before we put them in the CDN.
  • Enabling CORS will open up more opportunities for web apps' JS to interact with the content of the files, so this might assist someone smuggling payloads other than images, but I don't know if that's a large enough concern to say no to it.
• For host security, generally I don't think the CDN is going to support any kinds of requests that opening CORS would put at risk. I assume it's head/get/options only.
• Also worth mentioning that native clients don't bother with any of the header-based security, so the CORS policy only affects web clients anyway.

So -- off the top of my head -- I think this would be okay to do