Only half. Angular's HttpClient can read a token from a cookie and send it back as a header on mutating requests, but your server must issue and verify that token. Without the server half, your app has no real CSRF protection at all.
What CSRF is
In a cross-site request forgery (CSRF, also written XSRF), an attacker tricks a signed-in user into visiting a malicious page. That page silently sends a request to your application's server, and the browser attaches the user's cookies, including the authentication cookie. If the server cannot tell the forged request from a real one, the action goes through. Angular's guide uses a money transfer to illustrate.
What Angular's HttpClient does
The Angular security guide describes a common token pattern. The server sends a randomly created token in a cookie. Client code reads the cookie and adds a custom header on later requests. The server compares cookie and header and rejects mismatches. It works because of the same origin policy: only code from your site can read that cookie and set the custom header, so a page on another site cannot.
HttpClient implements the client side by default:
- An interceptor reads a token from a cookie named XSRF-TOKEN and sets it as a header named X-XSRF-TOKEN.
- It sends the header on mutating requests, such as POST, to relative and same origin URLs, but not on GET or HEAD requests.
- GET is skipped because CSRF protection is needed only for requests that change state.
What your server must do
The guide says HttpClient supports only the client half. Your backend must:
- Set a token in a JavaScript readable session cookie called XSRF-TOKEN on page load or on the first GET request.
- Make the token unique per user and verifiable by the server, so clients cannot invent their own. The guide suggests a digest of your authentication cookie with a salt.
- Check that the cookie value matches the X-XSRF-TOKEN header on every state changing request, and reject missing or mismatched values.
- Use unique cookie names if several Angular apps share a domain or subdomain, to avoid collisions.
| Piece | Who provides it |
|---|---|
| Reading the cookie and setting the header | Angular HttpClient |
| Issuing a per-user token | Your server |
| Verifying cookie against header | Your server |
| Skipping GET and HEAD | Angular, by default |
Common gaps
- State changes on GET endpoints. If a GET changes data, the default protection does not cover it.
- Requests to a different origin. The default interceptor targets relative and same origin URLs.
- A token that is the same for everyone.
- Treating the front end as enough. The guide says both CSRF and cross-site script inclusion must be mitigated primarily on the server.
How to test
Replay a POST from a command line tool without the header, then with a wrong value. The server should refuse both. Then check that the real app still works, which confirms the client half is wired up.
Quick check
If I use Angular HttpClient, am I protected from CSRF?
Only if your backend also issues and checks the token. HttpClient does just the client half.
Why are GET requests excluded?
CSRF protection is needed for requests that change state, and the same origin policy stops another site from reading the response to an authenticated GET.
Safeguard's free scan at gold.safeguard.sh/scan checks the dependencies in your front end and API projects.
Sources
Last reviewed: 19 October 2026.
