dotnet list package --vulnerable --include-transitive

<!-- BEFORE — vulnerable package -->
<PackageReference Include="System.Text.Json" Version="8.0.0" />

<!-- AFTER — patched version -->
<PackageReference Include="System.Text.Json" Version="10.0.0" />

HIGH-CONFIDENCE PATTERNS (almost always a real secret):
- "Password=" or "Pwd=" in connection strings outside appsettings.Development.json
- "Bearer " followed by a base64 token in source code
- "-----BEGIN PRIVATE KEY-----" or "-----BEGIN RSA PRIVATE KEY-----"
- AWS: "AKIA" followed by 16 alphanumeric characters
- Azure: strings matching Azure Storage/Service Bus key patterns

MEDIUM-CONFIDENCE PATTERNS (need context to determine):
- "ApiKey", "Secret", "Token" as variable names with string literal assignments
- Base64-encoded strings longer than 40 characters in source code
- Connection strings with server addresses in non-Development config files

FALSE-POSITIVE INDICATORS (skip these):
- Values in appsettings.Development.json (development-only)
- Placeholder values: "your-key-here", "changeme", "TODO", empty strings
- Test fixtures with obviously fake values
- User secrets references: "UserSecretsId" in .csproj

// BAD — hardcoded connection string
var connectionString = "Server=prod-db;Database=Orders;User=admin;Password=S3cret!";

// GOOD — configuration with user secrets / environment variables
var connectionString = builder.Configuration.GetConnectionString("OrdersDb");
// Store actual values in:
// - Development: dotnet user-secrets set "ConnectionStrings:OrdersDb" "..."
// - Production: Environment variable or Azure Key Vault

A03:2021 — Injection
  Detect: String concatenation in SQL queries, raw SQL with user input
  Pattern: FromSqlRaw($"SELECT * FROM Orders WHERE Id = '{userInput}'")
  Fix: FromSqlInterpolated($"SELECT * FROM Orders WHERE Id = {userInput}")
       or use parameterized queries / LINQ

A07:2021 — Cross-Site Scripting (XSS)
  Detect: Raw HTML output without encoding in Razor/Blazor
  Pattern: @Html.Raw(userInput)
  Fix: Use Razor's default encoding (@userInput) or sanitize explicitly

A08:2021 — Insecure Deserialization
  Detect: BinaryFormatter, JsonConvert with TypeNameHandling.All
  Pattern: JsonConvert.DeserializeObject<T>(json, new JsonSerializerSettings
           { TypeNameHandling = TypeNameHandling.All })
  Fix: Use System.Text.Json (no type name handling by default)
       If Newtonsoft is required: TypeNameHandling.None + explicit type converters

A02:2021 — Cryptographic Failures
  Detect: MD5, SHA1 for security purposes, ECB mode, hardcoded encryption keys
  Pattern: MD5.Create().ComputeHash(...)
  Fix: Use SHA256 minimum, prefer HMACSHA256 for authentication
       Use AES-GCM for encryption, derive keys from passwords using Rfc2898DeriveBytes

A04:2021 — Insecure Direct Object References
  Detect: Endpoints that use user-supplied IDs without ownership verification
  Pattern: GET /orders/{id} — returns any order regardless of who owns it
  Fix: Add ownership check: where o.Id == id && o.CustomerId == currentUser.Id

CHECKLIST:
1. All endpoints have explicit auth attributes
   - MCP: find_references(symbolName: "AllowAnonymous") — list deliberately public endpoints
   - MCP: find_references(symbolName: "Authorize") — list protected endpoints
   - Gap: endpoints with neither attribute (implicit policy depends on global config)

2. JWT validation settings are secure
   - ValidateIssuer: true (prevents token from wrong issuer)
   - ValidateAudience: true (prevents token meant for another app)
   - ValidateLifetime: true (prevents expired tokens)
   - ValidateIssuerSigningKey: true (prevents tampered tokens)
   - ClockSkew: TimeSpan.FromMinutes(1) max (default 5 min is too generous)

