Security

In modern application development, especially with APIs, knowing what’s happening under the hood isn’t just a “nice-to-have,” it’s a necessity. Audit logging provides a detailed record of every significant action, which is invaluable for security, compliance (like GDPR or HIPAA), and debugging complex issues.

While you could add logging calls in every controller action, that approach is repetitive and error-prone. A much cleaner, more powerful solution is to use ASP.NET Core’s middleware. In this post, we’ll build a piece of custom middleware from scratch to create a robust audit logging system for any API.

What is Middleware, Really?

Think of the ASP.NET Core request pipeline as an assembly line. When an HTTP request comes in, it passes through a series of components, or “middleware,” before it reaches your API controller. Each piece of middleware has a chance to inspect the request, modify it, or even short-circuit it. After the controller generates a response, it travels back down the same line.

This structure makes middleware the perfect place for cross-cutting concerns like authentication, caching, exception handling, and, of course, logging.

Designing Our Audit Logging Middleware

Before writing code, let’s define what information we want to capture for each API call. A good audit log should be comprehensive.

Key Data Points to Log:

• Request Info: HTTP Method, Path, Query String, Headers, and the Request Body. …

In the world of web application development, particularly when building secure and robust APIs with ASP.NET Core, the terms authentication and authorization are often used interchangeably. However, they represent two distinct and crucial security concepts. Understanding their differences and how they are implemented within the ASP.NET Core middleware pipeline is fundamental for any developer serious about security.

This article will demystify authentication and authorization, explore their implementation in ASP.NET Core, and highlight where middleware fits into this security puzzle.

Authentication vs. Authorization: A Clear Distinction

At its core, the difference between authentication and authorization is straightforward:

• Authentication is about identity. It’s the process of verifying that a user is who they claim to be. This is typically achieved by validating credentials like a username and password, a biometric scan, or a security token. In essence, authentication answers the question: “Who are you?”

• Authorization is about permissions. Once a user’s identity has been authenticated, authorization determines what actions they are allowed to perform. It’s the process of granting or denying access to specific resources or functionalities. Authorization answers the question: “What are you allowed to do?”

Think of it like attending a conference. When you arrive, you show your ticket and a photo ID to the registration desk. This is …

In modern web development, security isn’t an afterthought; it’s a foundational requirement. One of the most effective and straightforward ways to harden your ASP.NET Core application is by using HTTP security headers. These headers instruct the browser on how to behave, mitigating common attacks like Cross-Site Scripting (XSS), clickjacking, and protocol downgrade attacks.

While you can add these headers in various places, the most robust and maintainable approach is to create a single, centralized middleware. This ensures every response from your application is consistently protected.

In this post, we’ll build a configurable security headers middleware from scratch that manages Content-Security-Policy (CSP), HTTP Strict-Transport-Security (HSTS), and other essential headers.

Why a Centralized Middleware?

You might be tempted to sprinkle Response.Headers.Add(...) in your controllers or use separate app.Use...() calls for each header in Program.cs. However, a centralized approach offers significant advantages:

• Consistency: Every single endpoint gets the same baseline protection without fail. You eliminate the risk of forgetting to secure a new API or page.
• Single Point of Configuration: All your security header policies live in one place. Need to tighten your CSP? You only have one file to edit.
• Maintainability: As security standards evolve, updating your policies is trivial. You don’t have to hunt down configurations scattered across the project. …

In modern web development, Cross-Origin Resource Sharing (CORS) is a fundamental security mechanism. For standard, single-client applications, configuring a CORS policy in ASP.NET Core is straightforward: you define a set of allowed origins in your Program.cs. But what happens when you’re building a multi-tenant application where each tenant needs a different set of allowed origins?

A static, hardcoded list of origins quickly becomes a bottleneck. Adding a new tenant or updating a tenant’s domain would require a code change and a redeployment. This is not scalable or secure. The solution is to create a dynamic, per-tenant CORS policy that resolves the correct origins at runtime.

In this post, we’ll build a custom ASP.NET Core middleware to achieve exactly that. We’ll create a flexible system that looks up a tenant’s specific CORS configuration on the fly for each incoming request.

The Problem with Static CORS in Multi-Tenant Architectures

Let’s quickly review the standard approach. In a typical Program.cs, you might see this:

builder.Services.AddCors(options =>
{
    options.AddDefaultPolicy(policy =>
    {
        policy.WithOrigins("[https://client-app-one.com](https://client-app-one.com)", "[https://client-app-two.com](https://client-app-two.com)")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

// ... in the pipeline configuration
app.UseCors();

This works perfectly for a predictable …