Should we overstrictly typecheck object arguments

bogeeee commented 1 year ago

Let's say we have a service with runtime typechecking (shielding) enabled (as of > 0.9.0 release) :

type User = {
    name: string,
    lastName?: string,        
}

class MyService {
   changeMyUserSettings(user: User) {
   }
}

What if an attacker calls it with


const poisoned = {
   name: "Hans", 
   bpms_permissions: { allowWrite: "all" }
}

myRemoteService.changeMyUserSettings(poisoned);

Currently you can "poison" it with any additionaly fields, i.e. bpms_permissions and maybe some deeply nested library will evaluate it somehow or it gets saved in the database. Currently you have to just have some knowledge, how pure your code behind the service is and be very carefull, when allowing object parametes that get passed on to other API. So, what do you think ? Is this really an issue in practice ? Should we overstrictly forbid the use of additional properties and what would be the implication. Should we add some decorators for this like @tsUnlistedFields("erase"|"allow"|"error"). Is this even possible to implement and not clash mit Record / Indexed / Union types ?

bogeeee commented 1 year ago

bogeeee / restfuncs

Should we overstrictly typecheck object arguments #1