Minimal APIs gained popularity right away when they were released in.NET 6 because they made web services speedy and light.  Nevertheless, previous iterations lacked a suitable method for managing routine tasks like as permission, logging, and validation without having to repeat the same code. This is where Endpoint Filters come in; they were first introduced in.NET 7, got better in.NET 8, and are now much better in.NET 9, offering more control over the request pipeline, grouping options, and ease of use.

This article will examine filters in Minimal APIs with.NET 9 and show you how to utilize them efficiently while adhering to current best practices.

What is New in .NET 9 for Filters?
The core API remains the same, but .NET 9 brings several improvements that make filters easier and more powerful to use:

• Better dependency injection (DI) and setup for IEndpointFilterFactory
• Support for filter composition and grouping
• Smarter type inference for inline filters
• More consistent behavior between MapGroup and individual endpoints

If you have used filters in .NET 7 or 8, they’ll still work — but in .NET 9, you’ll enjoy cleaner code, stronger typing, and simpler configuration.

What Are Filters?
Filters let you add custom logic into the request pipeline of a Minimal API endpoint — both before and after the handler runs.
You can think of them as lightweight middleware but applied only to specific endpoints or endpoint groups.

They’re great for handling common tasks like:

• Validation
• Authentication / Authorization
• Logging / Metrics
• Exception Handling
• Response Wrapping
• The source code can be downloaded from GitHub.

The tools that I have used here

1. .NET 9.0
2. Visual Studio 2026 Insider

Defining Filters in .NET 9
You can create filters in two main ways:

• Inline Filters: Write quick, simple logic directly next to the endpoint.
• Reusable Filters: Create separate classes that implement IEndpointFilter for cleaner, reusable code.

Let us look at both.

Inline Filters
The simplest way to add a filter is inline using AddEndpointFilter

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.MapGet("/inlinefilters", (string name) => $"Hello, {name}!")
   .AddEndpointFilter(async (context, next) =>
   {
       Console.WriteLine("Before endpoint logic");

       var result = await next(context);

       Console.WriteLine("After endpoint logic");
       return result;
   });
app.Run();

How It Works

• You receive a context containing arguments, HttpContext, and more.
• You can run code before or after calling next(context).
• You can modify the result or even stop the request early.

Reusable Filters (IEndpointFilter)
When logic needs to be reused or tested, define a class-based filter:
public class LoggingFilter : IEndpointFilter
{
    public async ValueTask<object?> InvokeAsync(
        EndpointFilterInvocationContext context,
        EndpointFilterDelegate next)
    {
        Console.WriteLine($"Incoming: {context.HttpContext.Request.Path}");

        var result = await next(context);

        Console.WriteLine($"Completed: {context.HttpContext.Response.StatusCode}");

        return result;

    }
}

Attach to the endpoint as below:
// Using a reusable filter
app.MapGet("/reusefilter", (string name) => $"Hello, {name}!")
   .AddEndpointFilter<WebApplication1.Filters.LoggingFilter>();

Practical Use Cases
Here are some real-world examples of how filters can be used in .NET 9 projects:

Validation Filter
Perform model validation before hitting your endpoint logic.
public class ValidationFilter<UserDto> : IEndpointFilter
{
    public async ValueTask<object?> InvokeAsync(
        EndpointFilterInvocationContext context,
        EndpointFilterDelegate next)
    {
        var model = context.Arguments.OfType<UserDto>().FirstOrDefault();
        if (model == null)
        {
            return Results.BadRequest("Invalid request payload.");
        }

        // Use reflection to check for UserName, Name, and Age properties
        var type = typeof(UserDto);
        var nameProp = type.GetProperty("Name");
        var ageProp = type.GetProperty("Age");

        var name = nameProp?.GetValue(model) as string;
        var ageValue = ageProp?.GetValue(model);
        int age = 0;
        if (ageValue != null && int.TryParse(ageValue.ToString(), out var parsedAge))
        {
            age = parsedAge;
        }

        if (string.IsNullOrWhiteSpace(name) || age <= 0)
        {
            return Results.BadRequest("Invalid request payload. Name and Age are required and Age must be greater than 0.");
        }

        var validationResults = new List<ValidationResult>();
        bool isValid = Validator.TryValidateObject(
            model, new ValidationContext(model), validationResults, true);

        if (!isValid)
        {
            var errors = validationResults.ToDictionary(
                r => r.MemberNames.FirstOrDefault() ?? "Unknown",
                r => new[] { r.ErrorMessage ?? "Validation error" });

            return Results.ValidationProblem(errors);
        }

        // Await the next delegate in the pipeline
        return await next(context);
    }
}

