When Is CSRF Relevant to Angular + ASP.NET Core Applications?

1. What is the Main Rule?

CSRF is mainly relevant when the browser automatically sends authentication credentials with a request.

The easiest rule to remember is:

If authentication credentials are automatically attached by the browser—especially cookies—think about CSRF.

For Angular + ASP.NET Core:

Authentication Cookie
        ↓
Browser sends automatically
        ↓
CSRF is relevant

But with a bearer token that Angular explicitly attaches:

Angular
   ↓
Authorization: Bearer <token>
   ↓
ASP.NET Core

traditional cookie-based CSRF is generally not the primary concern.

2. Full Simple Sample Program

Let's compare two common architectures.

Scenario A — Cookie Authentication

ASP.NET Core Program.cs

using Microsoft.AspNetCore.Authentication.Cookies;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();

builder.Services
    .AddAuthentication(
        CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.Cookie.Name = "MyAuthCookie";

        options.Cookie.HttpOnly = true;
        options.Cookie.SecurePolicy =
            CookieSecurePolicy.Always;

        options.Cookie.SameSite =
            SameSiteMode.Lax;
    });

builder.Services.AddAuthorization();

var app = builder.Build();

app.UseHttpsRedirection();

app.UseAuthentication();
app.UseAuthorization();

app.MapControllers();

app.Run();

After login, the browser might have:

MyAuthCookie=abc123

Now Angular sends:

this.http.post(
  '/api/orders',
  order
);

The browser may automatically send the cookie:

POST /api/orders
Cookie: MyAuthCookie=abc123

Angular doesn't need to manually retrieve and attach the authentication cookie.

This is where CSRF matters.

An attacker may try to cause the victim's browser to send a state-changing request while the victim is authenticated.

Therefore:

Cookie Authentication
        ↓
Automatically sent credential
        ↓
CSRF relevant

3. Scenario B — Bearer JWT Explicitly Attached by Angular

Suppose Angular obtains an access token.

An interceptor explicitly attaches it.

auth.interceptor.ts

import {
  HttpInterceptorFn
} from '@angular/common/http';

export const authInterceptor:
  HttpInterceptorFn = (req, next) => {

    const token =
      sessionStorage.getItem(
        'access_token'
      );

    if (!token) {
      return next(req);
    }

    const authRequest =
      req.clone({
        setHeaders: {
          Authorization:
            `Bearer ${token}`
        }
      });

    return next(authRequest);
};

The resulting request is:

GET /api/products
Authorization: Bearer eyJhbGciOi...

The important difference is:

Browser
   ↓
Does NOT automatically know
it should attach this bearer token

Angular application
   ↓
Reads token
   ↓
Interceptor
   ↓
Explicitly creates
Authorization header

A malicious website cannot normally cause the victim's browser to automatically add your Angular application's bearer token to its request.

Therefore:

Traditional CSRF is generally not the main threat in this architecture.

XSS and token theft become particularly important concerns because the token is accessible to your application's JavaScript.

4. The Critical Difference

Compare the two architectures:

This is the most important interview point.

5. JWT Does NOT Automatically Mean No CSRF

A common misunderstanding is:

"We use JWT, so CSRF doesn't apply."

That's not necessarily correct.

The important question is:

How is the JWT sent?

JWT in HttpOnly Cookie

Suppose ASP.NET Core sends:

Set-Cookie: access_token=eyJ...

with:

HttpOnly
Secure

The browser automatically sends the cookie when applicable:

Cookie: access_token=eyJ...

Therefore:

JWT
 ↓
Stored in Cookie
 ↓
Cookie automatically sent
 ↓
CSRF relevant

JWT in Browser Storage + Authorization Header

Suppose Angular stores a token:

sessionStorage.setItem(
  'access_token',
  token
);

and explicitly adds:

Authorization: Bearer <token>

Then:

JWT
 ↓
Browser-accessible storage
 ↓
Angular reads token
 ↓
Interceptor explicitly adds header
 ↓
Traditional cookie-based CSRF
is generally not the main issue

But now XSS deserves particular attention because injected JavaScript may be able to access browser-stored tokens.

6. HttpOnly Cookie Doesn't Eliminate CSRF

Suppose:

Cookie:
HttpOnly = true

JavaScript cannot directly read the cookie.

That's good.

But the browser can still send the cookie automatically.

HttpOnly Cookie

JavaScript
    |
    X
Cannot read cookie


Browser
    |
    ✓
Can automatically send cookie

Therefore:

HttpOnly primarily protects against JavaScript reading the cookie; it does not by itself solve CSRF.

7. When Should Angular + ASP.NET Core Implement Anti-Forgery Protection?

Consider anti-forgery protection when:

Angular
   ↓
ASP.NET Core
   ↓
Authentication uses cookies
   ↓
Browser automatically sends them

Particularly for state-changing operations:

POST
PUT
PATCH
DELETE

Examples include:

POST   /api/orders
POST   /api/payments
PUT    /api/profile
PATCH  /api/account
DELETE /api/products/10

8. GET Requests Should Not Change Data

Avoid APIs such as:

GET /api/deleteProduct?id=10

because GET should be a safe/read-only operation.

Instead:

DELETE /api/products/10

Similarly, don't design:

GET /api/transfer?amount=5000

Use a state-changing method:

POST /api/transfers

Then apply appropriate authentication, authorization, and CSRF protection if cookie authentication is used.

9. Angular's XSRF Support

Angular HttpClient supports the common cookie-to-header XSRF pattern.

