[
https://issues.apache.org/jira/browse/WICKET-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176091#comment-17176091
]
Santiago Diaz commented on WICKET-6786:
---------------------------------------
Hi Sven!
My understanding from Edmond's comments (but please correct me if I'm wrong) is
that production applications will override the `isChecked` (in cases where you
want to use annotations on handlers that are cross-origin, for instance). Other
than that:
* In the ACL use case and without using `isChecked`, you would need to exempt
both the requested path & the source origin.
* In the pure CSRF protection case, this test is correct, since it forbids a
cross-site request to a non-exempted path to be made, e.g. a CSRF exploit.
> 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
> Assignee: Emond Papegaaij
> Priority: Major
> Fix For: 9.1.0
>
>
> {{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)