Attach to endpoint as below
// Using a validation filter
app.MapPost("/validationfilter", (WebApplication1.Models.UserDto user) => Results.Ok($"User {user.Name} of age {user.Age} created."))
   .AddEndpointFilter<ValidationFilter<WebApplication1.Models.UserDto>>();

Authorization Filter
Implement role-based access without repeating logic.
public class RoleFilter : IEndpointFilter
 {
     private readonly string _role;
     public RoleFilter(string role) => _role = role;

     public async ValueTask<object?> InvokeAsync(
         EndpointFilterInvocationContext context,
         EndpointFilterDelegate next)
     {
         var user = context.HttpContext.User;

         if (!user.Identity?.IsAuthenticated ?? false)
             return Results.Unauthorized();

         if (!user.IsInRole(_role))
             return Results.Forbid();

         return await next(context);
     }
 }

Attach to the endpoint:
//using role based filter
app.MapGet("/rolefilter", () => "Welcome, Admin")
   .AddEndpointFilterFactory((factoryContext, next) =>
       (context) =>
       {
           var filter = new RoleFilter("Admin");
           return filter.InvokeAsync(context, next);
       });

Exception Handler Filter
Centralize error handling at the endpoint or group level.
public class ExceptionFilter : IEndpointFilter
{
    public async ValueTask<object?> InvokeAsync(
        EndpointFilterInvocationContext context,
        EndpointFilterDelegate next)
    {
        try
        {
            return await next(context);
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Exception: {ex.Message}");
            return Results.Problem("Something went wrong, please try again.");
        }
    }
}

Apply at a group level in .NET 9:
public class ExceptionFilter : IEndpointFilter
{
    public async ValueTask<object?> InvokeAsync(
        EndpointFilterInvocationContext context,
        EndpointFilterDelegate next)
    {
        try
        {
            return await next(context);
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Exception: {ex.Message}");
            return Results.Problem("Something went wrong, please try again.");
        }
    }
}

Attach to the endpoint:
// Using a global exception handling filter
var api = app.MapGroup("/api")
      .AddEndpointFilter<ExceptionFilter>();

api.MapGet("/exceptionfilter", () => { throw new Exception("Test exception"); });

Conclusion
.NET 9 filters Common activities like validation, logging, and error handling can be easily handled in one location with minimal APIs. They guarantee that shared logic remains constant throughout your application while keeping your endpoint code clear and concise. For greater control, you can apply filters to particular endpoints or groups without introducing the intricacy of global middleware. Filters aid in maintaining readable, well-structured, and reusable code as your application expands. To put it briefly, they're an excellent method for creating dependable, clear, and stable minimal APIs. Happy Coding!

Security is a primary concern in contemporary web applications. JWT (JSON Web Token) authentication is a widely used method for securing REST APIs. Without keeping session data on the server, JWT enables your API to safeguard sensitive endpoints and authenticate users.

1. What is JWT?
JWT (JSON Web Token) is a compact token format that contains user information (claims) and is signed digitally.

Structure: JWT has three parts separated by dots:

• Header
• Payload
• Signature

Example
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMSIsImlhdCI6MTY4MDAwMDAwMCwiZXhwIjoxNjgwMDAzNjAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Purpose: JWT allows stateless authentication where the server does not need to store user sessions.

2. Create a Spring Boot Project
Use Spring Initializr to create a new project.

Add dependencies:

• Spring Web
• Spring Security
• Spring Data JPA (optional, for storing user data)
• jjwt (for JWT token creation)

3. Define User Model and Repository

• Create a User entity representing users in your database.
• Create a UserRepository to handle database operations.

Example
@Entity
public class User {
    @Id @GeneratedValue
    private Long id;
    private String username;
    private String password;
    private String role;
}

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByUsername(String username);
}

4. Configure Spring Security
Create a SecurityConfig class that extends WebSecurityConfigurerAdapter.
Disable the default login form and enable the JWT filter.

Example
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable()
            .authorizeRequests()
            .antMatchers("/auth/**").permitAll()
            .anyRequest().authenticated()
            .and()
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS);

        http.addFilterBefore(jwtFilter(), UsernamePasswordAuthenticationFilter.class);
    }
}

5. Create JWT Utility Class

• Generate and validate JWT tokens.
• Use io.jsonwebtoken (jjwt) library.

Example
@Component
public class JwtUtil {
    private String secret = "mySecretKey";

    public String generateToken(String username) {
        return Jwts.builder()
                   .setSubject(username)
                   .setIssuedAt(new Date())
                   .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 10))
                   .signWith(SignatureAlgorithm.HS256, secret)
                   .compact();
    }

    public String extractUsername(String token) {
        return Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody().getSubject();
    }

    public boolean validateToken(String token, UserDetails userDetails) {
        final String username = extractUsername(token);
        return (username.equals(userDetails.getUsername()) && !isTokenExpired(token));
    }
}

