Just to be sure, could you add a class without any reference to it?

    public class UnusedViewModel
    {
        public string RequestId { get; set; }

        public object Query;
    }

My expectation would be that its properties don't show up in remoteFlowSourceMembers.

Yes, that is correct. In Remote.qll RemoteFlowSource are only extended on types used as parameter types on methods in Controller like classes.

Nit picking, but what happens with get-only properties and private or static members?

Hmm, they are also included. There is no further restrictions on the Assignable members. Let's change this such that it is only public and non static assignable members.
Good catch!

Also - this is not nit picking! Really good that you ask these questions!

We can also fine-grain it even more. Do you have any special opinion on, which members we should included/exclude?

I'm not an expert on this. A quick google search revealed that (of course) this can be customized in asp.net. But in any case, I think if we mimic what the DefaultModelBinder does, we probably handle 95% of the cases correctly. I couldn't find an explicit list of the requirements on members, but it looks like only public non-static properties are handled. Also, properties with private setters are excluded as per dotnet/aspnetcore#38243. Also, maybe the class/record needs to have a default constructor. But I think we should dig a bit more deeply into the documentation.

@tamasvajk : Thank you!
Ah yes, I think you are right. I read some of this (I know it is old): https://docs.microsoft.com/en-us/archive/msdn-magazine/2012/february/asp-net-mvc-the-features-and-foibles-of-asp-net-mvc-model-binding

It doesn't explicitly state that properties should be get/set, but it seems like it is implicitly assumed and this could serve is a conservative extension of the existing logic (cover more with lower risk of false positives).
My suggestion would be that we take all public properties with public getters and setters and all public non-readonly fields. No statics allowed of course. Then we should be on the safe side and also cover most cases!

I think we can ignore fields altogether. There are some commonly used attributes to specify from where data should be bound. For example if data is taken from the request body, then FromBody is used: https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.frombodyattribute?view=aspnetcore-6.0. These attributes have no Field target, so I think we can safely ignore fields.

Alright! ASP.NET is complicated :-) It looks like the canonical examples all uses public (non static) auto implemented properties with public getters and setters. Maybe that is sufficiently conservative as a starting point.

Typo

Can be simplified a bit:

private class AspNetCoreRemoteFlowSourceMember extends TaintTracking::TaintedMember, Property {
  AspNetCoreRemoteFlowSourceMember() {
    this.getDeclaringType() = any(AspNetCoreRemoteFlowSource source).getType() and
    this.isPublic() and
    not this.isStatic() and
    this.isAutoImplemented() and
    this.getGetter().isPublic() and
    this.getSetter().isPublic()
  }
}