Filters in ASP.NET Core .NET 10 - The Complete Guide

I once had a validation action filter that silently swallowed ModelState errors in production. Everything looked correct - the filter checked ModelState.IsValid, returned BadRequest when invalid. Clean code, proper tests. But users were submitting invalid data and getting 200 OK responses. After hours of debugging, I discovered another action filter registered globally was short-circuiting the pipeline before my validation filter ever ran. The request never reached my filter. That experience taught me something critical: understanding filters is not just about knowing how to write one - it is about understanding the entire filter pipeline, execution order, and how filters interact with each other.

In this guide, I will walk you through all 6 filter types in ASP.NET Core .NET 10 - authorization, resource, action, exception, result, and endpoint filters. You will get a decision matrix for choosing the right filter type, practical code samples, and clear guidance on when to use filters vs middleware. Let’s get into it.

What Are Filters in ASP.NET Core?

Filters in ASP.NET Core are components that execute custom logic at specific stages of the HTTP request pipeline, specifically within the MVC and Minimal API frameworks. They allow you to handle cross-cutting concerns - logging, validation, authorization, exception handling, response shaping - without cluttering your controller actions or endpoint handlers.

According to Microsoft’s official documentation, filters run within the ASP.NET Core action invocation pipeline, sometimes referred to as the filter pipeline. The filter pipeline runs after ASP.NET Core selects the action to execute.

In .NET 10, ASP.NET Core supports 6 filter types:

1. Authorization Filters - run first, before everything else
2. Resource Filters - run before model binding, can short-circuit the entire pipeline
3. Action Filters - run immediately before and after an action method executes
4. Exception Filters - catch unhandled exceptions thrown during action execution
5. Result Filters - run before and after the action result is executed
6. Endpoint Filters - the lightweight alternative for Minimal APIs, introduced in .NET 7

Each filter type runs at a specific stage of the pipeline and serves a distinct purpose. The key insight is that filters give you action-level precision - unlike middleware, which operates on the entire HTTP pipeline without knowledge of controllers, actions, or model binding.

Why and When to Use Filters

Filters solve a specific problem: you need logic that runs around your action methods, with access to MVC-specific context like ModelState, action arguments, and action results. Middleware cannot give you that level of precision.

My take: if your logic needs to know what action is being called and what data was bound to its parameters, you need a filter. If your logic just needs the raw HttpContext, middleware is the right tool.

Here is when each approach makes sense:

• Use filters when you need access to action arguments, model state, or action results
• Use filters when the logic applies to specific controllers or actions, not every HTTP request
• Use filters when you want to short-circuit based on action-level context (like validation failures)
• Use middleware when the logic must run for all requests regardless of routing (logging, CORS, compression)
• Use middleware when you need to intercept requests before routing even happens

Authorization Filters

Authorization filters are the first filters to execute in the ASP.NET Core pipeline. They run before model binding, before action filters, and before everything else. Their job is to determine whether the current user is authorized to access the requested endpoint.

In most applications, you will not need a custom authorization filter. The built-in [Authorize], [AllowAnonymous], and policy-based authorization attributes handle the majority of scenarios. According to Microsoft’s authorization filter documentation, custom authorization filters require writing a custom authorization policy in most cases. But when you have a truly custom authorization system - API key validation, multi-tenant access checks, or custom claim requirements - implementing IAuthorizationFilter gives you full control.

Custom Authorization Filter Example

public class ApiKeyAuthorizationFilter(IConfiguration configuration) : IAuthorizationFilter
{
    public void OnAuthorization(AuthorizationFilterContext context)
    {
        var apiKey = context.HttpContext.Request.Headers["X-Api-Key"].FirstOrDefault();
        var expectedKey = configuration["ApiSettings:ApiKey"];

        if (string.IsNullOrEmpty(apiKey) || apiKey != expectedKey)
        {
            context.Result = new UnauthorizedObjectResult(new ProblemDetails
            {
                Status = StatusCodes.Status401Unauthorized,
                Title = "Invalid API Key",
                Detail = "Provide a valid API key in the X-Api-Key header."
            });
        }
    }
}

Notice the primary constructor syntax - this is modern C# in .NET 10. The filter takes IConfiguration as a dependency, which gets resolved through DI when you use ServiceFilter or register the filter globally.

Applying Authorization Filters

Register globally to protect every endpoint:

builder.Services.AddControllers(options =>
{
    options.Filters.Add<ApiKeyAuthorizationFilter>();
});

Or apply to a specific controller:

[ServiceFilter(typeof(ApiKeyAuthorizationFilter))]
[ApiController]
[Route("api/[controller]")]
public class SecureController : ControllerBase
{
    [HttpGet]
    public IActionResult GetSecureData() => Ok("Authorized access granted.");
}

