How do you secure a Web API in ASP.NET Core (HTTPS, authentication, CORS, input validation, rate limits, secrets, XSS and CSRF)?

Say it out loud, then check

Every layer, on the real system

The same request on BMW FS's Azure setup: which part of the system does each job, from the dealer's browser to the database.

The story

1. Before

   BMW FS's dealer API grew over three years, one endpoint at a time. Each developer added the security they remembered: [Authorize] on most controllers (an attribute, a label in square brackets, that makes an endpoint require sign-in; an endpoint is one address the API answers), a CORS rule copied from an old project (a browser rule about which other websites may call the API), a few checks inside actions. [AllowAnonymous] is the opposite label: open to everyone. Nothing was wrong on purpose; it just depended on everyone remembering everything. Every request passes through a pipeline, an ordered list of steps set up in Program.cs; the fix puts the security there.

   Loans[Authorize]

   Dealersno attribute

   Quotesanonymous

   1/4Before: every endpoint carries its own security, added by whoever wrote it.A new endpoint shipped without [Authorize]. It answered anyone, signed in or not.Fix: layers in the pipeline that every request passes, with sign-in required by default.Now a forgotten attribute means "signed in only"; public endpoints say [AllowAnonymous] on purpose.

   BackPlayNext
2. Why it had to change

   Security that depends on every developer remembering every rule fails the first time someone forgets. In BMW FS's case, a new dealers endpoint shipped without [Authorize], and for two weeks it answered anyone who knew the address.

3. How it works now

   A senior answer to "how do you secure an API" is defence in depth: several layers, each stopping a different attack, set up once in Program.cs so every request passes them. HTTPS for the wire, CORS for browsers, authentication and authorization for who may call, rate limits for abuse, and inside the endpoint, validation and a check that the record is the caller's. Secrets stay out of the code. The main diagram walks one request through the layers, then three attacks.

4. What we gained

   New endpoints are protected without anyone remembering to protect them, and each kind of attack has a known layer that stops it. The rest of the card covers secrets, CSRF and XSS, and the night BMW FS's new rate limiter answered with the wrong status code.

In the lending API

The pipeline: each Use... line is one layer of the diagram above, in the same order. Set-up comes first in the file, so the walk jumps back to it. Layer 1, HTTPS redirection, is just above these four.

Only the key lines are shown; Deep walks the whole file.

The code, file by file

The BMW FS dealer API's Program.cs: every layer, in pipeline order. Tap Next to walk one request.

What they ask next

The follow-ups interviews really ask. Answer out loud, then tap to check.

• ReportedWhat are the common security practices for securing a REST API?

  In layers. HTTPS with HSTS. Authentication with short-lived tokens, and authorization on by default through a fallback policy. A per-record check against BOLA. Server-side validation and DTOs. Parameterised SQL. Rate limits answering 429. CORS limited to our own front ends. Secrets in Key Vault with a managed identity. Errors without internal details, and logs without tokens or personal data. Then monitoring and alerts on 401, 403 and 429 spikes.

  Next questions, in Deep →Infosys: security practices for REST APIs
• ReportedWhat is an anti-forgery token, and does a JWT API need one?

  It's the defence against CSRF. The server puts a secret value in the real page and in a cookie, and checks they match on every form post; another site can make the browser send the cookie but can't read the page, so it can't send the value. In MVC that's [ValidateAntiForgeryToken]. An API that takes a bearer token in the Authorization header doesn't need it: the browser never adds that header by itself. An API that uses cookies does, along with SameSite cookies.

  Next questions, in Deep →Unlock Technologies: anti-forgery token
• ReportedHow do you protect a .NET application from XSS?

  Encode output, so user text is shown, never run. Razor views encode by default; Angular escapes interpolated values and sanitizes [innerHTML] by default, so the danger is code that bypasses that. An API returns JSON with Content-Type: application/json and the X-Content-Type-Options: nosniff header, so a browser never treats it as a page. A Content-Security-Policy header on the front end limits which scripts can run at all. Input validation helps, but encoding is the real defence.

  Next questions, in Deep →Corporate Infotech: XSS in .NET

Follow-up tree

Answer, then open the next level. That is the order an interviewer digs in.

Reporteda candidate was asked Intervieweran interviewer asks it

• ReportedWhat are the common security practices for securing a REST API?

  In layers. HTTPS with HSTS. Authentication with short-lived tokens, and authorization on by default through a fallback policy. A per-record check against BOLA. Server-side validation and DTOs. Parameterised SQL. Rate limits answering 429. CORS limited to our own front ends. Secrets in Key Vault with a managed identity. Errors without internal details, and logs without tokens or personal data. Then monitoring and alerts on 401, 403 and 429 spikes.

  Infosys: security practices for REST APIs
• ReportedWhat is an anti-forgery token, and does a JWT API need one?

  It's the defence against CSRF. The server puts a secret value in the real page and in a cookie, and checks they match on every form post; another site can make the browser send the cookie but can't read the page, so it can't send the value. In MVC that's [ValidateAntiForgeryToken]. An API that takes a bearer token in the Authorization header doesn't need it: the browser never adds that header by itself. An API that uses cookies does, along with SameSite cookies.

  Unlock Technologies: anti-forgery token
• ReportedHow do you protect a .NET application from XSS?

  Encode output, so user text is shown, never run. Razor views encode by default; Angular escapes interpolated values and sanitizes [innerHTML] by default, so the danger is code that bypasses that. An API returns JSON with Content-Type: application/json and the X-Content-Type-Options: nosniff header, so a browser never treats it as a page. A Content-Security-Policy header on the front end limits which scripts can run at all. Input validation helps, but encoding is the real defence.

  Corporate Infotech: XSS in .NET
