It does not matter how clean your architecture is or how fast your queries run - if an attacker can read another user's orders or forge a token, none of that matters.

Most API security problems come from skipping the basics:

• Not updated NuGet package with security vulnerability
• Missing validation check
• Weak authentication setup
• An over-permissive CORS policy
• A secret committed to source control.

The good news is that ASP .NET Core gives you almost everything you need built in.

Over the years, I have shipped and reviewed many .NET APIs, and the same set of practices keeps them safe.

Here are 18 of them, each with the code to apply it.

In this post, we will explore:

• Enforce HTTPS everywhere
• Authenticate with tokens, not sessions
• Validate the JWT signature, issuer, audience, and lifetime
• Authorize with policies, not just [Authorize]
• Apply the principle of least privilege
• Validate and sanitize all input
• Protect against over-posting / mass assignment
• Validate content types and limit request size
• Use parameterized queries and EF Core
• Implement rate limiting and throttling
• Configure CORS restrictively
• Return minimal error detail
• Set security headers
• Store secrets securely
• Enforce CSRF protection where relevant
• Version your API and deprecate insecure endpoints
• Log and audit security events
• Keep dependencies patched

Let's dive in.

Every request to your API should travel over an encrypted connection.

Without HTTPS, tokens, passwords, and personal data move in plain text, where anyone on the network path can read them. Plain HTTP also opens the door to downgrade attacks, in which an attacker forces a client to use an insecure connection.

ASP .NET Core gives you two tools. UseHttpsRedirection redirects HTTP requests to HTTPS, and HSTS (HTTP Strict Transport Security) tells browsers to only ever connect over HTTPS:

csharp
1var builder = WebApplication.CreateBuilder(args);
2
3builder.Services.AddHsts(options =>
4{
5    options.MaxAge = TimeSpan.FromDays(365);
6    options.IncludeSubDomains = true;
7    options.Preload = true;
8});
9
10var app = builder.Build();
11
12if (!app.Environment.IsDevelopment())
13{
14    app.UseHsts();
15}
16
17app.UseHttpsRedirection();

UseHttpsRedirection upgrades any HTTP request to HTTPS. UseHsts adds the Strict-Transport-Security header, so compliant browsers refuse to talk to your API over plain HTTP at all - which blocks downgrade attacks.

HSTS is skipped during development because you often use http://localhost.

For the full setup, see Configuring HTTPS Redirection and HSTS in ASP .NET Core.

Prefer stateless token authentication over server-side sessions.

A session stores authentication state in server memory or a shared store, which ties each user to a server and makes horizontal scaling harder. A token carries its own proof of identity, so any instance of your API can validate it without a lookup.

For most APIs, that means JWT bearer tokens, often issued by an identity provider through OAuth 2.0 or OpenID Connect:

csharp
1builder.Services
2    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
3    .AddJwtBearer(options =>
4    {
5        options.Authority = "https://your-idp.com";
6        options.Audience = "shop-api";
7    });
8
9var app = builder.Build();
10
11app.UseAuthentication();
12app.UseAuthorization();

The client sends the token in the Authorization: Bearer <token> header on every request. Your API validates it and reads the user's identity from the token's claims - no session store, no sticky sessions, no server-side state to scale.

This keeps your API stateless and easy to scale horizontally.

If you also need to revoke access before a token expires, read How to Implement Refresh Tokens and Token Revocation.

Before accepting a token, you should trust it.

A token is only safe once you verify who issued it, who it is for, that it has not expired, and that its signature is valid. Configure these checks explicitly through TokenValidationParameters rather than trusting framework defaults:

csharp
1.AddJwtBearer(options =>
2{
3    options.TokenValidationParameters = new TokenValidationParameters
4    {
5        ValidateIssuer = true,
6        ValidIssuer = "https://your-idp.com",
7
8        ValidateAudience = true,
9        ValidAudience = "shop-api",
10
11        ValidateIssuerSigningKey = true,
12        IssuerSigningKey = new SymmetricSecurityKey(key),
13
14        ValidateLifetime = true,
15        ClockSkew = TimeSpan.FromSeconds(30)
16    };
17});

Each flag closes a hole:

• ValidateIssuerSigningKey confirms the signature - never turn this off, or anyone can forge a token.
• ValidateIssuer and ValidateAudience ensure the token came from your identity provider and was meant for your API, not some other service.
• ValidateLifetime rejects expired tokens.

Pay attention to ClockSkew.

It exists to tolerate small clock differences between servers, but its default is a generous 5 minutes, so an expired token can still be accepted for up to 5 extra minutes. Reducing it to about 30 seconds, or even zero, tightens token expiry enforcement, as long as your servers' clocks are synchronized (with NTP).

See Authentication and Authorization Best Practices for the complete picture.

Authentication tells you who the user is. Authorization decides what they are allowed to do.

A bare [Authorize] only checks that the user is logged in. Real rules - "only managers can delete orders", "users can only see their own data" - need policy-based and resource-based authorization.

Define a policy once:

csharp
1builder.Services.AddAuthorization(options =>
2{
3    options.AddPolicy("orders:write", policy =>
4        policy.RequireRole("Manager")
5              .RequireClaim("permission", "orders:write"));
6});

Apply it to a controller action:

csharp
1[ApiController]
2[Route("api/orders")]
3public class OrdersController : ControllerBase
4{
5    [HttpDelete("{id:int}")]
6    [Authorize(Policy = "orders:write")]
7    public IActionResult Delete(int id)
8    {
9        _orderService.Delete(id);
10        return NoContent();
11    }
12}

Or on a minimal API endpoint:

csharp
1app.MapDelete("/api/orders/{id:int}", (int id, IOrderService orders) =>
2{
3    orders.Delete(id);
4    return Results.NoContent();
5})
6.RequireAuthorization("orders:write");

When the rule depends on the specific resource - like "only the owner can edit this order" - use resource-based authorization with IAuthorizationService.AuthorizeAsync(user, order, "OrderOwner"), which evaluates the policy against the actual entity.

Policies keep authorization logic in one place, out of your endpoint bodies.

Give every client the minimum access it needs, and nothing more.

A token, a claim set, or an API key should grant exactly the permissions required for its job. A mobile app that only reads the product catalog should not hold a token capable of deleting orders.

Scope this at the token level. When your identity provider issues a token, it includes only the scopes that the client was granted, and your policies check for them:

csharp
1builder.Services.AddAuthorization(options =>
2{
3    options.AddPolicy("catalog:read", policy =>
4        policy.RequireClaim("scope", "catalog:read"));
5
6    options.AddPolicy("orders:write", policy =>
7        policy.RequireClaim("scope", "orders:write"));
8});

The same idea applies to API keys and database accounts - scope them down too. If a credential leaks, least privilege limits the blast radius to only what that one credential could do.

Treat every incoming payload as dangerous until proven valid.

Malformed or malicious input should be rejected at the edge, before it reaches your business logic or your database. ASP .NET Core helps here: with the [ApiController] attribute, a request that fails model validation automatically returns a 400 with a problem-details body.

Add data annotations or, for richer rules, FluentValidation:

csharp
1public class CreateProductRequest
2{
3    [Required]
4    [StringLength(200, MinimumLength = 1)]
5    public string Name { get; set; } = string.Empty;
6
7    [Range(0.01, 1_000_000)]
8    public decimal Price { get; set; }
9}
10
11[ApiController]
12[Route("api/products")]
13public class ProductsController : ControllerBase
14{
15    [HttpPost]
16    public IActionResult Create(CreateProductRequest request)
17    {
18        // If we get here, the model is already valid
19        var product = _productService.Create(request);
20        return CreatedAtAction(nameof(Get), new { id = product.Id }, product);
21    }
22}

The minimal API equivalent runs validation through a filter or explicitly:

csharp
1app.MapPost("/api/products",
2    (CreateProductRequest request, IValidator<CreateProductRequest> validator) =>
3{
4    var result = validator.Validate(request);
5    if (!result.IsValid)
6    {
7        return Results.ValidationProblem(result.ToDictionary());
8    }
9
10    var product = productService.Create(request);
11    return Results.Created($"/api/products/{product.Id}", product);
12});

Validating early turns a class of attacks - oversized strings, out-of-range numbers, missing fields - into a clean 400 instead of an exception deep in your code.

Never bind incoming JSON straight onto your database entity.

If clients post to your EF Core entity directly, they can set fields they should never control - IsAdmin, Balance, Status, or another user's Id. This is called over-posting, or mass assignment.

Bind to a dedicated request DTO that exposes only the fields a client is allowed to set, then map it onto the entity yourself:

csharp
1// Request DTO - only what the client may set
2public record UpdateProductRequest(string Name, decimal Price);
3
4[HttpPut("{id:int}")]
5public async Task<IActionResult> Update(int id, UpdateProductRequest request)
6{
7    var product = await _dbContext.Products.FindAsync(id);
8    if (product is null)
9    {
10        return NotFound();
11    }
12
13    // Map only the allowed fields
14    product.Name = request.Name;
15    product.Price = request.Price;
16
17    await _dbContext.SaveChangesAsync();
18    return NoContent();
19}

The Product entity might also have CreatedAt, OwnerId, or IsFeatured fields, but because the client can only send Name and Price, those fields are inaccessible from the outside.

Separate request models require a small amount of typing and close a whole category of privilege-escalation bugs.

Reject what you are not prepared to handle.

An endpoint that accepts JSON should reject other media types, and no endpoint should accept an unbounded request body - a multi-gigabyte upload is an easy way to exhaust server memory and take your API down.

Restrict the content type with [Consumes] and cap the body size with [RequestSizeLimit]:

csharp
1[HttpPost]
2[Consumes("application/json")]
3[RequestSizeLimit(1_000_000)] // 1 MB
4public IActionResult Create(CreateProductRequest request)
5{
6    var product = _productService.Create(request);
7    return CreatedAtAction(nameof(Get), new { id = product.Id }, product);
8}

You can also set a global limit through Kestrel:

csharp
1builder.WebHost.ConfigureKestrel(options =>
2{
3    options.Limits.MaxRequestBodySize = 1_000_000;
4});

The same discipline applies to the amount of data a client can pull back.

Always enforce pagination with a maximum page size on collection endpoints, so a client cannot request an unbounded result set:

csharp
1[HttpGet]
2public IActionResult GetProducts(int page = 1, int pageSize = 20)
3{
4    // Clamp the page size so no one can ask for everything at once
5    pageSize = Math.Min(pageSize, 100);
6
7    var products = _productService.GetPage(page, pageSize);
8    return Ok(products);
9}

Capping request size, content type, and page size all defend against the same thing: a single request that tries to consume more resources than your server can spare.

Never build SQL by concatenating strings together from user input.

String concatenation is how SQL injection happens - a crafted input like '; DROP TABLE Products; -- becomes part of your query. Parameterized queries keep user input as data, never as executable SQL.

EF Core parameterizes everything by default, so a LINQ query is always safe:

csharp
1// 1. Safe - EF Core parameterizes 'search'
2var products = await _dbContext.Products
3    .Where(p => p.Name.Contains(search))
4    .ToListAsync();

When you do need raw SQL, use FromSql orFromSqlInterpolated, which turn the interpolated values into parameters rather than literal text:

csharp
1// 2. Safe - 'category' becomes a SQL parameter, not concatenated text
2var products = await _dbContext.Products
3    .FromSqlInterpolated($"SELECT * FROM Products WHERE Category = {category}")
4    .ToListAsync();
5
6// 3. Dangerous - never do this
7var sql = "SELECT * FROM Products WHERE Category = '" + category + "'";
8
9// 4. And never use FromSqlRaw with string interpolation
10var products = await _dbContext.Products
11    .FromSqlRaw($"SELECT * FROM Products WHERE Category = {category}")
12    .ToListAsync();

The first two are safe; 3 and 4 are an attacker's door.

Limit how often a single client can call your API.

Without limits, one client - or one attacker - can hammer your login endpoint with brute-force attempts, or flood your API with requests until it falls over. ASP .NET Core has a built-in rate limiter you wire up in Program.cs:

csharp
1builder.Services.AddRateLimiter(options =>
2{
3    options.AddFixedWindowLimiter("api", limiter =>
4    {
5        limiter.PermitLimit = 10;
6        limiter.Window = TimeSpan.FromMinutes(1);
7        limiter.QueueLimit = 0;
8    });
9
10    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
11});
12
13var app = builder.Build();
14app.UseRateLimiter();

Then apply the policy to a controller action or a minimal API endpoint:

csharp
1[HttpPost("login")]
2[EnableRateLimiting("api")]
3public IActionResult Login(LoginRequest request) { /* ... */ }

csharp
1app.MapPost("/login", (LoginRequest request) => { /* ... */ })
2   .RequireRateLimiting("api");

When a client exceeds the limit, it gets a 429 Too Many Requests instead of reaching your code. This blunts brute-force and denial-of-service abuse.

Allow only the origins you trust to call your API from a browser.

Cross-Origin Resource Sharing (CORS) controls which web origins can make requests to your API. The dangerous shortcut is AllowAnyOrigin(), which lets any website on the internet call your API on behalf of a logged-in user.

Define a named policy that lists exactly the origins, methods, and headers you allow:

csharp
1builder.Services.AddCors(options =>
2{
3    options.AddPolicy("Shop", policy =>
4        policy.WithOrigins("https://shop.example.com")
5              .WithMethods("GET", "POST", "PUT", "DELETE")
6              .WithHeaders("Authorization", "Content-Type"));
7});
8
9var app = builder.Build();
10app.UseCors("Shop");

This says: only https://shop.example.com may call us, only with these methods, only with these headers. Everything else is refused.

Reserve AllowAnyOrigin for truly public, unauthenticated APIs - and never combine it with credentials.

For the full guide, see CORS in ASP .NET Core.

An error response should help the caller, not the attacker.

A raw exception page leaks stack traces, framework versions, file paths, and SQL - a map of your internals. Return a clean, standard error instead, using Problem Details (RFC 9457):

csharp
1builder.Services.AddProblemDetails();
2
3var app = builder.Build();
4
5if (app.Environment.IsDevelopment())
6{
7    app.UseDeveloperExceptionPage();
8}
9else
10{
11    // Production: a clean ProblemDetails response, no stack trace
12    app.UseExceptionHandler();
13}

In production, an unhandled exception returns a structured Problem Details body with a status code and a generic message - and nothing about your internals.

Keep detailed diagnostics in your logs, where only you can see them, not in the HTTP response, where a client can.

You can read more about Problem Details in Best Practices for Building REST APIs.

A few response headers harden your API against common browser-side attacks.

Headers like Content-Security-Policy, X-Content-Type-Options, and Referrer-Policy tell the browser how to treat your responses - which scripts may run, whether to guess content types, how much referrer information to leak.

Add them with a small piece of middleware that runs on every response:

csharp
1app.Use(async (context, next) =>
2{
3    var headers = context.Response.Headers;
4    headers["X-Content-Type-Options"] = "nosniff";
5    headers["Referrer-Policy"] = "no-referrer";
6    headers["Content-Security-Policy"] = "default-src 'self'";
7    headers["X-Frame-Options"] = "DENY";
8
9    await next();
10});

• X-Content-Type-Options: nosniff stops the browser from guessing (and mis-running) content types.
• Content-Security-Policy restricts where scripts, styles, and other resources may load from.
• Referrer-Policy controls how much of your URL is sent to other sites.
• X-Frame-Options: DENY prevents your responses from being embedded in a frame (clickjacking).

For a pure JSON API, these matter most when responses are rendered in a browser, but they are cheap insurance for any API.

Note: in production, consider using a maintained library or a reverse proxy to manage these headers and a stricter Content-Security-Policy tailored to your app.

Keys, connection strings, and tokens must never live in source control.

A secret committed to appsettings.json is a secret leaked - it stays in your Git history forever, visible to everyone with repository access. Also, when using AI Agents, they can directly read your secrets from your configuration, unless you deny access for them. Be aware of this!

Keep secrets out of the codebase entirely.

In development, use the .NET Secret Manager:

bash
1dotnet user-secrets init
2dotnet user-secrets set "ConnectionStrings:Shop" "Server=...;Password=..."

In production, use environment variables or a managed secret store like Azure Key Vault:

csharp
1builder.Configuration.AddAzureKeyVault(
2    new Uri("https://shop-vault.vault.azure.net/"),
3    new DefaultAzureCredential());
4
5var connectionString = builder.Configuration.GetConnectionString("Shop");

Your code then reads the configuration the same way, regardless of where the value came from.

The application does not care about the source - only that the value is not sitting in a committed file.

Cross-Site Request Forgery protection matters when you authenticate with cookies.

CSRF tricks a logged-in user's browser into sending an unwanted request, using the cookie the browser attaches automatically. If your API authenticates with cookies, you need anti-forgery tokens:

csharp
1builder.Services.AddAntiforgery(options =>
2{
3    options.HeaderName = "X-CSRF-TOKEN";
4});
5
6var app = builder.Build();
7app.UseAntiforgery();

Then require a valid token on state-changing endpoints:

csharp
1[HttpPost]
2[ValidateAntiForgeryToken]
3public IActionResult Create(CreateOrderRequest request) { /* ... */ }

Here is the important nuance: pure token-based APIs are largely immune to CSRF.

If your client sends a JWT in the Authorization header (not a cookie), the browser does not automatically attach it, so a forged cross-site request carries no credentials. You mainly need antiforgery for cookie-authenticated endpoints - server-rendered apps and APIs that use cookie auth.

Match the protection to your authentication model: cookies need CSRF defense, bearer tokens generally do not.

Versioning lets you retire a bad design without breaking every client at once.

When an endpoint turns out to be insecure or poorly shaped, you need a way to introduce a fixed version and phase out the old one on a schedule. API versioning gives you that path.

Add the Asp.Versioning.Mvc package and mark the old version deprecated:

csharp
1builder.Services.AddApiVersioning(options =>
2{
3    options.DefaultApiVersion = new ApiVersion(2, 0);
4    options.ReportApiVersions = true;
5});

csharp
1[ApiController]
2[ApiVersion("1.0", Deprecated = true)]
3[ApiVersion("2.0")]
4[Route("api/v{version:apiVersion}/orders")]
5public class OrdersController : ControllerBase
6{
7    // v2 fixes the insecure contract; v1 is marked deprecated
8}

ReportApiVersions adds api-supported-versions and api-deprecated-versions headers to your responses, so clients see the deprecation coming and can migrate before you remove v1.

This turns "we cannot fix it because clients depend on it" into a managed migration.

Security events - failed logins, authorization denials, suspicious request patterns - need to be logged with enough context to reconstruct what happened. Capture them as structured logs:

csharp
1[HttpPost("login")]
2public async Task<IActionResult> Login(LoginRequest request)
3{
4    var result = await _authService.AuthenticateAsync(request);
5    if (!result.Succeeded)
6    {
7        _logger.LogWarning(
8            "Failed login for {Email} from {IpAddress}",
9            request.Email, HttpContext.Connection.RemoteIpAddress);
10
11        return Unauthorized();
12    }
13
14    return Ok(result.Token);
15}

Log authentication failures, authorization denials, and anything that appears to be probing.

Record enough context to support a real forensic investigation - which can include sensitive details where your threat model requires them, such as the account, the source IP, and the action attempted.

Because those logs can contain sensitive data, treat them as sensitive: store them where only authorized people can read them, and apply retention and access controls.

For setup, see Logging Best Practices in ASP .NET Core.

Most breaches exploit known vulnerabilities, not new ones.

Your API depends on dozens of NuGet packages and the .NET runtime, and each is a potential entry point when a security fix ships and you have not applied it. Staying current is one of the highest-value things you can do.

.NET can list vulnerable packages for you:

bash
1dotnet list package --vulnerable
2dotnet list package --outdated

Run these regularly, and wire the scan into your CI pipeline so a known-vulnerable dependency fails the build:

bash
1# Include transitive dependencies - a vulnerability three packages deep is still yours
2dotnet list package --vulnerable --include-transitive

Update your NuGet packages and the .NET runtime on a schedule, not only when something breaks. Combined with a tool like Dependabot or GitHub security alerts, this closes the gap attackers rely on most.

Security is not a single feature you add at the end. It is a set of habits applied across the whole API.

Let's recap the key takeaways:

• Secure the connection. Enforce HTTPS with redirection and HSTS, and add security headers so responses are hard to abuse.
• Get authentication and authorization right. Use stateless tokens, validate every part of the JWT (including a tight ClockSkew), and authorize with policies and least privilege - not just [Authorize].
• Treat all input as hostile. Validate and sanitize payloads, bind to request DTOs to stop over-posting, cap request and page size, and let EF Core parameterize your queries.
• Defend against abuse. Rate-limit clients, restrict CORS to trusted origins, and apply CSRF protection wherever you use cookie authentication.
• Do not leak information. Return minimal error detail with Problem Details, and keep secrets in a vault or environment, never in source control.
• Operate securely over time. Version and deprecate insecure endpoints, log and audit security events into access-controlled storage, and keep your dependencies patched.

No single practice makes an API secure, and you do not have to apply all 18 at once.

Start with the ones that close your biggest gaps - usually HTTPS, token validation, authorization, and input validation - then work down the list.

I am building a deep-dive System Design course.

It will be better than anything you have seen so far:

• Reading
• Watching videos
• Designing real systems in the browser
• Taking tests

Join the waitlist here to get early access and a launch discount.

Hope you find this newsletter useful. See you next time.