My take: for most projects, stick with the built-in [Authorize] attribute and policy-based authorization. Only reach for IAuthorizationFilter when you have truly custom authorization logic that the policy system cannot handle.

Resource Filters

Resource filters run before model binding and wrap the entire action execution pipeline. They execute their “before” logic before model binding happens, and their “after” logic after everything else (action, exception, and result filters) completes. This makes them ideal for short-circuiting expensive operations early.

The most common use case I have seen in production is response caching - checking if a cached response exists before the pipeline does any work, and caching the response after the pipeline completes.

Async Resource Filter Example

public class TimingResourceFilter(ILogger<TimingResourceFilter> logger) : IAsyncResourceFilter
{
    public async Task OnResourceExecutionAsync(ResourceExecutingContext context, ResourceExecutionDelegate next)
    {
        var stopwatch = Stopwatch.StartNew();
        var actionName = context.ActionDescriptor.DisplayName;

        logger.LogInformation("Starting request pipeline for {ActionName}", actionName);

        var executedContext = await next();

        stopwatch.Stop();
        logger.LogInformation("Completed {ActionName} in {ElapsedMs}ms",
            actionName, stopwatch.ElapsedMilliseconds);
    }
}

The async version with IAsyncResourceFilter is what I recommend for most scenarios. It gives you a clean before/after pattern with a single method - call await next() to execute the rest of the pipeline, and anything after that line runs on the response path.

Short-Circuiting with Resource Filters

You can skip the entire pipeline by setting context.Result without calling next():

public class CacheResourceFilter(IMemoryCache cache) : IAsyncResourceFilter
{
    public async Task OnResourceExecutionAsync(ResourceExecutingContext context, ResourceExecutionDelegate next)
    {
        var cacheKey = context.HttpContext.Request.Path.ToString();

        if (cache.TryGetValue(cacheKey, out var cachedResult))
        {
            context.Result = new OkObjectResult(cachedResult);
            return; // Short-circuit - skip the entire pipeline
        }

        var executedContext = await next();

        if (executedContext.Result is ObjectResult { Value: not null } objectResult)
        {
            cache.Set(cacheKey, objectResult.Value, TimeSpan.FromMinutes(5));
        }
    }
}

This is powerful because model binding, action execution, and everything else gets skipped when the cache hits. Trust me, for high-traffic endpoints, this pattern saves significant server resources.

Action Filters

Action filters are the workhorses of the filter pipeline. They run immediately before and after the action method executes - after model binding is complete, so you have full access to the bound action arguments.

This is where I put validation logic, request/response logging, and audit trails. The filter sees exactly what data will hit the action method and what result the action produces.

Action Filter with ILogger

public class LoggingActionFilter(ILogger<LoggingActionFilter> logger) : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
    {
        logger.LogInformation("Executing action {ActionName} with arguments {@Arguments}",
            context.ActionDescriptor.DisplayName,
            context.ActionArguments);
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        logger.LogInformation("Executed action {ActionName} - Status code: {StatusCode}",
            context.ActionDescriptor.DisplayName,
            context.HttpContext.Response.StatusCode);
    }
}

Notice: no Console.WriteLine. In production, always use ILogger with structured logging. The primary constructor pattern keeps the code clean and eliminates boilerplate field assignments.

Async Action Filter

For scenarios where you need async operations (database calls, external API checks), use IAsyncActionFilter:

public class AuditActionFilter(ILogger<AuditActionFilter> logger) : IAsyncActionFilter
{
    public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        var user = context.HttpContext.User.Identity?.Name ?? "Anonymous";
        var action = context.ActionDescriptor.DisplayName;

        logger.LogInformation("User {User} invoking {Action}", user, action);

        var executedContext = await next();

        if (executedContext.Exception is null)
        {
            logger.LogInformation("User {User} completed {Action} successfully", user, action);
        }
    }
}

Validation Action Filter

This is the filter I use in every project - a global ModelState validation filter that eliminates repetitive if (!ModelState.IsValid) checks from every action:

public class ValidationActionFilter : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
    {
        if (!context.ModelState.IsValid)
        {
            context.Result = new BadRequestObjectResult(context.ModelState);
        }
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        // No post-processing needed
    }
}

Register it globally and you never write ModelState.IsValid in a controller again:

builder.Services.AddControllers(options =>
{
    options.Filters.Add<ValidationActionFilter>();
});

Quite handy, yeah? This one filter has saved me hundreds of lines of repetitive validation code across 5+ projects.

Exception Filters

