What are filters in ASP.NET Core?

Updated Apr 28, 2026

Short answer

Filters in ASP.NET Core are components that allow developers to run code before or after specific stages of request processing, especially around controller actions and Razor Pages handlers. They are commonly used for cross-cutting concerns such as authorization, validation, logging, exception handling, and modifying action results. Unlike middleware, filters operate closer to the MVC/action execution level and have access to action-specific context.

Deep explanation

Filters are part of the ASP.NET Core MVC pipeline and provide a way to execute reusable logic around controller actions, Razor Pages handlers, or endpoint execution.

They are useful when the logic is related to MVC behavior rather than the entire HTTP request pipeline.

Examples of cross-cutting concerns handled by filters:

Authorization checks.
Request validation.
Logging action execution.
Exception handling.
Modifying responses.
Measuring action performance.
Adding common headers.

The general flow is:

TEXT

1HTTP Request
2      |
3      v
4Middleware Pipeline
5      |
6      v
7Routing
8      |
9      v
10Authorization Filters
11      |
12      v
13Resource Filters
14      |
15      v
16Action Filters
17      |
18      v
19Controller Action
20      |
21      v
22Result Filters
23      |
24      v
25HTTP Response

Filters execute inside the MVC execution pipeline, after routing has selected an endpoint.

Why use filters?

Without filters, developers often repeat the same code in multiple controllers.

Example:

CSHARP

1public IActionResult CreateOrder(Order order)
2{
3    Console.WriteLine("Starting action");
4
5    // Business logic
6
7    Console.WriteLine("Action completed");
8
9    return Ok();
10}

If every action needs logging, adding this code repeatedly creates:

Duplicate code.
Maintenance problems.
Higher chances of inconsistency.

A filter allows the behavior to be defined once and reused.

Types of filters in ASP.NET Core

ASP.NET Core provides several built-in filter types.

Authorization filters

Authorization filters run first in the filter pipeline.

Their purpose is to determine whether a request is allowed.

Example:

CSHARP

1[Authorize]
2public IActionResult GetOrders()
3{
4    return Ok();
5}

The [Authorize] attribute internally uses authorization filtering.

If authorization fails:

The action is not executed.
A 401 or 403 response is returned.

Resource filters

Resource filters run after authorization but before model binding.

They are useful for tasks that need to happen early.

Common uses:

Caching.
Short-circuiting requests.
Resource-level processing.

Example scenario:

A resource filter checks whether a response exists in cache before executing model binding and controller logic.

Action filters

Action filters run immediately before and after a controller action.

They are the most commonly used filters.

Example:

CSHARP

1public class LoggingFilter : IActionFilter
2{
3    public void OnActionExecuting(
4        ActionExecutingContext context)
5    {
6        Console.WriteLine(
7            "Action starting");
8    }
9
10    public void OnActionExecuted(
11        ActionExecutedContext context)
12    {
13        Console.WriteLine(
14            "Action completed");
15    }
16}

Flow:

TEXT

1Request
2   |
3   v
4OnActionExecuting()
5   |
6   v
7Controller Action
8   |
9   v
10OnActionExecuted()
11   |
12   v
13Response

Exception filters

Exception filters handle exceptions thrown during MVC action execution.

Example:

CSHARP

1public class GlobalExceptionFilter 
2    : IExceptionFilter
3{
4    public void OnException(
5        ExceptionContext context)
6    {
7        context.Result =
8            new ObjectResult(
9                "Something went wrong")
10            {
11                StatusCode = 500
12            };
13    }
14}

They are useful for:

Returning consistent error responses.
Logging controller exceptions.

However, middleware is usually preferred for global exception handling because it can catch errors outside the MVC pipeline as well.

Result filters

Result filters execute before and after an action result is executed.

Example:

CSHARP

1public class HeaderFilter : IResultFilter
2{
3    public void OnResultExecuting(
4        ResultExecutingContext context)
5    {
6        context.HttpContext.Response.Headers
7            .Add("X-App-Version", "1.0");
8    }
9
10    public void OnResultExecuted(
11        ResultExecutedContext context)
12    {
13    }
14}

Common uses:

Adding response headers.
Modifying output formatting.
Logging response information.

Creating custom filters

Filters can be created by implementing filter interfaces.

Example action filter:

CSHARP

1public class TimingFilter : IActionFilter
2{
3    private Stopwatch _timer;
4
5    public void OnActionExecuting(
6        ActionExecutingContext context)
7    {
8        _timer = Stopwatch.StartNew();
9    }
10
11    public void OnActionExecuted(
12        ActionExecutedContext context)
13    {
14        _timer.Stop();
15
16        Console.WriteLine(
17            $"Execution time: {_timer.ElapsedMilliseconds}ms");
18    }
19}

Registering filters

Filters can be registered in different ways.

Attribute registration

Apply a filter directly to a controller or action.

CSHARP

1[ServiceFilter(typeof(TimingFilter))]
2public IActionResult GetProducts()
3{
4    return Ok();
5}

Global registration

CSHARP

1builder.Services
2    .AddControllers(options =>
3    {
4        options.Filters.Add<TimingFilter>();
5    });

Every controller action will now execute this filter.

Dependency injection with filters

Filters can use dependency injection.

Example:

CSHARP

1public class AuditFilter : IActionFilter
2{
3    private readonly ILogger<AuditFilter> _logger;
4
5    public AuditFilter(
6        ILogger<AuditFilter> logger)
7    {
8        _logger = logger;
9    }
10
11    public void OnActionExecuting(
12        ActionExecutingContext context)
13    {
14        _logger.LogInformation(
15            "Action executed");
16    }
17
18    public void OnActionExecuted(
19        ActionExecutedContext context)
20    {
21    }
22}

This makes filters easier to test and maintain.

Synchronous vs asynchronous filters

ASP.NET Core provides synchronous and asynchronous filter interfaces.

Synchronous example:

CSHARP

IActionFilter

Asynchronous example:

CSHARP

IAsyncActionFilter

Async filters are preferred when performing asynchronous operations.

Example:

CSHARP

1public class ValidationFilter 
2    : IAsyncActionFilter
3{
4    public async Task OnActionExecutionAsync(
5        ActionExecutingContext context,
6        ActionExecutionDelegate next)
7    {
8        // Before action
9
10        var result = await next();
11
12        // After action
13    }
14}

Filters vs Middleware

Filters and middleware are often confused because both can execute code before and after processing.

Middleware	Filters
Runs for every HTTP request	Runs within MVC/action execution
Works before endpoint execution	Works around controller actions
Has access to HTTP pipeline	Has access to MVC context
Good for authentication, logging, exceptions	Good for action-level concerns

Example:

Use middleware for:

Global exception handling.
Request logging.
Authentication.
Compression.

Use filters for:

Validating controller inputs.
Auditing actions.
Modifying action results.

Filters vs Dependency Injection services

Filters should not replace normal application services.

A good separation:

TEXT

1Controller
2    |
3    v
4Service Layer
5    |
6    v
7Business Logic
8
9
10Filter
11    |
12    v
13Cross-cutting Concerns

Business rules belong in services, while filters handle reusable infrastructure behavior.

Real-world example

Consider an e-commerce API where every order creation request must be logged.

Without a filter:

CSHARP

1public IActionResult CreateOrder(Order order)
2{
3    logger.LogInformation(
4        "Creating order");
5
6    // Save order
7
8    return Ok();
9}

This logging code would be repeated across many actions.

Create a filter:

CSHARP

1public class AuditFilter : IActionFilter
2{
3    private readonly ILogger<AuditFilter> _logger;
4
5    public AuditFilter(
6        ILogger<AuditFilter> logger)
7    {
8        _logger = logger;
9    }
10
11    public void OnActionExecuting(
12        ActionExecutingContext context)
13    {
14        _logger.LogInformation(
15            "Executing {Action}",
16            context.ActionDescriptor.DisplayName);
17    }
18
19    public void OnActionExecuted(
20        ActionExecutedContext context)
21    {
22        _logger.LogInformation(
23            "Action completed");
24    }
25}

CSHARP

1builder.Services.AddControllers(options =>
2{
3    options.Filters.Add<AuditFilter>();
4});

Now every controller action automatically receives audit logging without adding duplicate code.

Common mistakes

* Using filters for logic that belongs in application services.
* Confusing filters with middleware and choosing the wrong execution level.
* Adding too many global filters and making request flow difficult to understand.
* Performing long-running operations inside filters.
* Using synchronous filters when asynchronous work is required.
* Forgetting that authorization filters run before action filters.
* Handling all application exceptions only with exception filters instead of middleware.
* Registering filters incorrectly and causing dependency injection failures.
* Assuming filters run for every type of endpoint, including non-MVC endpoints.
* Modifying response data in filters without understanding serialization behavior.

Follow-up questions

What is the difference between middleware and filters in ASP.NET Core?
What are the different types of filters in ASP.NET Core?
When would you choose a filter instead of middleware?
How do you create a custom action filter?
Why are asynchronous filters preferred for some scenarios?
Can filters use dependency injection in ASP.NET Core?

Short answer

Deep explanation

Why use filters?

Types of filters in ASP.NET Core

Authorization filters

Resource filters

Action filters

Exception filters

Result filters

Creating custom filters

Registering filters

Attribute registration

Global registration

Dependency injection with filters

Synchronous vs asynchronous filters

Filters vs Middleware

Filters vs Dependency Injection services

Real-world example

Common mistakes

Follow-up questions

More .NET Core interview questions