Building a custom action filter for validation in ASP.NET Core

When a request lands on an ASP.NET Core controller, the framework walks through a layered pipeline that includes routing, model binding, the action itself, and the result execution. Validation usually happens during model binding, with the [ApiController] attribute automatically translating DataAnnotation failures into a 400 response. For many teams in Sydney and Melbourne, that built-in behaviour covers the basics, but real-world APIs accumulate rules that simply do not fit on a property: a tenant id must match the caller's organisation, a purchase order cannot be approved after 5 pm AEST, a customer record must not collide with an existing Australian Business Number. These are exactly the cases where a custom action filter earns its place.

Action filters sit at the heart of the MVC pipeline, between authorisation and the action method. They give developers a place to run logic before and after the action executes, and they support dependency injection, so any registered service can be reached from inside the filter. The C# Corner Annual Conference 2020 audience will recognise this as one of the cleanest ways to keep controllers free of repetitive plumbing while still enforcing rich, context-aware rules.

The article walks through building a reusable validation attribute, registering it so that it can be applied selectively or globally, and understanding how it differs from middleware and built-in model validation. Along the way, it borrows patterns common in Australian software houses, from fintechs in Barangaroo to mining platforms based in Perth, where input rules are tied as much to local regulations and time zones as they are to schema correctness.

Why action filters matter for input validation

Cross-cutting concerns are the bread and butter of filter pipelines. Authentication, logging, caching and rate limiting all benefit from being applied uniformly rather than copy-pasted into every action method. Validation, once it grows beyond a few attributes, behaves the same way. A team in Brisbane working on a home-loan API, for instance, needs to check that the loan amount is consistent with the property valuation, that the applicant's state matches the property's state, and that the request originates from a broker with the right accreditation. Writing that logic directly inside the action method is brittle; centralising it in a filter keeps every endpoint honest without polluting the controller's primary purpose.

The other advantage is composability. Filters can be combined, ordered, and conditionally applied. A [ValidateABN] attribute can be stacked alongside an [EnsureBusinessHours] filter on the same endpoint, and each one short-circuits the request independently when its rule fails. This is the kind of expressive power that the [ApiController] convention alone does not offer.

Anatomy of an ASP.NET Core action filter

An action filter implements either IActionFilter or IAsyncActionFilter, both of which live in the Microsoft.AspNetCore.Mvc.Filters namespace. The synchronous interface exposes OnActionExecuting and OnActionExecuted; the asynchronous counterpart provides a single OnActionExecutionAsync method that wraps a next delegate. Most modern codebases prefer the async flavour because it cooperates better with I/O-bound checks such as calling an external sanctions service over the NBN or consulting a cache hosted in a Sydney region.

The filter lifecycle mirrors the request lifecycle. OnActionExecuting runs after model binding but before the action method. If the filter sets context.Result to a non-null value, the action method is skipped entirely. This is the key mechanism for short-circuiting bad input and returning an IActionResult such as BadRequest with a structured payload. OnActionExecuted fires after the action runs, useful for auditing or modifying the result, although validation work is almost always placed in the pre-execution hook.

Filters can be plain C# classes applied as attributes, or they can be created through TypeFilterAttribute and ServiceFilterAttribute, both of which resolve dependencies from the DI container. This distinction matters when the filter needs scoped services such as an EF Core DbContext or a configuration provider.

Implementing a reusable validation attribute

A typical starting point is a class that derives from Attribute and IAsyncActionFilter. The attribute can declare constructor parameters that act as configuration, such as a property name or a threshold, while the filter logic lives in the override.

public class EnsureWithinBusinessHoursAttribute : Attribute, IAsyncActionFilter
{
    private readonly string _timeZoneId;
    public EnsureWithinBusinessHoursAttribute(string timeZoneId)
    {
        _timeZoneId = timeZoneId;
    }

    public async Task OnActionExecutionAsync(
        ActionExecutingContext context, ActionExecutionDelegate next)
    {
        var tz = TimeZoneInfo.FindSystemTimeZoneById(_timeZoneId);
        var local = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, tz);
        if (local.Hour < 9 || local.Hour >= 17)
        {
            context.Result = new ObjectResult(new
            {
                error = "requests_outside_business_hours",
                timeZone = _timeZoneId
            })
            { StatusCode = 400 };
            return;
        }
        await next();
    }
}