• ReportedCookies and security: what flags matter?

  HttpOnly: JavaScript can't read it, so an XSS bug can't steal it. Secure: sent over HTTPS only. SameSite=Lax or Strict: not sent on most requests started by other sites, which blocks most CSRF. A session or refresh-token cookie gets all three.

  Driven IT Solutions: cookies in web security
• Where do you keep secrets like connection strings and API keys?

  Never in appsettings files or the repository. Locally, dotnet user-secrets, a file outside the project folder. In Azure, Key Vault, read at start-up with AddAzureKeyVault and DefaultAzureCredential, which signs in with the app's managed identity, so there's no password to protect. Better still, avoid the secret: Azure SQL and Storage accept the managed identity itself.

  See it in Make it yours →
• UseHttpsRedirection or HSTS: what's the difference?

  Redirection answers each http:// request with a redirect (307 by default) to https://, but that first request already went out unencrypted. HSTS is a header that tells the browser to use HTTPS for this site for a set time (30 days by default in .NET), so later requests never go out as http:// at all. The template adds HSTS only outside Development, and it never applies to localhost.

• Why does the rate limiter return 503, and what should it return?

  503 is just the built-in default for RejectionStatusCode. Set it to 429 Too Many Requests and add a Retry-After header in OnRejected: 429 tells the client it's their own rate, and well-behaved clients wait. A 503 looks like an outage to monitoring and to retry policies.

  Walk the incident →
• What's on the OWASP API Security Top 10?

  A list of the most common API holes. Interviewers mostly ask about the first few: broken object level authorization (changing an id to read another's record), broken authentication, broken object property level authorization (returning or accepting fields the caller shouldn't touch, which DTOs prevent), and unrestricted resource consumption (no rate limits or size limits). Name one, and say how your code prevents it.

Production bugs, and how to tell them

Each one: what you see, why, the fix in code, and the line to say.

• The portal's API answered every website with the user's cookies

  Origin: https://evil.example
  → Access-Control-Allow-Origin: https://evil.example
     Access-Control-Allow-Credentials: true

  Cause

  A cookie-based endpoint needed CORS with credentials. AllowAnyOrigin() with AllowCredentials() made .NET throw at start-up, so a developer replaced it with SetIsOriginAllowed(_ => true), which allows every origin by echoing back whatever origin asks. Any website a signed-in user visited could now call the API with their cookies and read the answers.

  Fix

  List the exact origins from configuration with WithOrigins(...). A security test sends a request from an unknown origin and fails if the response allows it.

  BeforeAfter

  1builder.Services.AddCors(o =>2 o.AddPolicy("dealer-sites", p => p3 .SetIsOriginAllowed(_ => true)4 .AllowCredentials()));

  Before · Program.cs · line 3 · 1 of 1Allows every origin, by echoing it back. With credentials, that hands any website the user's session.

  BackNext file

  Say it

  AllowAnyOrigin with credentials is refused by .NET for a reason. Echoing any origin back defeats that check. With credentials, list exact origins only.

• A search box that could read the whole table

  GET /api/dealers/search?name=x' OR '1'='1
  → 200 OK, 2,140 dealers

  Cause

  A dealer search used FromSqlRaw with the name pasted into the SQL string. The input x' OR '1'='1 closed the quote and added a condition that is always true, so the query returned every dealer: SQL injection.

  Fix

  Use LINQ, db.Dealers.Where(d => d.Name == name), or FromSql with an interpolated string. Both make EF Core send name as a SQL parameter. A test sends the same input and expects no rows.

  BeforeAfter

  1db.Dealers.FromSqlRaw(2 "SELECT * FROM Dealers WHERE Name = '"3 + name + "'");

  Before · DealerSearch.cs · line 3 · 1 of 1The input becomes part of the SQL text.

  BackNext file

  Say it

  Concatenating input into FromSqlRaw is SQL injection. LINQ, or FromSql with interpolation, sends the value as a parameter, so it can't change the query.

Traps

• Don't sayWe have CORS, so other sites can't call our API.SayCORS only limits pages in browsers. Scripts and Postman ignore it; authentication and authorization are the lock.
• Don't sayKeep the secrets in appsettings.Production.json; it isn't checked in.SayKey Vault with a managed identity. Files get copied, committed by mistake and read by anyone with server access.
• Don't sayAdd the rate limiter and keep its defaults.SaySet RejectionStatusCode = 429 and send Retry-After; the default 503 looks like an outage.
• Don't sayEvery endpoint has [Authorize], so we're covered.SayUntil someone forgets one. A fallback policy makes "signed in" the default, and a per-record check stops BOLA.

Traps

What should you say instead? Tap to check.

• Don't sayWe have CORS, so other sites can't call our API.

  Say instead

  CORS only limits pages in browsers. Scripts and Postman ignore it; authentication and authorization are the lock.

• Don't sayKeep the secrets in appsettings.Production.json; it isn't checked in.

  Say instead

  Key Vault with a managed identity. Files get copied, committed by mistake and read by anyone with server access.

• Don't sayAdd the rate limiter and keep its defaults.

  Say instead

  Set RejectionStatusCode = 429 and send Retry-After; the default 503 looks like an outage.

• Don't sayEvery endpoint has [Authorize], so we're covered.

  Say instead

  Until someone forgets one. A fallback policy makes "signed in" the default, and a per-record check stops BOLA.