3. Authorization policies are specific
   - BAD: [Authorize] with no policy — just checks "is authenticated"
   - GOOD: [Authorize(Policy = "OrderAdmin")] — role/claim-based authorization

4. No auth bypass patterns
   - Middleware ordering: UseAuthentication() before UseAuthorization()
   - No global AllowAnonymous that accidentally opens everything
   - API key validation in middleware, not in each controller

// BAD — JWT configuration with weak validation
builder.Services.AddAuthentication().AddJwtBearer(options =>
{
    options.TokenValidationParameters = new()
    {
        ValidateIssuer = false,          // Anyone can issue tokens
        ValidateAudience = false,        // Token works for any app
        ValidateLifetime = false,        // Expired tokens accepted
        IssuerSigningKey = new SymmetricSecurityKey(
            "short-key"u8.ToArray())     // Key too short (< 256 bits)
    };
});

// GOOD — secure JWT configuration
builder.Services.AddAuthentication().AddJwtBearer(options =>
{
    options.TokenValidationParameters = new()
    {
        ValidateIssuer = true,
        ValidIssuer = builder.Configuration["Jwt:Issuer"],
        ValidateAudience = true,
        ValidAudience = builder.Configuration["Jwt:Audience"],
        ValidateLifetime = true,
        ClockSkew = TimeSpan.FromMinutes(1),
        ValidateIssuerSigningKey = true,
        IssuerSigningKey = new SymmetricSecurityKey(
            Convert.FromBase64String(builder.Configuration["Jwt:Key"]!))
    };
});

// CRITICAL — wildcard origin with credentials
builder.Services.AddCors(options =>
{
    options.AddDefaultPolicy(policy =>
    {
        policy.AllowAnyOrigin()      // Any website can call this API
              .AllowCredentials();    // ...and send cookies/auth headers
        // This is a security vulnerability — browsers block this combo,
        // but it signals a misunderstanding of CORS
    });
});

// HIGH — wildcard origin without credentials
policy.AllowAnyOrigin()             // Any website can read API responses
      .AllowAnyHeader()
      .AllowAnyMethod();
// Acceptable ONLY for truly public APIs (e.g., public data feeds)

// GOOD — explicit origins
builder.Services.AddCors(options =>
{
    options.AddDefaultPolicy(policy =>
    {
        policy.WithOrigins(
                builder.Configuration.GetSection("Cors:AllowedOrigins").Get<string[]>()!)
              .AllowCredentials()
              .WithMethods("GET", "POST", "PUT", "DELETE")
              .WithHeaders("Content-Type", "Authorization");
    });
});

CHECKS:
1. PII in logs — email, phone, SSN, credit card in logging statements
   Pattern: logger.LogInformation("User {Email} placed order", user.Email)
   Fix: logger.LogInformation("User {UserId} placed order", user.Id)
   Rule: Log identifiers (IDs), not identity data (email, name, phone)

2. Sensitive data in responses — returning more data than needed
   Pattern: Returning full User entity (with password hash) from an endpoint
   Fix: Use a response DTO that excludes sensitive fields

3. Missing Data Protection API — storing sensitive data without encryption
   Pattern: Storing API keys as plain text in the database
   Fix: Use IDataProtector to encrypt before storage

4. Unencrypted sensitive configuration — secrets in appsettings.json
   Pattern: "SmtpPassword": "actualpassword" in appsettings.json
   Fix: Use user secrets (dev), Key Vault (prod), or environment variables

// BAD — PII in logs
logger.LogInformation("Order placed by {Email} for {CreditCard}",
    order.CustomerEmail, order.PaymentCard);

// GOOD — identifiers only
logger.LogInformation("Order {OrderId} placed by customer {CustomerId}",
    order.Id, order.CustomerId);

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined