The .NET API Security Checklist We Follow on Every Project

Every API we build goes through a security review before deployment. Over time, we've formalized this into a checklist that covers the most critical areas.

Authentication and Authorization

• JWT validation: Always validate issuer, audience, and expiration. Never trust tokens without verification.
• Role-based and policy-based authorization: Use ASP.NET Core's authorization policies for granular access control.
• API key rotation: Support multiple active keys to enable zero-downtime rotation.

Input Validation

• Model validation: Use DataAnnotations and FluentValidation for all request models.
• Parameterized queries: Never concatenate user input into SQL strings. EF Core handles this, but raw SQL needs explicit parameterization.
• File upload restrictions: Validate file type, size, and content. Never trust the Content-Type header alone.

Rate Limiting and Throttling

ASP.NET Core's built-in rate limiting middleware handles most scenarios. We configure:

• Per-endpoint rate limits based on expected usage
• Sliding window algorithms for API consumers
• Differentiated limits for authenticated vs. anonymous users

CORS Configuration

Never use a wildcard CORS policy in production. We explicitly list allowed origins and review them during each deployment.

Logging and Monitoring

• Structured logging: We use Serilog with structured properties for every request.
• Sensitive data filtering: Request/response logging must exclude passwords, tokens, and PII.
• Alert thresholds: Set up alerts for unusual error rates, response times, and authentication failures.

Dependency Security

• Regular NuGet audit: Run dotnet list package --vulnerable as part of CI.
• Lock files: Use packages.lock.json to prevent supply chain attacks.

HTTPS and Transport Security

• HSTS headers: Enforce HTTPS with Strict-Transport-Security.
• Certificate pinning: For service-to-service communication in sensitive environments.

Conclusion

Security is iterative. This checklist is our baseline — each project adds domain-specific security requirements on top. The important thing is having a systematic approach rather than relying on memory.