6. Implement Authentication Controller
Create endpoints for login and token generation.

Example
@RestController
@RequestMapping("/auth")
public class AuthController {
    @Autowired private AuthenticationManager authenticationManager;
    @Autowired private JwtUtil jwtUtil;
    @Autowired private UserDetailsService userDetailsService;

    @PostMapping("/login")
    public ResponseEntity<?> login(@RequestBody AuthRequest request) {
        authenticationManager.authenticate(new UsernamePasswordAuthenticationToken(request.getUsername(), request.getPassword()));
        final UserDetails userDetails = userDetailsService.loadUserByUsername(request.getUsername());
        final String token = jwtUtil.generateToken(userDetails.getUsername());
        return ResponseEntity.ok(new AuthResponse(token));
    }
}

AuthRequest and AuthResponse are simple POJOs to carry request and response data.

7. Create JWT Filter
Intercepts incoming requests, extracts the JWT token from headers, and validates it.

Example
@Component
public class JwtFilter extends OncePerRequestFilter {
    @Autowired private JwtUtil jwtUtil;
    @Autowired private UserDetailsService userDetailsService;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
            throws ServletException, IOException {
        final String authHeader = request.getHeader("Authorization");
        String username = null;
        String token = null;

        if (authHeader != null && authHeader.startsWith("Bearer ")) {
            token = authHeader.substring(7);
            username = jwtUtil.extractUsername(token);
        }

        if (username != null && SecurityContextHolder.getContext().getAuthentication() == null) {
            UserDetails userDetails = userDetailsService.loadUserByUsername(username);
            if (jwtUtil.validateToken(token, userDetails)) {
                UsernamePasswordAuthenticationToken authToken = new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities());
                SecurityContextHolder.getContext().setAuthentication(authToken);
            }
        }

        chain.doFilter(request, response);
    }
}

8. Test Your REST API
Start the Spring Boot application.
Use Postman or curl to test:
/auth/login with username/password → get JWT token.

Access protected endpoints with Authorization: Bearer <token> header.

Example curl command
curl -H "Authorization: Bearer <your_token_here>" http://localhost:8080/api/protected

Bash
If everything is correct, the request succeeds; otherwise, it returns 401 Unauthorized.

Summary
You may create safe, stateless REST APIs with Spring Boot's JWT authentication. You may successfully secure your API by following these steps: building a user model, setting up Spring Security, producing JWT tokens, putting filters in place, and testing your endpoints. Because JWT is scalable, safe, and lightweight, it is frequently employed in contemporary online and mobile apps.

Why Use OpenAI with .NET 9?
.NET 9 brings Native AOT, built-in OpenAPI, and minimal APIs that fit AI-first apps perfectly. Combined with OpenAI’s API, you can add:

• Conversational AI (ChatGPT)
• Embeddings for semantic search
• Image generation (DALL·E)
• Structured JSON outputs for agents
• Streaming responses for chatbots

This article shows you how to build production-ready integrations.

Getting Started with OpenAI in .NET 9

1. Install Packages
You can use the official OpenAI .NET SDK or raw HttpClient.
dotnet add package OpenAI

If you prefer HttpClient (no SDK dependency):
dotnet add package Microsoft.Extensions.Http

2. Add API Key to Configuration
appsettings.json:
{
  "OpenAI": {
    "ApiKey": "YOUR_API_KEY_HERE"
  }
}

Or environment variable:
setx OPENAI_API_KEY "sk-xxxx"

3. Register OpenAI Client in Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHttpClient("OpenAI", client =>
{
    client.BaseAddress = new Uri("https://api.openai.com/v1/");
    client.DefaultRequestHeaders.Add("Authorization", $"Bearer {builder.Configuration["OpenAI:ApiKey"]}");
});

var app = builder.Build();

Example 1: ChatGPT in Minimal API
app.MapPost("/chat", async (HttpClientFactory httpFactory, ChatRequest request) =>
{
    var client = httpFactory.CreateClient("OpenAI");

    var payload = new
    {
        model = "gpt-4o-mini",
        messages = new[]
        {
            new { role = "system", content = "You are a helpful assistant." },
            new { role = "user", content = request.Message }
        }
    };

    var response = await client.PostAsJsonAsync("chat/completions", payload);
    var result = await response.Content.ReadFromJsonAsync<ChatResponse>();

    return Results.Ok(result?.Choices.FirstOrDefault()?.Message?.Content);
});

record ChatRequest(string Message);
record ChatResponse(List<Choice> Choices);
record Choice(Message Message);
record Message(string Role, string Content);

Test with:
curl -X POST https://localhost:5001/chat -H "Content-Type: application/json" -d "{ \"message\": \"Tell me about .NET 9\" }"