Exception filters catch unhandled exceptions thrown during action execution, action filter execution, or result filter execution. They give you a centralized place to log exceptions and return consistent error responses within the MVC pipeline.

Important .NET 10 note: While exception filters still work, the recommended approach for global exception handling in .NET 8+ is IExceptionHandler. Exception filters only catch exceptions within the MVC pipeline - they will not catch exceptions from middleware, routing, or model binding. IExceptionHandler catches everything.

My take: use IExceptionHandler for your global exception handling strategy, and reserve exception filters for controller-specific error handling where you need access to the action context.

Custom Exception Filter

public class GlobalExceptionFilter(ILogger<GlobalExceptionFilter> logger) : IExceptionFilter
{
    public void OnException(ExceptionContext context)
    {
        logger.LogError(context.Exception, "Unhandled exception in {ActionName}",
            context.ActionDescriptor.DisplayName);

        var problemDetails = new ProblemDetails
        {
            Status = StatusCodes.Status500InternalServerError,
            Title = "An unexpected error occurred",
            Detail = context.Exception.Message,
            Instance = context.HttpContext.Request.Path
        };

        context.Result = new ObjectResult(problemDetails)
        {
            StatusCode = StatusCodes.Status500InternalServerError
        };

        context.ExceptionHandled = true;
    }
}

Setting context.ExceptionHandled = true prevents the exception from propagating further. If you do not set this, the exception will continue up to middleware-level exception handlers.

Result Filters

Result filters run after the action method executes but before the action result is sent to the client. They are useful for modifying or wrapping the response without touching the controller logic.

The most practical use case is response wrapping - ensuring every successful response follows a standard envelope format with success, data, and timestamp properties.

Response Wrapping Result Filter

public class ResponseWrappingResultFilter(ILogger<ResponseWrappingResultFilter> logger) : IResultFilter
{
    public void OnResultExecuting(ResultExecutingContext context)
    {
        if (context.Result is ObjectResult objectResult
            && objectResult.StatusCode is null or (>= 200 and < 300))
        {
            objectResult.Value = new
            {
                success = true,
                data = objectResult.Value,
                timestamp = DateTime.UtcNow
            };
        }
    }

    public void OnResultExecuted(ResultExecutedContext context)
    {
        logger.LogDebug("Result executed for {ActionName}",
            context.ActionDescriptor.DisplayName);
    }
}

This filter wraps all 2xx responses in a standard format. Register it globally and every controller gets consistent response shaping without any extra code.

Endpoint Filters (for Minimal APIs)

Endpoint filters were introduced in .NET 7 and are the filter system for Minimal APIs. According to Microsoft’s endpoint filter documentation, endpoint filters allow you to run code before and after the endpoint handler runs. Unlike MVC filters that only work with controllers, endpoint filters intercept Minimal API route handlers - giving you before/after processing with full access to the endpoint arguments and result.

If you are building Minimal APIs (which I recommend for most new projects in .NET 10), endpoint filters are your primary tool for cross-cutting concerns at the route level.

Basic Endpoint Filter

public class LoggingEndpointFilter(ILogger<LoggingEndpointFilter> logger) : IEndpointFilter
{
    public async ValueTask<object?> InvokeAsync(
        EndpointFilterInvocationContext context,
        EndpointFilterDelegate next)
    {
        var endpoint = context.HttpContext.GetEndpoint()?.DisplayName;
        logger.LogInformation("[Before] Executing endpoint: {Endpoint}", endpoint);

        var result = await next(context);

        logger.LogInformation("[After] Executed endpoint: {Endpoint}", endpoint);
        return result;
    }
}

Applying Endpoint Filters

app.MapGet("/products", () => Results.Ok(products))
   .AddEndpointFilter<LoggingEndpointFilter>();

Typed Validation Endpoint Filter

This is where endpoint filters really shine - typed validation per route:

public class ValidationEndpointFilter<T>(
    ILogger<ValidationEndpointFilter<T>> logger) : IEndpointFilter where T : class
{
    public async ValueTask<object?> InvokeAsync(
        EndpointFilterInvocationContext context,
        EndpointFilterDelegate next)
    {
        var argument = context.Arguments.OfType<T>().FirstOrDefault();

        if (argument is null)
        {
            logger.LogWarning("Request body of type {Type} is null", typeof(T).Name);
            return Results.BadRequest($"Request body of type {typeof(T).Name} is required.");
        }

        logger.LogInformation("Validated endpoint argument of type {Type}", typeof(T).Name);
        return await next(context);
    }
}

Apply it to specific routes:

app.MapPost("/products", (CreateProductRequest request) =>
    Results.Created($"/products/1", new Product(1, request.Name, request.Price)))
    .AddEndpointFilter<ValidationEndpointFilter<CreateProductRequest>>();

Inline Filters

For simple, one-off logic, you can write filters inline without a separate class:

app.MapPost("/orders", (Order order) => Results.Ok(order))
   .AddEndpointFilter(async (context, next) =>
   {
       var order = context.GetArgument<Order>(0);

       if (order.Total <= 0)
           return Results.BadRequest("Order total must be greater than zero.");

       return await next(context);
   });

Endpoint filters support chaining - you can add multiple filters to a single endpoint, and they execute in the order they are added. Each filter can short-circuit by returning a result without calling next().

Filter Execution Order

Understanding execution order is critical. I have seen developers waste hours debugging issues that were simply caused by filters running in the wrong order. Here is the exact sequence for the MVC filter pipeline:

Request Path (Incoming)

--> Authorization Filters
    --> Resource Filters (OnResourceExecuting)
        --> Model Binding
            --> Action Filters (OnActionExecuting)
                --> Action Method
            <-- Action Filters (OnActionExecuted)
        --> Result Filters (OnResultExecuting)
            --> Result Execution
        <-- Result Filters (OnResultExecuted)
    <-- Resource Filters (OnResourceExecuted)

If an exception is thrown during action or result execution, exception filters run instead of the normal result path.

Order Within the Same Filter Type

When multiple filters of the same type are registered, they follow this priority:

1. Global filters run first (registered in AddControllers options)
2. Controller-level filters run second (applied via attributes on the controller)
3. Action-level filters run last (applied via attributes on the action method)

The “after” methods (OnActionExecuted, OnResultExecuted) run in reverse order - the last filter to execute its “before” logic is the first to execute its “after” logic. Think of it as nesting: global wraps controller, which wraps action.

Controlling Filter Order

You can explicitly control order using the Order property on IOrderedFilter:

[ServiceFilter(typeof(LoggingActionFilter), Order = 1)]
[ServiceFilter(typeof(ValidationActionFilter), Order = 2)]
public IActionResult Create([FromBody] Product product) => Ok(product);

Lower Order values execute first. Filters with the same Order value follow the default scope-based ordering (global, then controller, then action).

TypeFilter vs ServiceFilter

Both TypeFilter and ServiceFilter let you apply filters with dependency injection, but they work differently under the hood.

ServiceFilter

• Resolves the filter instance from the DI container
• You must register the filter as a service: services.AddScoped<YourFilter>()
• Throws at runtime if the filter is not registered
• Respects the lifetime you configure (transient, scoped, singleton)

// Registration
builder.Services.AddScoped<LoggingActionFilter>();

// Usage
[ServiceFilter(typeof(LoggingActionFilter))]
public IActionResult Get() => Ok();

TypeFilter

• Creates the filter instance at runtime using ActivatorUtilities
• Does not require DI registration of the filter itself
• Dependencies are still resolved from DI via constructor injection
• Supports passing constructor arguments via the Arguments property

// No registration needed
[TypeFilter(typeof(LoggingActionFilter))]
public IActionResult Get() => Ok();

// With extra constructor arguments
[TypeFilter(typeof(RoleFilter), Arguments = new object[] { "Admin" })]
public IActionResult AdminOnly() => Ok();

My take: use ServiceFilter for most cases. It is explicit about DI registration, gives you control over lifetime, and makes it clear that the filter is a managed dependency. Only reach for TypeFilter when you need to pass constructor arguments or when you have a filter that should not be registered in the DI container.

Global Filters vs Filter Attributes

The decision between global registration and per-action attributes comes down to scope:

Use global filters when:

• The logic must run for every controller action (logging, exception handling, response wrapping)
• You want consistent behavior across the entire API
• The filter has no action-specific configuration

builder.Services.AddControllers(options =>
{
    options.Filters.Add<TimingResourceFilter>();
    options.Filters.Add<GlobalExceptionFilter>();
    options.Filters.Add<ResponseWrappingResultFilter>();
});

Use filter attributes when:

• The logic applies only to specific controllers or actions
• You need different configuration per endpoint
• You want the filter’s presence to be explicitly visible in the controller code

[ServiceFilter(typeof(ValidationActionFilter))]
[HttpPost]
public IActionResult Create([FromBody] CreateProductRequest request) => Ok(request);

You can mix both approaches. Global filters provide the baseline, and attribute filters add endpoint-specific behavior on top.

When to Use Each Filter Type - Decision Matrix

This is the table I reference when deciding which filter type to use for a given concern. I have refined this across dozens of production APIs:

