I'm not sure if blocking more than 3 levels of iframes is actually a goal. Is it part of the HTML specification?

Anyway, I don't see a security vulnerability here. It might be a functional/spec-compliance bug, but I'll leave that to the Blink team.

Also, if it affects iOS (WKWebView), please check that box.

We do attempt to block simpler forms of iframe nesting. However, realistically, there's a limit to how well the heuristic works today: it's based on matching the non-fragment part of the URL, which doesn't work if the query string is randomized.

Do we know how Edge/Firefox behave here? If they limit the max nesting, that would be a convincing reason to limit our nesting as well. Nesting too deeply certainly can cause issues.

(Strictly speaking, I don't think we can nest beyond 1000 iframes due to https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/html_frame_owner_element.cc?rcl=c9094c99449adbde1ed817b9c3af33cd9b07506d&l=378: does the repro actually cause Blink to exceed this limit? If so, I would consider that a bug; otherwise, this is more of a feature request / spec fix)

https://crash.corp.google.com/browse?q=reportid=%27c21ffbfcc3995db2%27 is a crash I hit while playing around with the repro page: it's a stack overflow in cc code. So limiting the max depth of the frame tree is probably not a bad idea.

(there's a similar bug to limit the max depth of the layout tree, see issue 721175. This one is easier to fix though)