Example 2: Embeddings for Search
app.MapPost("/embed", async (HttpClientFactory httpFactory, TextRequest req) =>
{
    var client = httpFactory.CreateClient("OpenAI");

    var payload = new
    {
        model = "text-embedding-3-small",
        input = req.Text
    };

    var response = await client.PostAsJsonAsync("embeddings", payload);
    var result = await response.Content.ReadFromJsonAsync<EmbedResponse>();

    return Results.Ok(result?.Data.FirstOrDefault()?.Embedding);
});

record TextRequest(string Text);
record EmbedResponse(List<EmbedData> Data);
record EmbedData(List<float> Embedding);

Use cases: semantic search, clustering, recommendations.

Example 3: Image Generation (DALL·E)
app.MapPost("/image", async (HttpClientFactory httpFactory, TextRequest req) =>
{
    var client = httpFactory.CreateClient("OpenAI");

    var payload = new
    {
        prompt = req.Text,
        model = "gpt-image-1",
        size = "512x512"
    };

    var response = await client.PostAsJsonAsync("images/generations", payload);
    var result = await response.Content.ReadFromJsonAsync<ImageResponse>();

    return Results.Ok(result?.Data.FirstOrDefault()?.Url);
});

record ImageResponse(List<ImageData> Data);
record ImageData(string Url);

Example 4: Streaming Responses (Chatbot UX)
app.MapGet("/stream", async (HttpContext context, HttpClientFactory httpFactory) =>
{
    var client = httpFactory.CreateClient("OpenAI");

    var payload = new
    {
        model = "gpt-4o-mini",
        messages = new[]
        {
            new { role = "user", content = "Explain .NET 9 in 3 bullet points" }
        },
        stream = true
    };

    context.Response.ContentType = "text/event-stream";
    using var req = new HttpRequestMessage(HttpMethod.Post, "chat/completions")
    {
        Content = JsonContent.Create(payload)
    };
    using var resp = await client.SendAsync(req, HttpCompletionOption.ResponseHeadersRead);

    using var reader = new StreamReader(await resp.Content.ReadAsStreamAsync());
    while (!reader.EndOfStream)
    {
        var line = await reader.ReadLineAsync();
        if (!string.IsNullOrWhiteSpace(line) && line.StartsWith("data:"))
        {
            await context.Response.WriteAsync(line + "\n");
            await context.Response.Body.FlushAsync();
        }
    }
});

This enables real-time token streaming for chatbots or IDE assistants.

Best Practices

• Dependency Injection: Use AddHttpClient for resilience & pooling.
• Minimal APIs + Records: Lightweight DTOs = AOT friendly.
• AOT Publishing:
  • dotnet publish -c Release -p:PublishAot=true
• Configuration via Secrets Manager:
  • dotnet user-secrets set "OpenAI:ApiKey" "sk-xxx"
• Use OpenAPI + Swagger in .NET 9 (builder.Services.AddOpenApi()) so your AI endpoints are discoverable by tools and LLMs.

GEO Optimization Notes

• Expose /openapi/v1.json so AI agents and generative engines can discover your endpoints automatically.
• Stream responses (/stream) for agentic AI use cases like copilots.
• Embed structured JSON for predictable responses (use response_format = { "type": "json_object" }).
• Use static SSR in Blazor when combining AI with UI for crawlability.

Summary

With .NET 9 + OpenAI, you can build chatbots, search engines, image generators, and real-time streaming AI apps with minimal code. Key takeaways:

• Built-in HttpClientFactory + DI makes API calls clean.
• Minimal APIs + Records = lightweight, AOT-friendly.
• .NET 9’s OpenAPI support makes your AI endpoints discoverable.
• Streaming and embeddings open the door to real-world agentic apps.

For web applications, Cross-Origin Resource Sharing (CORS) is an essential security component. It specifies how one domain's resources can be accessed by another. Serious security threats, including data theft, unauthorized access to APIs, and potentially account compromise, can arise from improperly setup CORS. This post will go over the recommended practices for securing your applications, typical setup errors, and how to properly set up CORS in ASP.NET Core APIs.

Why CORS Matters?
Modern browsers enforce the Same-Origin Policy, which restricts web pages from making requests to a different domain, protocol, or port. CORS provides a controlled way for servers to relax this restriction and specify which origins are allowed to access resources.

For example

• Allowed: https://example.com can call https://api.example.com.
• Blocked: https://attacker.com cannot call https://api.example.com unless CORS allows it.

When developers configure CORS too loosely (e.g.), attackers may exploit the API from malicious websites.

Common CORS Misconfigurations
Using AllowAnyOrigin() with Authentication
builder.Services.AddCors(options =>
{
    options.AddPolicy("OpenPolicy", policy =>
    {
        policy.AllowAnyOrigin()
              .AllowAnyMethod()
              .AllowAnyHeader();
    });
});

This allows any site to call your API, even if cookies, tokens, or credentials are included.

Risk: Attackers can perform Cross-Site Request Forgery (CSRF) or steal user data.

Allowing Credentials with Wildcards
policy.AllowAnyOrigin()
      .AllowCredentials();

This is invalid in ASP.NET Core, but if forced, it opens a massive security hole. Credentials (cookies, Authorization headers) should only be sent to trusted origins.

Overly Broad Allowed Origins
policy.WithOrigins("https://*.example.com");

Wildcard subdomains may unintentionally allow untrusted or user-controlled domains (e.g., evil.example.com).

Forgetting to Restrict Methods/Headers
policy.WithOrigins("https://trusted.com")
      .AllowAnyHeader()
      .AllowAnyMethod();

Over-permissive headers and methods allow attackers to abuse API endpoints in unexpected ways.

Correctly Configuring CORS in ASP.NET Core
Step 1: Define Trusted Origins
Only allow specific, trusted origins that require access to your API.
builder.Services.AddCors(options =>
{
    options.AddPolicy("SecurePolicy", policy =>
    {
        policy.WithOrigins("https://app.example.com", "https://admin.example.com")
              .WithMethods("GET", "POST")        // Only required methods
              .WithHeaders("Content-Type", "Authorization"); // Only necessary headers
    });
});

Step 2: Apply CORS Policy
Apply globally or per controller.

Global Middleware
var app = builder.Build();

app.UseCors("SecurePolicy");

Per Controller
[EnableCors("SecurePolicy")]
[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    // Endpoints here
}

Step 3: Handle Credentials Carefully
If your API needs cookies or tokens with cross-origin requests:
policy.WithOrigins("https://app.example.com")
      .AllowCredentials()
      .WithHeaders("Content-Type", "Authorization");

Always restrict origins to exact, trusted domains.
Best Practices to Prevent CORS Misconfigurations

• Never use AllowAnyOrigin() in production APIs.
• Avoid wildcards in allowed origins, headers, or methods.
• Restrict credentials: Only allow them for trusted, exact origins.
• Log and monitor preflight requests (OPTIONS) to detect misuse.
• Use environment-based policies (e.g., open CORS in dev, strict in production).

    if (app.Environment.IsDevelopment())
    {
        app.UseCors("DevPolicy"); // More permissive
    }
    else
    {
        app.UseCors("SecurePolicy"); // Strict
    }

    Test your CORS configuration with tools like curl or browser dev tools to confirm restrictions work as intended.

Example: Secure CORS Setup for an API
builder.Services.AddCors(options =>
{
    options.AddPolicy("ApiCorsPolicy", policy =>
    {
        policy.WithOrigins("https://client.example.com")
              .WithMethods("GET", "POST")
              .WithHeaders("Authorization", "Content-Type")
              .AllowCredentials();
    });
});

var app = builder.Build();

app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();

app.UseCors("ApiCorsPolicy");

app.MapControllers();

Conclusion
Although CORS permits valid cross-domain queries, a misconfiguration can leave your ASP.NET Core API vulnerable to serious threats. You can make sure your API is secure and functional by limiting origins, headers, and methods to what is required and staying away from risky patterns like AllowAnyOrigin().

In ASP.NET Core development, configuration plays a very important role. Instead of hardcoding values in code, developers use a configuration system to manage settings like database connections, logging levels, API keys, and environment-specific values. The most commonly used configuration file is appsettings.json, and the main way to read these settings in your application is through IConfiguration. In this article, we will explain in simple terms how to use appsettings.json and IConfiguration with examples. All content is written to be SEO and GEO-friendly, so developers worldwide can easily understand.

What is appsettings.json?
The appsettings.json file is a JSON (JavaScript Object Notation) file used in ASP.NET Core applications to store configuration data. It acts like a central place where you keep application settings that may change depending on the environment.

Key Features

• Human-readable JSON format.
• Hierarchical structure (supports nested sections).
• Supports multiple environment files (e.g., appsettings.Development.json, appsettings.Production.json).
• Automatically loaded by ASP.NET Core at startup.

Example of appsettings.json
{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=mydb;User Id=sa;Password=YourPassword;"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning"
    }
  },
  "AppSettings": {
    "ApplicationName": "My ASP.NET Core App",
    "Version": "1.0"
  }
}

What is IConfiguration?
The IConfiguration interface in ASP.NET Core is used to read values from appsettings.json (and other sources like environment variables, command-line arguments, or secrets). It provides a simple way to access settings by key.

Example of using IConfiguration
public class HomeController : Controller
{
    private readonly IConfiguration _configuration;

    public HomeController(IConfiguration configuration)
    {
        _configuration = configuration;
    }

