Cross-Site Request Forgery
Cross-Site Request Forgery (CSRF) is an attack that tricks a user into executing unwanted actions on a web application in which they are currently authenticated.
CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf. For most sites, browser requests automatically include any credentials associated with the website, such as the user's session cookie, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the hacker and a legitimate request sent by the victim.
CSRF attacks target functionality that causes a state change on the server, such as changing the victim's email address or password or purchasing something. Forcing the victim to retrieve data does not benefit an attacker because the attacker does not receive the response, the victim does. As such, CSRF attacks target state-changing requests.
How we avoid CSRF attacks
We implement two layers of protection against CSRF attacks:
All browsers that follow the W3C specification on Cross-Origin Resource Sharing (CORS) will make a preflight request to the API, also known as an OPTIONS request.
We only communicate with the application/JSON.
We require the
withCredentialsflag set to TRUE on an
XMLHttpRequest.withCredentialsproperty is a Boolean that indicates whether or not cross-site Access-Control requests should be made using credentials such as cookies, authorization headers, or TLS client certificates.
The purpose of the browser performing a preflight request is to check if an external site can use its API. This request essentially checks if Access-Control-Allow-Origin or the domain the request comes from has a value of
This response tells the browser to allow code from any origin to access a resource will include the following. If not, the request is forbidden.
The majority of browsers follow the W3C convention. For browsers that do not comply with the standard, some builds of Internet Explorer and Safari, there is installed a second layer of defense.
A website can only read its own cookies. We utilize this functionality by having a token created by the server on every page refresh. This token is set as a cookie, then extracted only if the user is on the actual site and sent with the request that is not possible to replicate outside of the site itself.