When you start building ASP.NET Core Web APIs, security tools like Coverity, SonarQube, or Fortify may suddenly report warnings such as “Cross-Site Request Forgery (CSRF) vulnerability detected”. For beginners, this can be confusing and even alarming — especially when your API already uses JWT authenticationand works perfectly fine.
In this article we are going to see what CSRF really is, why these warnings appear, and when you actually need to worry about them, using simple language and practical examples.
What is CSRF (in simple terms) ?
Here is the simplest way to visualize a CSRF attack from start to finish:
- You log into MyBank.com. Your browser now holds a Session Cookie (your digital “ID Badge”). As long as you don’t log out, your browser will show this badge to the bank every time they talk.
- Without logging out of your bank, you open a new tab and visit a Shady-Site.com (the “Bad” website).
- 3. Inside that shady website, there is a hidden line of code that looks like this:
Transfer $500 to Hacker - The moment you land on the shady site, it forces your browser to send that transfer command to MyBank.com.
- Your browser thinks: “Oh, a request for MyBank! I’ll attach the ID Badge (Cookie) so they know who it is.”
- Crucial Point: Your browser does this automatically without asking you.
- MyBank.com receives the request. It sees your valid ID Badge attached. It thinks, “This must be from the user,” and it processes the transfer.
CSRF attacks work because browsers automatically send cookies. CSRF is like a forged signature.
Example:
Consider this API endpoint:
This endpoint:
- Accepts a POST request
- Updates the database
- Looks completely normal
However, a security scanner may still flag it as CSRF vulnerable. Why ? Static analysis tools look at patterns, not runtime behavior.
They see:
- A POST method
- Data modification
- No visible CSRF token validation
So they assume: “This request might be authenticated using cookies and needs CSRF protection.”
They do not know how your authentication is actually implemented.
How Modern Angular + ASP.NET Core Apps Authenticate?
When you useJWT tokens (common in React, Angular, and ASP.NET Core), the rules change. This setup is naturally much safer against CSRF. Here is how it works:
1. The Token is Manual
Unlike cookies, which are “sticky” and stay in the browser’s pocket, a JWT Bearer Token is just a piece of text your code holds. The browser never sends it to the server unless your JavaScript code (Angular/React) specifically attaches it.
2. The Bad Website is Powerless
If you visit a “bad” website while logged in with a JWT:
- The bad website tries to send a command to your bank/API.
- The browser does not automatically attach the JWT token.
- The bad website cannot “steal” the token from your React app because browsers have security walls (Same-Origin Policy) that prevent one site from reading another site’s data.
3. The Server Rejects the Forgery
When the fake request arrives at your API:
- The API looks for the
Authorization: Bearer <token>header. - Since the browser didn’t add it automatically, the header is missing.
- The API says, “I don’t know who this is,” and blocks the request.
CSRF protection is usually unnecessary for JWT APIs because authentication is manual, not automatic. Since browsers do not automatically attach Bearer tokens to requests, a forged request from a malicious site will lack the requiredAuthorization header. Your API will simply see the missing token and reject the request, making the CSRF attack impossible.
What You Can Do About It
Option 1: Explicitly Ignore CSRF for API Endpoints
This clearly documents that CSRF protection is intentionally not used.
Option 2: Document the Security Decision
Add a note in your security documentation explaining:
- JWT Bearer authentication is used
- No cookie-based authentication exists
- CSRF protection is not applicable
This is common in enterprise projects.
Conclusion
In this article, we have seen that CSRF is primarily a risk for cookie-based sites, while JWT-based APIs are naturally protected because browsers don’t send tokens automatically. By understanding your authentication flow, you can confidently distinguish between real security threats and false positives from static analysis tools.
Recommendation for ASP.NET 10.0 Hosting
A solid base for developing online services and applications is ASP.NET. Before creating an ASP.NET web application, you must be proficient in JavaScript, HTML, CSS, and C#. There are thousands of web hosting providers offering ASP.NET hosting on the market. However, there are relatively few web hosting providers that offer top-notch ASP.NET hosting.
ASP.NET is the best development language in Windows platform, which is released by Microsoft and widely used to build all types of dynamic Web sites and XML Web services. With this article, we’re going to help you to find the best ASP.NET Hosting solution in Europe based on reliability, features, price, performance and technical support. After we reviewed about 30+ ASP.NET hosting providers in Europe, our Best ASP.NET Hosting Award in Europe goes to HostForLIFE.eu, one of the fastest growing private companies and one of the most reliable hosting providers in Europe.