    public IActionResult Index()
    {
        var appName = _configuration["AppSettings:ApplicationName"];
        var version = _configuration["AppSettings:Version"];
        ViewData["Message"] = $"{appName} - Version {version}";
        return View();
    }
}

Here, we are reading ApplicationName and Version from appsettings.json using IConfiguration.

Using Strongly Typed Classes for Configuration
Instead of accessing settings by string keys, ASP.NET Core allows binding configuration to classes. This makes the code cleaner, type-safe, and easier to maintain.

Example
public class AppSettings
{
    public string ApplicationName { get; set; }
    public string Version { get; set; }
}

In Program.cs:
builder.Services.Configure<AppSettings>(builder.Configuration.GetSection("AppSettings"));

In a Controller or Service:
public class HomeController : Controller
{
    private readonly AppSettings _appSettings;

    public HomeController(IOptions<AppSettings> appSettings)
    {
        _appSettings = appSettings.Value;
    }

    public IActionResult Index()
    {
        return Content($"App Name: {_appSettings.ApplicationName}, Version: {_appSettings.Version}");
    }
}

This approach is recommended for large applications because it makes managing configuration much easier.

Environment-Specific Configurations
ASP.NET Core supports different appsettings.json files for different environments such as Development, Staging, and Production.

    appsettings.Development.json

    appsettings.Staging.json

    appsettings.Production.json

Example of appsettings.Development.json

{
  "AppSettings": {
    "ApplicationName": "My Dev App",
    "Version": "1.0-DEV"
  }
}

When the application runs in Development mode, it will override values from appsettings.json with values from appsettings.Development.json. This makes it easy to have different settings for local testing, staging servers, and live production environments.

Security Best Practices
When using appsettings.json, it is important to handle sensitive information carefully.

• Do not store passwords or API keys directly in appsettings.json for production.
• Use User Secrets in development.
• Use Azure Key Vault, AWS Secrets Manager, or environment variables for production.

Example: Instead of keeping your database password in plain text, store it in an environment variable and let ASP.NET Core automatically load it into IConfiguration.

Summary
appsettings.json is the main file for configuration in ASP.NET Core, and IConfiguration is the service that reads these values. Developers can store important settings like connection strings, API keys, logging levels, and app information in appsettings.json. With the help of IConfiguration and strongly typed classes, these values can be accessed easily inside the application. By using environment-specific files and following security best practices, developers can build applications that are secure, flexible, and ready for global deployment. This approach makes ASP.NET Core applications scalable, maintainable, and cloud-ready.

What is mass assignment/overposting?

• Mass assignment happens when an API blindly binds all incoming JSON fields to your entity model, allowing attackers to set properties they shouldn’t.
• Example
• Suppose your User entity has a IsAdmin flag.

public class User
{
    public int Id { get; set; }
    public string Username { get; set; }
    public string Email { get; set; }
    public bool IsAdmin { get; set; }  //  Should never be set by the client
}

If your Web API controller does this:
[HttpPost]
public async Task<IActionResult> Register(User user)
{
    _context.Users.Add(user);
    await _context.SaveChangesAsync();
    return Ok(user);
}

An attacker can send:
{
  "username": "hacker",
  "email": "[email protected]",
  "isAdmin": true
}

Now the attacker registers themselves as Admin.
This is overposting (exposing unintended properties to clients).

How to Prevent Overposting in ASP.NET Core
1. Use DTOs (Data Transfer Objects)
Never expose your Entity models directly to the API.

Instead, use DTOs that only contain the fields you want the client to update.
public class RegisterDto
{
    [Required, StringLength(50)]
    public string Username { get; set; }

    [Required, EmailAddress]
    public string Email { get; set; }

    [Required, StringLength(100)]
    public string Password { get; set; }
}

Controller
[HttpPost("register")]
public async Task<IActionResult> Register(RegisterDto dto)
{
    var user = new User
    {
        Username = dto.Username,
        Email = dto.Email,
        IsAdmin = false //  Explicitly controlled
    };

    _context.Users.Add(user);
    await _context.SaveChangesAsync();

    return Ok("User registered successfully");
}

Only safe fields are accepted.

Sensitive properties ( IsAdmin ) are not exposed to binding.

2. Use Bind Attribute (MVC only, not Web API best practice)
You can restrict bound properties in MVC controllers with [Bind] .
public IActionResult Create([Bind("Username,Email,Password")] User user)
{ ... }

Not recommended for Web APIs—use DTOs instead.

3. Explicit Model Updates
When updating existing entities, don’t call Update() with the whole model.

Instead, the map only allowed properties.

Vulnerable
[HttpPut("{id}")]
public async Task<IActionResult> Update(int id, User user)
{
    _context.Update(user);  //  Overwrites everything, including IsAdmin
    await _context.SaveChangesAsync();
    return Ok(user);
}

