!!! Overview[1]
[{$pagename}] ([CSRF] or [XSRF] or [CXRF]) is a type of [exploit] in [HTTP] where [unauthorized] commands are transmitted from a [user-agent] that the [website] [trusts].

[{$pagename}] "tricks" a victim's [browser] into sending a [HTTP Request] to a vulnerable [Website], which then performs an undesired action on behalf of the victim (for example, changing [credentials], making an illegal purchase, or performing online financial operation). 

[{$pagename}] [exploit] is extremely widespread since the majority of today's [Website] rely solely on automatically submitted [credentials] such as [session] [cookies], [basic Authentication Scheme] credentials, source IP addresses, Secure Socket Layer ([SSL]) [certificates], or [Microsoft Windows] domain [credentials]. Therefore, as the user is currently [authenticated] to the site, the site will have no way to distinguish a [{$pagename}] [attack] from a legitimate user request.

Unlike [cross-site scripting] ([XSS]), which [exploits] the [trust] a user has for a particular site, [{$pagename}] exploits the [trust] that a [website] has in a [user-agent].

!! [Best Practices] For Automated CSRF Defense[2]
! Standard Header Checks
Almost all requests include one or both of:
* Origin Header
* Referer Header
Although it is trivial to "spoof" any [HTTP Header Field] from your own [browser], it is generally impossible to do so in a [{$pagename}] [Spoofing Attack], except via an [XSS] [vulnerability]. That's why checking [HTTP Header Fields] is a reasonable first step in your [{$pagename}] defense, but since they aren't always present, it is generally not considered a sufficient defense on its own.

! Checking The Origin Header
If the Origin header is present, verify its value matches the site's origin. The Origin [HTTP Header Field] standard was introduced as a method of defending against [CSRF] and other [cross-domain] attacks. Unlike the referrer, the origin header will be present in [HTTP] requests that originate from an [HTTPS] URL. If the origin header is present, then it should be checked to make sure it matches your site's origin.

This defense technique is specifically proposed in section 5.0 of Robust Defenses for [{$pagename}]. This paper proposes the creation of the Origin header and its use as a [CSRF] defense mechanism.

! Checking The Referer Header
If the Origin header is not present, verify the hostname in the Referer [HTTP Header Field] matches the site's origin. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF [prevention] when memory is scarce or [server-side] [state] doesn't exist. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.

In both cases, just make sure your origin check is strong. For example, if your site is "site.com" make sure "site.com.attacker.com" doesn't pass your origin check (i.e., match through the trailing / after the origin to make sure you are matching against the entire origin).

! What to do when Both Origin and Referer Aren't Present
If neither of these headers is present, which should be __VERY rare__, you can either accept or block the request. We recommend blocking, particularly if you aren't using a random CSRF token as your second check. You might want to log when this happens for a while and if you basically never see it, start blocking such requests.

! [CSRF Token]
A [CSRF Token] is probably a better defense.

! [Same-site Cookies]
[Same-site Cookies] defines a "SameSite" [cookie] attribute which allows servers to assert that a [cookie] ought not to be sent along with cross-site requests. 

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Cross-site_request_forgery|Wikipedia:Cross-site_request_forgery|target='_blank'] - based on information obtained 2016-08-08- 
* [#2] - [Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet|https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet|target='_blank'] - based on information obtained 2016-08-08-