Re: [whatwg/fetch] Split 'document' destination into 'frame' and 'iframe'. (#948)

> 1. This is already not true for SVG, right? We treat it identical to `<iframe>` in most respects, but also resize the element based on the intrinsic dimensions.

This kinda sucks :/ If we go with `navigate` it will mean that, for example, if an application hosts SVG files with thumbnails of user documents and blocks `no-cors` loads, it will still be vulnerable to various XS-Leaks (e.g. an attacker loading an image cross-site to determine if a user has access to a given resource and infer whether the load succeeded from the dimensions of the `<object>`).

Basically, developers would now also need to restrict requests with mode=`navigate` and always check `Sec-Fetch-Dest` in their logic and/or to fall back on `X-Frame-Options` / `frame-ancestors` for images, which is not common practice. It seems suboptimal to make every developer writing Fetch Metadata logic learn about these quirks or have a potentially bypassable security configuration; it's a wart that large sites can live with, but which will probably come back to haunt us one way or another.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/948#issuecomment-553457518

Received on Wednesday, 13 November 2019 15:37:43 UTC