In an Angular app, how do you change the XSRF cookie and header names HttpClient uses, or turn its XSRF handling off, and when is each justified?

## The defaults you are changing Out of the box, `provideHttpClient()` registers an XSRF interceptor that reads the cookie **`XSRF-TOKEN`** and writes its value into the header **`X-XSRF-TOKEN`** on same-origin requests other than `GET` and `HEAD`. Two features passed to `provideHttpClient` adjust that behaviour. ## Renaming: withXsrfConfiguration ```ts provideHttpClient( withXsrfConfiguration({cookieName: 'CSRF-TOKEN', headerName: 'X-CSRF-TOKEN'}), ) ``` - Both properties are optional; pass only the one you need to change and the other keeps its default. - The interceptor's rules do not change: same methods skipped, same origin check, existing headers still never overwritten. When it is justified: 1. **The backend expects other names.** Many server frameworks default to their own cookie and header names; matching them in Angular is simpler than reconfiguring the server. 2. **Several Angular apps share one domain or subdomain.** Cookies are scoped by domain, so two apps using `XSRF-TOKEN` can overwrite each other's token. The security guide recommends a unique cookie name per app. ## Turning it off: withNoXsrfProtection ```ts provideHttpClient(withNoXsrfProtection()) ``` This disables the interceptor for that `HttpClient` configuration: no header is ever added. The guide describes it as the option for when the built-in mechanism does not work for your application. It is justified when XSRF is **not a risk or is handled elsewhere**: - The API authenticates with a **bearer token in the `Authorization` header** rather than a cookie. A forged cross-site request cannot attach that header, so there is nothing for the cookie-to-header check to add. - The backend uses a **different CSRF defence** and does not expect this header. It is **not** justified as a quick way to make `403` errors disappear. If requests fail the backend's check, the usual causes are a missing cookie, a name mismatch or a cross-origin URL, and disabling the client half fixes none of them. ## Using both is an error The two features contradict each other. In development mode, `provideHttpClient` checks for this and throws a configuration error saying it found both `withXsrfConfiguration()` and `withNoXsrfProtection()` in the same call. Production builds skip that check, so the mistake should be caught in development. ## Supplying the token from somewhere else If the backend delivers the token some other way, such as in a `<meta>` tag instead of a cookie, the renaming feature does not help. `@angular/common/http` exports the abstract class **`HttpXsrfTokenExtractor`**, whose `getToken()` the interceptor calls; providing your own implementation in its place lets the built-in interceptor keep its method and origin rules while reading the token from your source. ## Where the configuration applies Both features configure the `HttpClient` set up by that particular `provideHttpClient` call, which in most apps is a single call in the application's bootstrap providers, such as `appConfig`. Put the XSRF feature in that same call, next to any other features the app uses, rather than in a separate provider list; one call per app keeps the configuration in one readable place. ## Checking the result After changing names, open the browser's network panel and inspect a same-origin `POST`: the request should carry the new header name with the value of the new cookie. If the header is missing, check that the server now issues the cookie under the new name and that the cookie is readable by script. ## Old code you may meet | NgModule-era API | Current replacement | | :--- | :--- | | `HttpClientXsrfModule.withOptions({cookieName, headerName})` | `withXsrfConfiguration({cookieName, headerName})` | | `HttpClientXsrfModule.disable()` | `withNoXsrfProtection()` | `HttpClientXsrfModule` is deprecated, along with `HttpClientModule`; new code configures `HttpClient` through `provideHttpClient` and its features. ## Quick decision guide - Cookie-based session, default names acceptable: change nothing. - Cookie-based session, backend uses other names or apps share a domain: `withXsrfConfiguration`. - Token in `Authorization` header, no cookie auth: `withNoXsrfProtection` is reasonable. - Requests are failing and you are not sure why: diagnose before disabling anything.