Conceptually, ASP.NET Core provides a token using a cookie such as:

XSRF-TOKEN

Angular reads that token and sends it in a header such as:

X-XSRF-TOKEN: <token>

The server validates it.

ASP.NET Core
     |
     | Generates anti-forgery token
     v
XSRF-TOKEN cookie
     |
     v
Angular HttpClient
     |
     | Reads token
     v
X-XSRF-TOKEN header
     |
     v
ASP.NET Core
     |
     | Validate token
     v
Controller

The exact Angular/API origin arrangement matters when configuring this mechanism.

10. Why Can't an Attacker Simply Send the CSRF Header?

The defense relies on the attacker's cross-site page not being able to obtain the valid anti-forgery token.

The victim's legitimate Angular application has access to the token mechanism and sends:

X-XSRF-TOKEN: valid-token

The attacker's request should not have a valid matching token.

ASP.NET Core can therefore reject it.

Conceptually:

Authentication Cookie
        ✓

CSRF Token
        X
        |
        v
Request rejected

11. SameSite Cookies Also Help

Cookie configuration provides another important layer.

For example:

options.Cookie.SameSite =
    SameSiteMode.Lax;

Common values are:

Strict
Lax
None

SameSite can restrict when cookies are sent in cross-site contexts.

Therefore modern CSRF defense commonly involves a combination of:

Anti-forgery protection
        +
SameSite cookies
        +
HTTPS
        +
Secure cookie settings
        +
Safe HTTP methods

depending on the application's architecture.

12. CSRF vs CORS

Don't confuse CSRF with CORS.

CORS

Controls which origins are allowed to make/read certain cross-origin browser requests.

Example:

policy.WithOrigins(
    "https://myapp.com");

CSRF

Protects against an attacker causing an authenticated user's browser to perform an unwanted action.

Therefore:

CORS
!=
CSRF protection

A correctly configured CORS policy is useful, but you shouldn't treat CORS as a replacement for CSRF defenses.

13. CSRF vs XSS

This distinction is especially important for Angular interviews.

CSRF

Attacker
   ↓
Victim's browser
   ↓
Automatically sends credentials
   ↓
Unwanted authenticated request

XSS

Attacker-controlled content
   ↓
Application renders it unsafely
   ↓
Malicious JavaScript executes
   ↓
Inside trusted application's origin

A simple way to remember:

CSRF abuses the browser's automatic credential behavior. XSS executes attacker-controlled code in the trusted application's browser context.

14. Practical Decision Flow

When reviewing an Angular + ASP.NET Core application, ask:

How is the user authenticated?
          |
          v
Are credentials automatically
sent by the browser?
      /          \
    YES           NO
     |             |
     v             v
CSRF is         Traditional
relevant        CSRF risk is
                much lower

For example:

Cookie Authentication
        ↓
       YES
        ↓
Consider CSRF protection

versus:

Bearer JWT
        ↓
Angular explicitly adds
Authorization header
        ↓
        NO
        ↓
Traditional CSRF is generally
not the primary concern

15. Key Points

1. Cookie authentication → CSRF matters

Because cookies may be automatically sent by the browser.

2. JWT doesn't determine CSRF risk by itself

Ask:

Where is the JWT stored, and how is it transmitted?

3. JWT in an automatically sent cookie → CSRF can still matter

JWT + Cookie
    ↓
Automatically sent
    ↓
CSRF relevant

4. Bearer token explicitly attached by Angular → traditional CSRF is much less relevant

Authorization: Bearer <token>

is normally added explicitly by Angular rather than automatically by the browser.

5. HttpOnly doesn't prevent CSRF

It prevents JavaScript from reading the cookie, but the browser may still send it.

6. Protect state-changing operations

Focus especially on:

POST
PUT
PATCH
DELETE

and don't use GET to modify server state.

16. Interview Questions and Answers

1. When is CSRF relevant in Angular + ASP.NET Core?

Answer:
CSRF is mainly relevant when authentication credentials, especially cookies, are automatically sent by the browser. Cookie-authenticated state-changing API requests should therefore be evaluated for CSRF protection.

2. Is CSRF relevant when using JWT?

Answer:
It depends on how the JWT is transmitted. If the JWT is stored in an automatically sent cookie, CSRF can still apply. If Angular explicitly adds it as a bearer token in the Authorization header, traditional cookie-based CSRF is generally much less relevant.

3. Does HttpOnly prevent CSRF?

No.

HttpOnly prevents JavaScript from reading the cookie, but the browser can still automatically send the cookie with requests.

4. Which HTTP methods normally need CSRF consideration?

State-changing methods such as:

POST
PUT
PATCH
DELETE

GET requests should not modify application state.

5. Does CORS prevent CSRF?

Not by itself.

CORS controls cross-origin browser access. CSRF defenses protect against forged authenticated requests. They address different security problems.

6. How does Angular help with CSRF?

Angular HttpClient supports an XSRF cookie/header pattern, commonly using:

XSRF-TOKEN
      ↓
X-XSRF-TOKEN

The ASP.NET Core backend must be configured to issue and validate the corresponding anti-forgery token.

Interview Quick Answer

CSRF is relevant to Angular + ASP.NET Core mainly when authentication credentials are automatically sent by the browser, especially with cookie-based authentication. If a JWT is stored in an automatically sent cookie, CSRF protection may still be required. If Angular explicitly attaches a bearer JWT using the Authorization header, traditional cookie-based CSRF is generally not the primary threat.