A good reason, which you have sort of touched on, is that once the CSRF cookie has been received, it is then available for use throughout the application in client script for use in both regular forms and AJAX POSTs. This will make sense in a JavaScript heavy application such as one employed by AngularJS (using AngularJS doesn't require that the application will be a single page app, so it would be useful where state needs to flow between different page requests where the CSRF value cannot normally persist in the browser).

Consider the following scenarios and processes in a typical application for some pros and cons of each approach you describe. These are based on the Synchronizer Token Pattern.

Request Body Approach

1. User successfully logs in.
2. Server issues auth cookie.
3. User clicks to navigate to a form.
4. If not yet generated for this session, server generates CSRF token, stores it against the user session and outputs it to a hidden field.
5. User submits form.
6. Server checks hidden field matches session stored token.

Advantages:

• Simple to implement.
• Works with AJAX.
• Works with forms.
• Cookie can actually be HTTP Only.

Disadvantages:

• All forms must output the hidden field in HTML.
• Any AJAX POSTs must also include the value.
• The page must know in advance that it requires the CSRF token so it can include it in the page content so all pages must contain the token value somewhere, which could make it time consuming to implement for a large site.

Custom HTTP Header (downstream)

1. User successfully logs in.
2. Server issues auth cookie.
3. User clicks to navigate to a form.
4. Page loads in browser, then an AJAX request is made to retrieve the CSRF token.
5. Server generates CSRF token (if not already generated for session), stores it against the user session and outputs it to a header.
6. User submits form (token is sent via hidden field).
7. Server checks hidden field matches session stored token.

Advantages:

• Works with AJAX.
• Cookie can be HTTP Only.

Disadvantages:

• Doesn't work without an AJAX request to get the header value.
• All forms must have the value added to its HTML dynamically.
• Any AJAX POSTs must also include the value.
• The page must make an AJAX request first to get the CSRF token, so it will mean an extra round trip each time.
• Might as well have simply output the token to the page which would save the extra request.

Custom HTTP Header (upstream)

1. User successfully logs in.
2. Server issues auth cookie.
3. User clicks to navigate to a form.
4. If not yet generated for this session, server generates CSRF token, stores it against the user session and outputs it in the page content somewhere.
5. User submits form via AJAX (token is sent via header).
6. Server checks custom header matches session stored token.

Advantages:

• Works with AJAX.
• Cookie can be HTTP Only.

Disadvantages:

• Doesn't work with forms.
• All AJAX POSTs must include the header.

Custom HTTP Header (upstream & downstream)

1. User successfully logs in.
2. Server issues auth cookie.
3. User clicks to navigate to a form.
4. Page loads in browser, then an AJAX request is made to retrieve the CSRF token.
5. Server generates CSRF token (if not already generated for session), stores it against the user session and outputs it to a header.
6. User submits form via AJAX (token is sent via header) .
7. Server checks custom header matches session stored token.

Advantages:

• Works with AJAX.
• Cookie can be HTTP Only.

Disadvantages:

• Doesn't work with forms.
• All AJAX POSTs must also include the value.
• The page must make an AJAX request first to get the CRSF token, so it will mean an extra round trip each time.

Set-Cookie

1. User successfully logs in.
2. Server issues auth cookie.
3. User clicks to navigate to a form.
4. Server generates CSRF token, stores it against the user session and outputs it to a cookie.
5. User submits form via AJAX or via HTML form.
6. Server checks custom header (or hidden form field) matches session stored token.
7. Cookie is available in browser for use in additional AJAX and form requests without additional requests to server to retrieve the CSRF token.

Advantages:

• Simple to implement.
• Works with AJAX.
• Works with forms.
• Doesn't necessarily require an AJAX request to get the cookie value. Any HTTP request can retrieve it and it can be appended to all forms/AJAX requests via JavaScript.
• Once the CSRF token has been retrieved, as it is stored in a cookie the value can be reused without additional requests.

Disadvantages:

• All forms must have the value added to its HTML dynamically.
• Any AJAX POSTs must also include the value.
• The cookie will be submitted for every request (i.e. all GETs for images, CSS, JS, etc, that are not involved in the CSRF process) increasing request size.
• Cookie cannot be HTTP Only.

So the cookie approach is fairly dynamic offering an easy way to retrieve the cookie value (any HTTP request) and to use it (JS can add the value to any form automatically and it can be employed in AJAX requests either as a header or as a form value). Once the CSRF token has been received for the session, there is no need to regenerate it as an attacker employing a CSRF exploit has no method of retrieving this token. If a malicious user tries to read the user's CSRF token in any of the above methods then this will be prevented by the Same Origin Policy. If a malicious user tries to retrieve the CSRF token server side (e.g. via curl) then this token will not be associated to the same user account as the victim's auth session cookie will be missing from the request (it would be the attacker's - therefore it won't be associated server side with the victim's session).

As well as the Synchronizer Token Pattern there is also the Double Submit Cookie CSRF prevention method, which of course uses cookies to store a type of CSRF token. This is easier to implement as it does not require any server side state for the CSRF token. The CSRF token in fact could be the standard authentication cookie when using this method, and this value is submitted via cookies as usual with the request, but the value is also repeated in either a hidden field or header, of which an attacker cannot replicate as they cannot read the value in the first place. It would be recommended to choose another cookie however, other than the authentication cookie so that the authentication cookie can be secured by being marked HttpOnly. So this is another common reason why you'd find CSRF prevention using a cookie based method.

Choosing the storage is more about trade-offs than trying to find a definitive best choice. Let's go through a few options:

Option 1 - Web Storage (localStorage or sessionStorage)

Pros

• The browser will not automatically include anything from Web storage into HTTP requests making it not vulnerable to CSRF
• Can only be accessed by Javascript running in the exact same domain that created the data
• Allows to use the most semantically correct approach to pass token authentication credentials in HTTP (the Authorization header with a Bearer scheme)
• It's very easy to cherry pick the requests that should contain authentication

Cons

• Cannot be accessed by Javascript running in a sub-domain of the one that created the data (a value written by example.com cannot be read by sub.example.com)
• ⚠️ Is vulnerable to XSS
• In order to perform authenticated requests you can only use browser/library API's that allow for you to customize the request (pass the token in the Authorization header)

Usage

You leverage the browser localStorage or sessionStorage API to store and then retrieve the token when performing requests.

localStorage.setItem('token', 'asY-x34SfYPk'); // write
console.log(localStorage.getItem('token')); // read

Option 2 - HTTP-only cookie

Pros

• It's not vulnerable to XSS
• The browser automatically includes the token in any request that meets the cookie specification (domain, path and lifetime)
• The cookie can be created at a top-level domain and used in requests performed by sub-domains

Cons

• ⚠️ It's vulnerable to CSRF
• You need to be aware and always consider the possible usage of the cookies in sub-domains
• Cherry picking the requests that should include the cookie is doable but messier
• You may (still) hit some issues with small differences in how browsers deal with cookies
• ⚠️ If you're not careful you may implement a CSRF mitigation strategy that is vulnerable to XSS
• The server-side needs to validate a cookie for authentication instead of the more appropriate Authorization header

Usage

You don't need to do anything client-side as the browser will automatically take care of things for you.

Option 3 - Javascript accessible cookie _{ignored by server-side}

Pros

• It's not vulnerable to CSRF (because it's ignored by the server)
• The cookie can be created at a top-level domain and used in requests performed by sub-domains
• Allows to use the most semantically correct approach to pass token authentication credentials in HTTP (the Authorization header with a Bearer scheme)
• It's somewhat easy to cherry pick the requests that should contain authentication

Cons

• ⚠️ It's vulnerable to XSS
• If you're not careful with the path where you set the cookie then the cookie is included automatically by the browser in requests which will add unnecessary overhead
• In order to perform authenticated requests you can only use browser/library API's that allow for you to customize the request (pass the token in the Authorization header)

Usage

You leverage the browser document.cookie API to store and then retrieve the token when performing requests. This API is not as fine-grained as the Web storage (you get all the cookies) so you need extra work to parse the information you need.

document.cookie = "token=asY-x34SfYPk"; // write
console.log(document.cookie); // read

Additional Notes

This may seem a weird option, but it does has the nice benefit that you can have storage available to a top-level domain and all sub-domains which is something Web storage won't give you. However, it's more complex to implement.

Conclusion - Final Notes

My recommendation for most common scenarios would be to go with Option 1, mostly because:

• If you create a Web application you need to deal with XSS; always, independently of where you store your tokens
• If you don't use cookie-based authentication CSRF should not even pop up on your radar so it's one less thing to worry about

Also note that the cookie based options are also quite different, for Option 3 cookies are used purely as a storage mechanism so it's almost as if it was an implementation detail of the client-side. However, Option 2 means a more traditional way of dealing with authentication; for a further read on this cookies vs token thing you may find this article interesting: Cookies vs Tokens: The Definitive Guide.

Finally, none of the options mention it, but use of HTTPS is mandatory of course, which would mean cookies should be created appropriately to take that in consideration.