Safe
[HttpPut("{id}")]
public async Task<IActionResult> Update(int id, UpdateUserDto dto)
{
    var user = await _context.Users.FindAsync(id);
    if (user == null) return NotFound();

    // Only update safe fields
    user.Username = dto.Username;
    user.Email = dto.Email;

    await _context.SaveChangesAsync();
    return Ok(user);
}

4. Automapper with Explicit Mapping
If using AutoMapper, configure mappings carefully:
CreateMap<RegisterDto, User>()
.ForMember(dest => dest.IsAdmin, opt => opt.Ignore()); // Prevent assignment

5. Use TryUpdateModelAsync with Property Whitelisting
If you want to bind selectively:
await TryUpdateModelAsync(user, "",
u => u.Username, u => u.Email);

6. Audit Sensitive Fields
Even with DTOs, add server-side checks to ensure properties like IsAdmin , Balance , Role , etc. are only modified by authorized users.

Example
if (dto.Role != null && !User.IsInRole("Admin"))
{
    return Forbid();
}

Best Practices Checklist

• Always use DTOs instead of binding entities directly.
• Whitelist properties explicitly (DTOs, TryUpdateModelAsync , AutoMapper configs).
• Do not expose sensitive properties (e.g., IsAdmin , Balance , CreatedDate ).
• Never call _context.Update(entity) blindly —update only safe fields.
• Audit sensitive updates with role-based authorization.

Conclusion
Mass assignment/overposting is a silent but dangerous vulnerability in ASP.NET Core Web APIs. By using DTOs, explicit property mapping, and whitelisting techniques, you ensure that attackers cannot overwrite sensitive fields.

Always remember:
Bind only what you trust; never trust what you bind.

When you click on a link on a typical website, the browser loads a brand-new page from the server. This could be sluggish and result in a visible lag, which would force a page refresh. Single-Page Applications (SPAs) were developed to increase performance and user experience. They give online apps the same speed and fluidity as mobile apps.

What is a Single-Page Application?
A Single-Page Application (SPA) is a type of web application that loads a single HTML page and dynamically updates the content as the user interacts with it. Instead of reloading the whole page, only the necessary data is fetched and shown.

Key Features

• Loads Once: The main page loads only once, and further content loads dynamically.
• No Full Page Reloads: Content changes without refreshing the entire page.
• Fast Navigation: Feels smooth and similar to using a native mobile app.
• Heavy Use of JavaScript: SPAs rely on JavaScript frameworks and APIs.

How do SPAs Work?

• SPAs work by using JavaScript to handle routing and update the page's content.
• Initial Load: The browser loads one main HTML, CSS, and JavaScript file.
• User Interaction: When the user clicks a button or link, JavaScript intercepts it.
• Data Fetching: The application requests only the necessary data from the server using APIs (such as AJAX or Fetch).
• Dynamic Update: JavaScript updates only part of the page without a full reload.

Example

• If you use Gmail in your browser.
• When you click on an email, only the email content loads while the sidebar and top menu stay the same.
• This is a perfect example of an SPA. (Language: JavaScript with frameworks like React or Angular)

Technologies Used in SPAs
SPAs depend heavily on JavaScript and frontend frameworks.
Common Frameworks and Libraries:

• React.js: Widely used for building SPAs.
• Angular: A complete framework for large SPAs.
• Vue.js: A simple and flexible option for SPAs.
• Svelte: A newer framework for building SPAs efficiently.

Supporting Tools:

• AJAX / Fetch API: To request data without reloading the page.
• REST APIs / GraphQL: To fetch and send data between frontend and backend.

Advantages of SPAs

• Fast Performance: After the first load, navigation is speedy.
• Better User Experience: Smooth transitions without page reloads.
• Reusable Components: Developers can reuse UI components.
• Mobile App Feel: Feels more interactive, like a mobile application.
• Reduced Server Load: Only the required data is requested.

Disadvantages of SPAs

• Initial Load Time: The first page may take longer to load because JavaScript files are heavy.
• SEO Challenges: Search engines may struggle to index SPAs properly.
• Browser Compatibility: Requires JavaScript; may not work well if disabled.
• Security Risks: Exposed APIs can be targeted if not adequately secured.

Real-World Examples of SPAs

• Gmail: Only updates email content without reloading the entire page.
• Google Maps: Loads the map once and dynamically updates locations.
• Facebook: Clicking posts and comments updates the page instantly.
• Twitter: New tweets load dynamically without a full refresh.

Summary
Single-Page Applications (SPAs) are modern web applications that load a single main HTML page and dynamically update its content as users interact. They provide faster navigation, smoother experiences, and a mobile app-like feel. SPAs are built using JavaScript frameworks like React, Angular, and Vue. While they improve performance and user experience, they also face challenges like SEO issues and heavy initial load times. In short, SPAs are a powerful choice for building interactive and modern web applications.

