Filters in ASP.NET Core MVC allows us to run certain actions before or after specific stages in the request processing pipeline. There are some built-in filters in ASP.NET Core. We can also write custom filters to execute actions at various stages of the request pipeline. They also help us to handle cross-cutting concerns and avoid duplication of codes.

We have discussed Filters in detail in the Implementing Action Filters in ASP.NET Core article. In that article, we have explained how to implement an Action Filter in an ASP.NET Core Web API application. In this article, we’ll explain the different Filter types available in ASP.NET Core MVC and how to implement each type.

If you’ve missed some of the previous articles in the series we recommend visiting the series page: ASP.NET Core MVC Series.

To download this article’s source code visit: Filters in ASP.NET Core MVC.

We have divided the article into the following sections:

First, let’s look at the different types of Filters available in ASP.NET Core MVC.

Filter types

Each filter type is executed at a different stage in the request pipeline.

Authorization filters are run first and are used to determine whether the current user is authorized for the current request. They can short-circuit the pipeline if a request is unauthorized.

Resource filters come right after the authorization. We can use it to implement caching or short-circuit the filter pipeline for performance reasons.

Action filters can run code immediately before and after an individual action method is called. We can use it to manipulate the arguments passed into action and the result returned from the action. Razor Pages do not support Action filters.

Exception filters are used to globally handle all unhandled exceptions that occur in the application.

Result filters can run code immediately before and after the execution of individual action results. They run only when the action method has executed successfully. 

Authorization Filter

Authorization filters control access to action methods. They are the first filters to be executed within the filter pipeline. They have a before method called OnAuthorization(), but they don’t have an after method.


Let’s implement an Authorization Filter. For that, we need to implement IAuthorizationFilter interface and the OnAuthorization() method inside it.

In the filter, let’s define a field called _permission which is supplied via the constructor. We can also create a method CheckUserPermission() that performs the authorization logic. 

For testing purposes, let’s assume that the hypothetical user always has just the Read permission and no Write permission. When the user is not authorized, we can set the Result property of the HTTP Context as UnauthorizedResult which will short circuit the execution pipeline.

Let’s create the AuthorizeActionFilter class:

Now, let’s create an Attribute for the filter that we just created using the TypeFilterAttribute

We have the Authorize attribute ready for use now. Now let’s use it in our application.

For testing this attribute, let’s create 3 controller actions – Index(), Read() and Edit().

Let’s leave Index() method without specifying the Authorize attribute. For the Read()  method, let’s specify Authorize attribute with Read permission. Let’s specify the Authorize attribute with Write permission for the Edit() method:


Remember that for testing purposes, we implemented the filter in such a way that only Read permission is available for all users.

Let’s run the application and navigate to \home\index:


Since no authorization is required, it works fine.

Now let’s navigate to \home\read:


This action method requires Read permission which is available for the user. 

If we place a breakpoint in the OnAuthorized() method in the AuthorizationFilter, We can verify that it is not executed for the Index() method but is executed for the Read() method.

Now let’s navigate to \home\edit:


This action requires the Write permission which is not available for the user and hence it throws an HTTP ERROR 401 denoting unauthorized request.

What we see here is the standard browser error page for HTTP 401 Response. We can also create custom error pages corresponding to various status codes in our application for better user experience.

In this section, we have learned how to implement an Authorization Filter.

Resource Filters 

As we understand from the name, Resource filters can be used for handling resources and helps to short circuit the request execution pipeline if required. A common usage of this type of filter is the implementation of Caching. This can avoid the rest of the pipeline when a Cache hit happens.


Let’s look at how we can implement caching using the resource filter.

First, let’s define a class CacheResourceFilter implementing IResourceFilter interface. The Resource filter has a before method OnResourceExecuting() and an after method  OnResourceExecuted().

Let’s define a dictionary object _cache for holding the cached value and a string value _cacheKey for storing the Cache key:

In the OnResourceExecuting() method, we can check if the _cacheKey is present in the _cache dictionary. If it is present, we set the context.Result with the cached value. We can short-circuit the filter pipeline by setting the context.Result property. 

In the OnResourceExecuting() method, we check if the _cacheKey is already present in the _cache. If not, we’ll insert the context.Result value into the _cache.

Then, let’s create an attribute for this filter:

Finally, let’s create a controller and an action method to return a text indicating the time at which the content was generated. Also, let’s decorate the controller with the CacheResource attribute we just created.


 Now, let’s run the application and navigate to /cached:


When we access this URL for the first time, we can see the content is generated with the current timestamp. Then, for all subsequent access to the same URL, we’ll get a cached version of the resource. We can verify this by checking the timestamp in the URL. Also, if we place a breakpoint in the controller action method, we can see that it is hit only in the first request. For all subsequent requests, we can see that we have short-circuited the execution pipeline by using the resource filter.

Great! We have learned how to implement a Resource Filter.

Action Filters

Action filters run right before and after each action method is executed. We have discussed implementing action filter in detail in the article section: Action Filters Implementation.

The linked article shows how to implement an action filter in an ASP.NET Core Web API application. We can follow the same steps for implementing action filters in an ASP.NET Core MVC application.


Let’s create an action filter that handles invalid models. If the model is invalid, we are going to return a standard BadRequest response with a custom message.

Our custom validation class needs to  inherit from the abstract ActionFilterAttribute class and override the OnActionExecuting() and OnActionExecuted() methods:


The OnActionExecuting() runs before the action method and OnActionExecuted() after the action method.

In the OnActionExecuting() method, we can check if the Model is null or ModelState is invalid. In both these cases, we can return a BadRequest response. This way we can handle this across the application instead of having to write this code in each of the action methods.

Now let’s use this filter in an action method:


If we call this action method without supplying a valid Book model, we can see the standard BadRequest response with the custom message that we have given:


That’s it! In this section, we have looked at how to implement an action filter.

Exception Filters

Exception Filters are used to handle any unhandled exceptions that occur in our application. They do not have before or after methods. They just implement the OnException() method. This method will be called whenever an unhandled exception occurs in our application.


To see the exception filter in action, let’s create an action method that generates an unhandled exception:

Now, let’s create a custom exception filter by implementing the IExceptionFilter interface. We can provide the required exception handling behavior in the OnException() method:

In the OnException() method, we can set the ViewResult as CustomError . Then we can pass the exception details into the view as ViewData.

After that, we’ll create the CustomError view and display the error message in a user-friendly manner:


Now, let’s run the application and navigate to \home\generateerror:


We can see that a custom error page is displayed with details of the exception which we can customize to show only the required information to the user. This way, we can give the user a much better experience and we can handle exceptions across the application in a consistent manner.

Exception Handling – Middlewares vs Filters

Additionally, we can use middleware for handling unhandled exceptions. So, when should we use an exception handling middleware and when should we go for an exception filter?

If we are concerned about errors that may occur outside of the MVC context or our code, for example, we may want to capture an error that occurs inside a middleware or a filter, then we’ll have to go for an exception handling middleware. On the other hand, if we want to get the MVC context during exception handling and perform some action based on that, then we’ll have to use an exception filter.

In this section, we have learned how to implement an exception filter in our application.

Result Filters

We can use Result filters to run code before or after the execution of controller action results. They are executed only if the controller action method is executed successfully. We can write logic to surround the view or to apply some customizations to all the action results in our application.

Let’s say we want to add a particular value to the header of all the action results in our application. 

We are going to take a look at how to implement this using a result filter.

First, let’s create a class AddHeaderFilter that implements the IResultFilter interface. Result filter has a before method called OnResultExecuting() and an after method called OnResultExecuted()

In the OnResultExecuting() method, let’s add a custom response header:

After that, let’s create an attribute for the result filter that we just created:

Finally, let’s create an action method in the HomeController and apply the AddHeader result filter attribute.

Let’s run the application and navigate to home\testresultfilter.

On inspecting the headers, we can see that the custom header is present in the response:


This way we can use result filter to customize the action results across the application.

Great! In this section, we have learned how to implement a result filter.


In this article we have learned the following topics:

  • The different types of filters available in ASP.NET Core MVC.
  • Creating a custom Authorization Filter.
  • Implementing Caching using Resource Filter.
  • Using Exception filter to handle unhandled exceptions.
  • Adding a custom response header to all our action methods using Resource Filter.

With that, we come to the end of the ASP.NET Core MVC series. Hope you enjoyed reading through and had some good learning in the process!

If you have enjoyed reading this article and if you would like to receive the notifications about the freshly published .NET Core content we encourage you to subscribe to our blog.