Clearly chess.com was using something like "starts with" to process the re-upload. Basically don't re-upload if it starts with https://chess.com, but filter out if it starts with https://chess.com/registration-invite

Typically same origin policies are relaxed for things like images by default [0]. So they came up with a trampoline, they created a chess.com.theirDomain.tld to get past the re-upload filter, which in turn returned a redirect, which the browser followed.

[0] https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...

OP Here - Like the others have said, it wasn't a proper same-origin check. We'll never know for sure how it was handled beacuse it was all done server-side but I'm guessing it was something like an if in statement on the FQDN, hence why I was able to get away with pointing it to my own domain.

It wasn't a proper same-origin check - the server code was checking to see if the image was hosted elsewhere, and if so, it would download and self-host it. The code to check if it was on `chess.com` probably just checked to see if the domain included that string, because laziness.

Not CORS origin check (that does not apply to links), but hand made origin check from chess.com developers.

it sounded server side code allow-list the source, so it was probably just doing a string prefix check. the code to make the friend relation doesn't happen in the browser

if it's happening server side they might have had a bug where they are doing naive substring comparison instead of actual domain evaluation