Or sending Content-Security-Policy: script-src 'none' for everything that isn’t intended to be a document. Or both.
IMO it’s too bad that suborigins never landed. It would be nice if Discord’s mintlify route could set something like Suborigin: mintlify, thus limiting the blast radius to the mintlify section.
I imagine there’s a fair amount of complexity that would need to be worked out, mostly because the browser doesn’t know the suborigin at the time it makes a request. So Sec-Fetch-Site and all the usual CORS logic would not be able to respect suborigins unless there was a pre-flight check for the browser to learn the suborigin. But this doesn’t seem insurmountable: a server using suborigins would know that request headers are sent as if the request were aimed at the primary origin, and there could be some CORS extensions to handle the case where the originating document has a suborigin.
https://news.ycombinator.com/item?id=46321651
e.g. serve .svg only when "Sec-Fetch-Dest: image" header is present. This will stop scripts