Get the point? Each filter type exists for a specific reason. When you pick the right one, your code stays clean. When you pick the wrong one, you fight the framework.

Filters vs Middleware vs Endpoint Filters

This is the comparison that matters most. I get this question constantly, and the answer depends on what you need access to.

My take: for new .NET 10 projects using Minimal APIs, use endpoint filters for route-specific logic and middleware for pipeline-wide concerns. For controller-based APIs, MVC filters give you the richest context. Do not mix MVC filters with Minimal API endpoints - they do not apply.

The Filter I Use in Every Project

Over 5+ production APIs, I have settled on a standard filter setup that I register globally in every project. Here is my baseline:

builder.Services.AddControllers(options =>
{
    options.Filters.Add<TimingResourceFilter>();       // Performance tracking
    options.Filters.Add<ValidationActionFilter>();     // Global ModelState validation
    options.Filters.Add<GlobalExceptionFilter>();      // Consistent error responses
    options.Filters.Add<ResponseWrappingResultFilter>(); // Standard response envelope
});

// Register filters for ServiceFilter usage
builder.Services.AddScoped<TimingResourceFilter>();
builder.Services.AddScoped<ValidationActionFilter>();
builder.Services.AddScoped<GlobalExceptionFilter>();
builder.Services.AddScoped<ResponseWrappingResultFilter>();
builder.Services.AddScoped<LoggingActionFilter>();

The LoggingActionFilter is not registered globally - I apply it via [ServiceFilter(typeof(LoggingActionFilter))] only on controllers where I need detailed request/response logging. Global logging would be too noisy for most APIs.

This setup gives me:

• Performance visibility - TimingResourceFilter tracks every request duration
• Zero validation boilerplate - ValidationActionFilter handles all ModelState checks
• Consistent error format - GlobalExceptionFilter returns ProblemDetails for every unhandled exception
• Standard response shape - ResponseWrappingResultFilter wraps all 2xx responses

I have evolved this setup over time. Early on, I used to register LoggingActionFilter globally, but that generated so much log noise that it became counterproductive. Scoped logging on sensitive endpoints is the sweet spot.

Troubleshooting Filter Issues

Here are the 6 most common filter issues I have encountered and how to fix them:

Filter is not firing at all? Check if the filter is actually registered. For ServiceFilter, the filter type must be registered in the DI container (services.AddScoped<YourFilter>()). A missing registration throws a runtime exception, but if you catch exceptions globally, you might miss it. Also verify the filter attribute is on the correct controller or action - not a base class method that is overridden.

Filters executing in the wrong order? Remember the default order: global, then controller, then action. If you need a specific sequence, implement IOrderedFilter and set the Order property. Lower values run first. Also check if you have both sync and async versions of the same filter interface - implementing both causes unpredictable behavior. Pick one.

DI dependencies not resolving in filters? If you are using [TypeFilter], the filter itself does not need DI registration, but its constructor dependencies must be registered. If using [ServiceFilter], the filter and its dependencies must be registered. Also verify the service lifetimes - a singleton filter cannot depend on a scoped service.

Short-circuit is not working? Setting context.Result only short-circuits if you do it in the correct method. In OnActionExecuting, setting context.Result prevents the action from running. In OnActionExecuted, the action has already run - setting context.Result only replaces the response. For resource filters, set context.Result in OnResourceExecuting and return without calling next().

Async filter pitfalls? Do not implement both IActionFilter and IAsyncActionFilter on the same class. ASP.NET Core only calls the async version if both are present, and the sync methods are silently ignored. Pick one interface per filter. If you need async operations, always use the async variant.

Endpoint filter not running on a Minimal API route? Endpoint filters only work on routes defined with MapGet, MapPost, etc. They do not apply to controller-based endpoints. Also check the filter registration order - AddEndpointFilter<T>() must be chained on the specific route builder, not on the WebApplication instance.

Key Takeaways

1. ASP.NET Core .NET 10 has 6 filter types - authorization, resource, action, exception, result, and endpoint filters - each designed for a specific stage of the request pipeline.
2. Use the decision matrix to pick the right filter type. Authorization for early rejection, resource for caching, action for logging/validation, exception for error handling, result for response wrapping, endpoint for Minimal APIs.
3. Prefer ServiceFilter over TypeFilter for most scenarios - it gives you explicit DI registration and lifetime control.
4. Filters are not middleware. Filters operate inside the MVC/Minimal API pipeline with access to action context. Middleware operates on the raw HTTP pipeline. Pick the right tool for the job.
5. Start with a standard filter baseline (validation, exception handling, response wrapping) and add endpoint-specific filters only where needed.

Happy Coding :)