Wasn’t sure what category this post was most appropriate in.
I’m wondering if there is some built in way or preferred way of doing security trimming on response DTOs.
Depending on which Role is currently authenticated with the service, I want to optionally populate specific fields in the response DTO. So for example, if Admin, populate all fields. If User, populate all but the “ConnectionString” field, etc.
Thanks
This logic shouldn’t be embedded in any serializer or AutoMapper, check the Users role within your Service implementation and only make use of the properties each User are allowed to specify.
Although I’d personally have different Services that each group of users have access to, allowing all Users to call the same “uber” Service capable of super user access sounds like it’s easy for simple logic errors to result in security vulnerabilities. Having different Request DTOs/Services also clearly spells out what each Service is capable of, reducing further confusion. They can all call the same internal method for processing their functionality behind-the-scenes, but at least with different Services their access is protected behind a well-defined Services layer.
You’re right, that does lend itself to security vulnerabilities. I’ll take your advice and make a subset service for end users. Thanks.