Understanding CommandResponse<T> in C#
When building applications, it’s common to write methods that need to return data along with the status of execution (success or failure). Instead of just returning raw data or a boolean, a better approach is to use a wrapper response object.
What is CommandResponse<T>?

CommandResponse<T> is a generic wrapper class that can hold:

• Data: the actual result of the operation.
• Errors: a list of errors if something went wrong.
• Success: a quick way to check if the operation succeeded.

It can be challenging to manage packages in a.NET solution with numerous projects.  You've probably seen issues like this if you've worked on big apps with dozens or even hundreds of projects.

• Projects utilizing various iterations of the same NuGet package are known as version mismatches.
• Manual labor: Each must be updated. csproj files one after the other.
• Build failures: CI/CD pipelines malfunctioning due to mismatched package versions.

To make this easier, Microsoft introduced Central Package Management (CPM) in .NET, starting with NuGet 6.0 and SDK-style projects.

What is Central Package Management?
Central Package Management lets you keep all NuGet package versions in one central file for your solution. Instead of writing the version number in every project file, you set it once in a file called Directory.Packages.props, and all projects use that version.

This makes upgrades easier, keeps versions consistent, and reduces maintenance work.

How It Works
Create a central file:
At the solution’s root, add a file named Directory.Packages.props.
<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
    <PackageVersion Include="RabbitMQ.Client" Version="7.1.2" />
    <PackageVersion Include="Swashbuckle.AspNetCore" Version="9.0.3" />
  </ItemGroup>
</Project>

Central Package Management
2. Reference packages in projects (without specifying versions):
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
    <PackageReference Include="RabbitMQ.Client" />
  </ItemGroup>

</Project>

Central Package Management
Note: The project file doesn’t include a version number. Instead, the version is defined in Directory.Packages.props.

3. Automatic adoption:
The .NET SDK automatically finds the Directory.Packages.props file in your solution folder and applies it to all projects.

Benefits of Central Package Management

• Consistency – Every project uses the same package version, avoiding conflicts.
• One place to update – Change the version in a single file instead of many.
• Fewer code conflicts – No version mismatches in .csproj files.
• Reliable builds – CI/CD pipelines run more smoothly.
• Simpler project files – .csproj files stay clean and easy to read.

Here’s a simpler example with different packages:
Suppose you have a solution with 15 projects, all using Newtonsoft.Json. Without CPM, updating it means changing 15 .csproj files.

With CPM, you just add this to Directory.Packages.props:
<PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />

Now all projects use the new version automatically.

Conclusion
Central Package Management (CPM) in .NET makes life easier for teams working on solutions with many projects. It keeps package versions consistent, simplifies updates, and saves time. If you haven’t tried it yet, create a Directory.Packages.props file in your solution. You’ll quickly see the advantages. Happy Coding!

When you first encounter the Readonly keyword in C#, it seems straightforward, prevent fields from being reassigned after construction. But once you start applying it to reference types, things get more nuanced. We’ll break down what Readonly really means, especially when dealing with objects, how it behaves differently with value vs. reference types, and what developers should keep in mind to write safer, cleaner code.

What Does Readonly Actually Do?
In C#, the Readonly keyword:

• Can be applied to fields.
• Ensures the field can only be assigned during declaration or inside the constructor of the class/struct.
• Once assigned, the field can’t point to a different object.

public class User
{
    public string Name { get; set; }
}

public class Account
{
    private readonly User _user = new User();
    public void ChangeUser()
    {
        // This is possible
        _user.Name = "New Name";
        // But this will result in compile-time error
        _user = new User();
    }
}

Misunderstanding:
A Readonly field of a reference type doesn’t make the object itself immutable, it only means the reference can’t be reassigned. You can still modify the object’s internal state.
Reference Types vs. Value Types with Readonly

Value Types:
readonly int number = 5;
// Compile-time error
number = 10;

With value types (like int, bool, struct), Readonly means you cannot change the value.
Reference Types:
readonly List<string> items = new List<string>();
// Possible
items.Add("Test");
// Compile-time error
items = new List<string>();

So, the object can still mutate , it’s the reference that’s locked.

Then, How to Make Reference Types Truly Immutable?
To make an object’s state immutable, you must:

• Avoid set accessors in properties.
• Make all fields Readonly.
• Use init accessors for initialization only.
• Don’t expose collection fields directly.

Example
public class User
{
    public string Name { get; init; }
}

Readonly with Properties
While Readonly can be used on fields, it cannot be directly used on properties. But you can mimic the behavior using init accessor:
public string Role { get; init; } = "admin";

These make the property immutable after initialization.