Thanks for your report.

file:// URLs should be treated as unique origins (per  crbug.com/455882 ), which should prevent the parent frame from being able to read anything in the child frame, even if it appears as a subframe when the page is rendered.

I was able to view the iframe with the directory listings, but was able to verify that I could not access any of its information via JavaScript in the parent frame, which was correctly blocked as cross-origin.

To clarify: were you able to have the parent frame access the filesystem details directly?

Otherwise, I think this is working as intended.

Beyond what's noted in #1, file:// URIs should only be framable by other file:// uris. It should not be possible to iframe a file:// URI from a page served by a web protocol like HTTP or HTTPS.

Unfortunately, I don't have access to a server, so I couldn't test this out over the web, only when loading the file locally. Are you saying that websites (unlike locally loaded HTML files) won't be able to see file:/// directories like this, or is more investigation required?

You can use https://web.evilbit.io/frame_file_url.html to test and see that the DevTools console says: Not allowed to load local resource: file:///etc/passwd.

I verified #3 -- it will only be frame-able for other pages loaded over file:// URLs.

The page framing the file:// URL would not be able to see the contents either way because of the same-origin policy (to the parent page, it would essentially be inaccessible). For example, the parent page would not be able to access any details about the files, despite it rendering within the frame on the page.

Thank you for checking on that. You can close this issue then.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot