Security

#Authentication, authorization, cookies and tokens

A signed-in caller is not automatically allowed to read every invoice. Authentication establishes identity; authorization decides access to an operation and resource. APIs normally return 401 for missing or invalid authentication and 403 for insufficient permission; sometimes 404 avoids revealing a resource's existence.

A cookie is a transport and storage mechanism; JWT is a token format. They are not opposites. HttpOnly blocks JavaScript from reading a cookie but cannot prevent XSS from making authenticated requests.

#OAuth 2.0, OIDC and current flows

OAuth 2.0 delegates API access using an access token; it is not a login protocol by itself. OIDC adds user authentication and an ID token for the client. APIs accept their intended access tokens, rather than ID tokens issued to the login client.

1. The client generates a random code verifier, an S256 challenge and state binding the request to its response.
2. The user signs in at the identity provider using an exactly registered redirect URI; OIDC uses nonce to bind the ID token to the request.
3. A short-lived authorization code returns and is exchanged with the verifier at the token endpoint.
4. The client validates the OIDC response and ID token, then calls the API with the access token. Refresh-token issuance depends on scope and provider policy.

PKCE addresses code interception; it does not replace state or redirect validation. Confidential clients still authenticate themselves. Client credentials represents a service without a user; prefer managed identity or certificates when supported.

See OAuth security best current practice.

#JWT validation and refresh-token rotation

A typical signed JWT contains a header, payload and signature. Base64Url is not encryption; claims must not contain secrets. Validate using a trusted issuer's keys and accepted algorithms, rather than merely decoding or trusting an attacker-controlled alg header.

// Package: Microsoft.AspNetCore.Authentication.JwtBearer 10.x
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority = "https://identity.example.com"; // (1)
        options.Audience = "orders-api";
        options.MapInboundClaims = false;
        options.TokenValidationParameters = new()
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            RequireSignedTokens = true,
            ValidAlgorithms = [SecurityAlgorithms.RsaSha256], // (2)
            ClockSkew = TimeSpan.FromSeconds(30)
        };
    });
builder.Services.AddAuthorization();
// After builder.Build():
app.UseAuthentication();
app.UseAuthorization();
app.MapGet("/orders", () => Results.Ok()).RequireAuthorization(); // (3)

Short-lived access tokens limit theft exposure, without one universal lifetime. Offline validation cannot instantly observe revocation; denylists or introspection add state and cost. Refresh rotation atomically consumes a token and issues its successor, detects reuse and revokes a family under provider policy. Coordinate parallel refreshes so legitimate retries are handled deliberately. See JWT bearer configuration.

#ASP.NET Core Identity and .NET 10 passkeys

Identity manages users, password hashing, roles, lockout, email confirmation and recovery tokens. It is not a complete OAuth authorization server. Its API endpoint bearer tokens are not necessarily JWTs and are not a general replacement for an OIDC provider.

ASP.NET Core 10 adds Identity passkey support using WebAuthn. Registration stores a public key; login signs a challenge bound to the relying party and origin. A biometric or PIN authorizes local key use; the server receives neither biometric data nor the private key.

1. Issue a fresh, short-lived challenge bound to the operation and user where applicable.
2. The browser and authenticator perform the WebAuthn ceremony.
3. Verify challenge, origin, RP ID, signature and required user verification.
4. Provide credential management, device-loss handling and appropriately secure recovery.

Origin binding resists phishing, but weak recovery can undermine it. Some credentials synchronize through passkey managers, so do not assume every private key is confined to one physical device. See Identity passkeys.

#Roles, claims, policies and resource authorization

A role such as Finance is a broad classification. A claim is an assertion from a trusted issuer. Policies combine requirements, and handlers evaluate them. Resource-based authorization fits decisions involving an order's owner and state, beyond caller identity alone.

builder.Services.AddAuthorizationBuilder()
    .AddPolicy("orders.edit", policy => policy
        .RequireAuthenticatedUser()
        .RequireClaim("permission", "orders.edit")); // (1)

// Endpoint fragment: tenant and user IDs come from validated identity context.
var order = await db.Orders.SingleOrDefaultAsync(
    o => o.Id == id && o.TenantId == tenantId, ct); // (2)
if (order is null) return Results.NotFound();
var decision = await authorization.AuthorizeAsync(
    user, order, "EditOwnPendingOrder");             // (3)
if (!decision.Succeeded) return Results.Forbid();
// Perform the update with concurrency protection.

This fragment omits the handler implementation. Also require the endpoint permission policy and enforce tenant boundaries in reads, writes, jobs and exports. EF Core filters provide defense in depth, but raw SQL, IgnoreQueryFilters and administrative paths still need review. Cache keys, blob paths and message handlers also require tenant isolation. See resource authorization.

#OWASP Top 10:2025 mapped to .NET

This is risk awareness, rather than certification of application security. This table uses 2025; SSRF is no longer a standalone category as in 2021, but remains a threat to mitigate.

Category names follow OWASP Top 10:2025.

#SQL injection: separate data from executable syntax

Concatenating a username into SQL lets input alter query meaning. Validation does not replace parameters. EF LINQ normally parameterizes values, while concatenated raw SQL remains dangerous.

var sql = $"SELECT * FROM Users WHERE Email = '{email}'";
var users = await db.Users.FromSqlRaw(sql).ToListAsync(ct);

var users = await db.Users
    .Where(user => user.Email == email)
    .ToListAsync(ct);                                    // (1)

// If raw SQL is required, pass interpolation directly to FromSql:
var matches = await db.Users
    .FromSql($"SELECT * FROM Users WHERE Email = {email}") // (2)
    .ToListAsync(ct);

Use a least-privileged database account. Apply the same separation to shell execution: prefer APIs and validated argument lists over constructed command strings.

#XSS and CSRF: different attacks

XSS runs attacker script in your origin, exposing data and authenticated actions. Razor HTML-encodes by default, but Html.Raw with user content or DOM innerHTML is dangerous. Rich HTML requires a maintained sanitizer, and JavaScript or URL contexts need their own encoding rules.

@Html.Raw(Model.CustomerNote)

@Model.CustomerNote

CSRF exploits automatic cookie attachment when a victim visits an attacker page. Validate antiforgery tokens on state-changing cookie-authenticated requests, with SameSite as another layer. GET must not mutate state. CORS is not a complete CSRF defense.

// MVC cookie-authenticated app; register before Build.
builder.Services.AddControllersWithViews(options =>
    options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute())); // (1)

// Razor form: the form tag helper normally generates this token already.
// Explicit generation is shown to make the mechanism visible.
// @Html.AntiForgeryToken()                                      // (2)

Content-Security-Policy adds XSS defense without replacing encoding. Explicitly attached bearer headers reduce conventional CSRF exposure, but putting that token in a cookie restores automatic attachment. See ASP.NET Core antiforgery guidance.

#SSRF: the server must not proxy arbitrary URLs

A user-supplied image URL can target cloud metadata or internal services. Checking an https prefix is insufficient: redirects, DNS rebinding, IPv6 and alternate IP formats create other routes.

var bytes = await http.GetByteArrayAsync(userSuppliedUrl, ct);

builder.Services.AddHttpClient("product-images", client =>
    client.BaseAddress = new Uri("https://images.example.com/"))
    .ConfigurePrimaryHttpMessageHandler(() =>
        new HttpClientHandler { AllowAutoRedirect = false }); // (1)

// Endpoint fragment; imageId is a validated Guid, not a path or URL.
var client = clients.CreateClient("product-images");
using var response = await client.GetAsync(
    $"products/{imageId:N}", HttpCompletionOption.ResponseHeadersRead, ct); // (2)
response.EnsureSuccessStatusCode();

Add egress firewall or proxy rules against private, loopback, link-local and metadata destinations, DNS controls, timeouts and a hard streamed-body limit even without Content-Length. If arbitrary URLs are a real requirement, validate resolved destinations and each redirect and connection, rather than relying on a superficial host check. See the OWASP SSRF guidance.

#Password hashing, encryption and HMAC

A general hash such as SHA-256 is a one-way fingerprint but is too fast for password storage. Use a slow, randomly salted password hasher with an appropriate work factor, such as Identity PBKDF2 or a maintained Argon2id implementation. A salt is not secret: it prevents shared precomputation across users but cannot rescue a weak password.

using Microsoft.AspNetCore.Identity;

var hasher = new PasswordHasher<IdentityUser>();
var storedHash = hasher.HashPassword(user, password);       // (1)
var result = hasher.VerifyHashedPassword(user, storedHash, suppliedPassword); // (2)
if (result == PasswordVerificationResult.SuccessRehashNeeded)
{
    // Persist a replacement hash through the user store after successful login.
}

Never log passwords or hashes. Measure work-factor changes on your resources so hashing cannot easily become a resource-exhaustion path.

#Secrets, Data Protection and dependency scanning

Use development user-secrets, which are not an encrypted vault. In production, prefer a vault and workload identity where possible, with least privilege and rotation. Environment variables transport configuration but can still leak through dumps or logs. Revoke and replace committed secrets immediately; deleting the file is insufficient.

ASP.NET Core Data Protection protects application state with encryption, integrity, purpose isolation and key rotation. Instances sharing cookies need the same application discriminator and persistent key ring, protected at rest. It is distinct from Windows DPAPI and is not automatically a KMS replacement for long-lived archives.

using Microsoft.AspNetCore.DataProtection;

builder.Services.AddDataProtection().SetApplicationName("Shop"); // (1)
// Production: configure persistent shared keys and encryption at rest.

public sealed class ProtectedState(IDataProtectionProvider provider)
{
    private readonly IDataProtector _protector =
        provider.CreateProtector("checkout-state.v1");           // (2)
    public string Protect(string value) => _protector.Protect(value);
    public string Unprotect(string value) => _protector.Unprotect(value);
}

# .NET 10 SDK form; include indirect dependencies too.
dotnet package list --vulnerable --include-transitive
# Older SDK form:
dotnet list package --vulnerable --include-transitive

Listing vulnerabilities does not itself implement your CI failure policy; inspect results or configure NuGet audit severities and warning failures. Review transitive dependencies, package provenance, advisories and upgrade plans, with dated, narrow exceptions. See Data Protection and package-list commands.

#HTTPS, security headers and webhook verification

HTTPS protects transport. HSTS instructs browsers to use HTTPS on subsequent visits under its policy; it neither replaces TLS nor protects the first visit without preload. Behind a proxy, configure trusted forwarded headers before HTTPS redirection. Use CSP source restrictions, frame-ancestors, X-Content-Type-Options: nosniff and an appropriate Referrer-Policy; test rather than blindly copying headers.

A webhook is not trustworthy merely because it says payment succeeded. Verify the signature over raw bytes before parsing, authenticate a timestamp under the provider's protocol to limit replay, then validate order, amount, currency and idempotency.

using System.Security.Cryptography;

// Illustrative provider contract: hex HMAC-SHA256 over the exact raw body.
static bool Verify(byte[] rawBody, string signatureHex, byte[] secret)
{
    if (signatureHex.Length != 64) return false;             // (1)
    byte[] supplied;
    try { supplied = Convert.FromHexString(signatureHex); }
    catch (FormatException) { return false; }
    byte[] expected = HMACSHA256.HashData(secret, rawBody);   // (2)
    return CryptographicOperations.FixedTimeEquals(expected, supplied); // (3)
}

This verifier alone does not prevent replay. Authenticate a timestamp, enforce a time window and persist a unique event ID atomically with the effect or inbox. Compare amount and currency against authoritative order data, and never treat a browser redirect as proof of payment.