The silent filter: How an ASP.NET MVC quirk became a security leak

We recently discovered a bug in one of our legacy ASP.NET MVC applications — the kind that doesn't throw an exception, doesn't log a warning, and doesn't announce itself in any way. It simply silently drops a filter on the floor. Unfortunately, that filter happened to be a security control.

Here's the story of what happened, why it happens, and what we're doing about it.

Remark: If you don’t have any legacy .NET Full Framework ASP.NET MVC apps remaining (good for you), you can stop reading.

What we were trying to do

Our application uses action filters for authorization. We had a global filter registered for all controllers that enforced a baseline set of access rules. For certain controllers, we wanted a stricter policy, so we added a local filter attribute directly on those controllers. Both filters shared the same attribute type.

The attribute was decorated like this:

The intention was clear: the local, more restrictive filter on the controller would layer on top of the global one, giving us defense in depth.

What we actually got was just one filter being invoked — and not always the one we expected.

What ASP.NET MVC actually does

This is where the framework's behavior surprised us. In ASP.NET MVC (full .NET Framework), when the filter pipeline is built for a given action, the framework collects filters from multiple sources: global filters, controller-level attributes, and action-level attributes. Before invoking them, it deduplicates filters of the same type when AllowMultiple = false.

The deduplication logic gives more specific scopes priority over less specific ones. So a controller-level attribute wins over a global filter of the same type, and an action-level attribute wins over a controller-level one.

In practice, this means when you register OurOwnAuthorizeAttribute globally and apply it to a controller, only the controller-level instance runs. The global one is silently discarded.

The expected behavior is not documented anywhere, or at least I couldn’t find it — and its security implications are non-obvious. You might assume "more filters = more checks." In fact, you get exactly one.

Here is the related source in the ASP.NET MVC framework:

Why this became a security problem

As we injected dependencies into our filters, we had created our own IFilterProvider and FilterCollection that worked with the Unity IoC container (where are the times):

Unfortunately this implementation didn’t take the implicit order rule into account and we accidently introduced a bug.

Our global filter enforced a general authorization rule. Our controller-level filter was meant to add a specific permission check on top of that. What we ended up with was just a general authorization check but the specific permission was not validated.

The result was a security gap in our application that matches the OWASP Top 10 # 1 - Broken Access Control.

Root cause summary

To be precise about the mechanics:

• AllowMultiple = false on an AttributeUsage tells both the C# compiler and the MVC filter pipeline that only one instance of this attribute should be active at a time for a given target.
• ASP.NET MVC's FilterProviderCollection respects this and removes duplicates during filter collection.
• The default priority order is the : Action > Controller > Global. Global filters lose to everything.
• We weren’t fully aware of this order and creating our own IFilterProvider instances broke this convention.
• There is no exception, no log message, and no warning when this deduplication occurs.

What we changed

First, we created a small example application to be able to isolate and replicate the issue.

Second, we changed the AttributeUsage declarations to allow multiple types:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true)]
public class OurOwnAuthorizeAttribute : AuthorizeAttribute { ... }

Third, we reviewed all other global filters in the application and audited every controller-level attribute to check for type collisions. We found two other cases where the same type was used both globally and locally, though neither had security implications.

Finally, we documented this behavior explicitly in our internal development guidelines for anyone working on the legacy application going forward.

Final thoughts

This bug was a reminder that security in software isn't just about writing the right checks — it's about understanding the execution environment those checks live in. A filter that isn't invoked is indistinguishable from a filter that was never written.

If you're working with a full .NET Framework ASP.NET MVC application and you use both global filters and attribute filters of the same type, we strongly encourage you to audit your filter configuration and add explicit tests asserting that the filters you expect to run actually do.

We got lucky that we caught this in a review and not in the wild. Next time, we'll have tests to catch it for us.

More information

aspnetwebstack/src/System.Web.Mvc/FilterProviderCollection.cs at a0b7fe4a95fa29a273b66c6273ee7430ba454754 · aspnetwebstack/aspnetwebstack