CSRF

    A real-life example is cited in section 1 of Robust Defenses for Cross-Site Request Forgery:

    There are many ways to mitigate CSRF, some of which have been outlined in the . This filter employs a stateless mitigation pattern known as origin verification.

    This pattern relies on two pieces of information used in determining if a request originated from the same host. * The origin that caused the user agent to issue the request (source origin). * The origin that the request is going to (target origin).

    When the filter is evaluating a request, it ensures both pieces of information are present and compares their values. If the source origin is missing or the origins do not match the request is rejected. The exception to this being if the source origin has been added to the policy as valid. Because CSRF attacks specifically target state-changing requests, the filter only acts on HTTP requests that have a state-changing method (POST, PUT, etc.).

    Note

    Due to differing functionality between browsers this filter will determine a request’s source origin from the Origin header. If that is not present it will fall back to the host and port value from the requests Referer header.

    For more information on CSRF please refer to the pages below.

    The CSRF filter supports the ability to extend the source origins it will consider valid. The reason it is able to do this while still mitigating cross-site request forgery attempts is because the target origin has already been reached by the time front-envoy is applying the filter. This means that while endpoints may support cross-origin requests they are still protected from malicious third-parties who have not been allowlisted.

    It’s important to note that requests should generally originate from the same origin as the target but there are use cases where that may not be possible. For example, if you are hosting a static site on a third-party vendor but need to make requests for tracking purposes.

    Warning

    Additional origins can be either an exact string, regex pattern, prefix string, or suffix string. It’s advised to be cautious when adding regex, prefix, or suffix origins since an ambiguous origin can pose a security vulnerability.

    The fraction of requests for which the filter is enabled can be configured via the value of the filter_enabled field.

    The fraction of requests for which the filter is enabled in shadow-only mode can be configured via the value of the shadow_enabled field. When enabled in shadow-only mode, the filter will evaluate the request’s Origin and Destination to determine if it’s valid but will not enforce any policies.

    Note

    If both and are on, the flag will take precedence.