Applying it on a controller is then a one-line affair: [EnsureWithinBusinessHours("Australia/Sydney")]. The same attribute can be reused on endpoints that need the same gatekeeping, and because it is an attribute, it shows up in tooling and Swagger documentation without extra wiring.

For filters that need richer dependencies, such as a repository or an HttpClient, the recommended approach is to subclass ActionFilterAttribute and pair it with TypeFilterAttribute, or to define a separate filter class and reference it through ServiceFilterAttribute. This lets the DI container inject scoped or transient services safely.

Comparing built-in model validation with custom filters

Several mechanisms exist for validating input in ASP.NET Core, and choosing the right one depends on what the rule needs to know. DataAnnotations are perfect for shape-level checks that do not depend on anything outside the payload. IValidatableObject lets a model validate itself, which works for cross-property rules but happens during model binding, before services are available. Middleware sits even earlier in the pipeline and is well suited for cross-cutting concerns, while custom action filters are the natural home for rules that need HttpContext, the current time, or a database roundtrip.

The table highlights why custom filters fill a specific niche: they are the right tool when validation depends on runtime context, external services, or organisational policy rather than on the shape of the payload.

Registering and applying the filter across controllers

There are three common registration strategies. The first is to decorate individual actions or controllers with the attribute, which gives precise control. The second is to register the filter type globally in Program.cs through the MvcOptions.Filters collection, so every endpoint inherits it. The third is to expose the filter as a service and reference it through [ServiceFilter(typeof(MyFilter))], which is the cleanest path when the filter needs scoped dependencies.

services.AddScoped<ICustomerRepository, CustomerRepository>();
services.AddControllers(options =>
{
    options.Filters.Add<EnsureWithinBusinessHoursFilter>();
});

Because the framework constructs filter attributes through reflection, any service injected via constructor must be resolvable from the request scope. A common mistake in Australian teams migrating from .NET Framework is to register a scoped service as singleton, which then breaks when the filter holds onto a DbContext across requests. Following the standard lifetime rules avoids subtle memory and threading issues, and it keeps the behaviour of the filter predictable under load.

Common pitfalls and performance considerations

Validation filters run on every request that hits a decorated endpoint, so any I/O they perform is on the hot path. A filter that calls an external API on every action invocation will quickly become a bottleneck, especially on plans where outbound traffic is metered. Caching, batching and circuit breakers should be considered early. A filter that consults a Redis cluster in ap-southeast-2 is fine; a filter that hits a third-party provider synchronously for each request is not.

Another pitfall is over-validating. If the same rule is already enforced by a DataAnnotation on the DTO, the filter is duplicating work and slowing the response.

Signals that built-in validation is no longer enough

• The rule depends on the current time, the caller's identity, or another request-scoped value.
• The check requires a database lookup or an external service.
• The failure response must include structured context, not just a list of field errors.
• The rule is shared by many endpoints and should be configured centrally.

Equally, filters should not become a dumping ground for unrelated logic. Logging, header rewriting and metrics belong in middleware or in dedicated filter attributes; mixing them with validation makes the code harder to test and reason about. The discipline of keeping filters small, single-purpose and async-friendly pays off when the application grows.

Practical scenarios for custom validation filters

• Tenant isolation: verify that a path or body parameter matches the caller's organisation before the action runs, returning 403 when it does not.
• Region-aware gating: allow requests only during local business hours in Australian states, taking daylight saving into account.
• Sanctions and PEP screening: call an external watchlist provider before a high-value transfer is initiated, caching the verdict for a short window.
• Rate-of-change checks: reject a body that would push a customer's stored preference past a regulated cap, which requires reading existing data.

Used thoughtfully, a custom action filter becomes a focused place where business rules meet HTTP plumbing, without leaking into either the controller or the model. That separation is what keeps APIs maintainable as requirements evolve, and it is the same discipline that frameworks like ASP.NET Core are designed to support.