[
https://issues.apache.org/jira/browse/WICKET-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149653#comment-17149653
]
Santiago Diaz commented on WICKET-6786:
---------------------------------------
Ah I see what you mean! I didn't realise you were getting false positives from
your CSRF protection. In that case (and considering that Fetch Metadata has
only recently been implemented in browsers, as you rightly say) I think it
would be reasonable for Fetch Metadata to take precedence over the CSRF
protection. If the {{Sec-Fetch-*}} headers are present we can apply the
Resource Isolation policies (Fetch Metadata), otherwise we will fallback to the
existing CSRF mechanism. Does that sound like a good approach?
If you agree with this we would be happy to go ahead and use WICKET-6786 for
our branch :)
> CsrfPreventionRequestCycleListener should support Fetch Metadata Request
> Headers
> --------------------------------------------------------------------------------
>
> Key: WICKET-6786
> URL: https://issues.apache.org/jira/browse/WICKET-6786
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
> Affects Versions: 9.0.0-M5, 8.8.0
> Reporter: Emond Papegaaij
> Priority: Major
>
> {{CsrfPreventionRequestCycleListener}} tries to determine the origin of a
> request via interpretation of the origin header and use this to block cross
> origin requests. The origin header however is not very reliable. For example,
> when a user opens a link in a new tab, the header is not sent. Fetch Metadata
> Request Headers (https://w3c.github.io/webappsec-fetch-metadata/) aims to
> solve this via a set of well defined headers. For Wicket, {{sec-fetch-site}}
> is the most important: {{same-origin}} is safe, {{none}} is a user opening a
> link via (for example) a bookmark, {{same-site}} and {{cross-origin}} should
> be blocked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
