This changed slightly when it was moved. Now this.getARoute() is being used instead of this.getDeclaringType().getFile().getRelativePath() (which is the same as long as getARoute is not overridden).
Is this a bug fix (this might change the description of WebFormActionMethod elements)?

This is an intended fix (the route to a method should also contribute to knowledge about the names referring to that method to help determine what it does)

I am wondering about the correctness of this predicate with different permutations of these attributes in the inheritance chain. E.g. suppose you have a base class with a method that has the AllowAnonymous attribute and then override that method in a child class, where you give it an explicit Authorize attribute. What effect would that have in ASP.NET? Does this predicate correctly model that behaviour?

Hmm; I'm not sure what ASP.NET would do in that situation.
How much do we need to be concerned with correctly covering every edge case? As it seems like these kinds of situations are unlikely to come up in real codebases.

I do not know off the top of my head what ASP.NET would do in that case, so I'd need to try it with a sample project as well. I am happy if we postpone looking into this and don't block this PR on addressing this detail.

I am concerned by the rate at which this may produce false positives. My understanding is that e.g. in ASP.NET the standard mechanism for managing authentication/authorisation is through attributes. The query does not seem to handle those (as well as auth code inherited from parent classes / any other form of auth), so would this query trigger alerts in those cases?

Are authorization attributes alone able to manage authorization that's based on the request parameters?
In these MRVA results I don't see a lot of evidence of other auth mechanisms that were missed.

No, using attributes is only sufficient where authorisation is based on roles, policies, etc.

For resource-based authorization checks in the body of the handler are indeed necessary. Would the example in that article be identified by checksUser?

However, role-based or policy-based authorisation may be sufficient in a lot of cases, so we probably shouldn't flag up insecure direct object reference vulnerabilities where checks are performed in that way.

Based on your description of the MRVA experiment, it seems like the results are only for the top 100 repos? Are those the top 100 C# repos or the top 100 repos that use ASP.NET? In any case, I would probably use a larger sample. It is also likely that the different authorisation mechanisms offered by ASP.NET are more prevalent in enterprise codebases, rather than in open-source ones.

It looks like the example in the article would be identified by checksUser, because it uses the User property.
This MRVA run with the checksUser condition reversed shows the auth methods that are being used.

However in this top 1000 MRVA run, it looks like there are indeed some FPs from role-based authentication for admin roles; so this is something that should be checked.
Should all instances of the Authorize attribute with Roles or Policy fields set be considered sufficient, or should a more complex check be made?

because it uses the User property

Ah, I don't think I had realised that properties count as Callables.

However in this top 1000 MRVA run, it looks like there are indeed some FPs from role-based authentication for admin roles; so this is something that should be checked.

Thank you for running that experiment! It does indeed seem to confirm my concerns here.

Should all instances of the Authorize attribute with Roles or Policy fields set be considered sufficient, or should a more complex check be made?

I think the logic is a little bit more complicated because the Authorize attribute may be placed on the method, class, or parent classes(?). So you need to check in all of these places for that attribute as well as any attributes which inherit from Authorize. Furthermore, you also need to check for the absence of the AllowAnonymous attribute, which may override any Authorize-like attribute that's placed further out. That's just off the top of my head, so there may be further subtleties. Microsoft's documentation should have the full details.

In terms of the arguments to the Authorize attribute, I don't think we should care at all. As long as there is some authorisation check, that should be considered a mitigation for the purpose of this query since we can't reason about what the intended audience for a particular endpoint is.

It is my understanding that an Authorize attribute with no arguments means "Any logged in user can access this", whereas this query focuses on cases where we'd expect stronger access controls than that (e.g. deleting any resource). Is this correct?

Yes, although consider that there might be web applications where most visitors have no accounts and the only authorised users you'll get are administrators that should be able to perform such actions. (E.g. a blog, a simple CMS/news website, etc.) In those cases just being logged in may be sufficient access control.

Also, for classes that inherit from Authorize, we wouldn't necessarily expect any parameters either, e.g.:

class MyAuthorizeAttribute : AuthorizeAttribute
{
    public MyAuthorizeAttribute()
    {
        base.Policy = "Administrators";
    }
}