rule of thumb estimate "difficulty" of establishing MIM between server side Api and server side backend:
(1-p[ad])**# of admins

compared to estimate of "difficulty" of establishing MIM between client and server
(1-p[us])**# of users

estimate of "difficulty" of establishing MIM between client and server side backend:
(1-p[ad])**# of admins * (1-p[us])**# of users

(with p[ad] and p[us] in best cases close to 0, but p[ad] probably still lower due to more security measures and habits server side, but more users than admins)
for attack vectors like keylogging after having infected one machine able to send SQL to the backend. For most scenarios the probability (1="total difficulty", inaccessible) server side will be higher. Slashing a couple of possible attack vectors is IMO worth some developer ease IMO.

Agree to disagree and stop ?

regds

thomas


>I cannot favor calling little apis to do such simple things. That is SQL Server's job. There is plenty of security provisions in the product - let the hackers and Microsoft fight it out. Anything we roll out is more likely an opportunity for a hacker. In all sincerity - if a hacker can put in a MIM between an application and sql server, that same hacker can put in an MIM between an application and your APIs.
>
>>
>>But as most operations are either simple CRUD or count(), sum() calls working on a single table, I think those should be created sever side - with parameters, as the client side gotten text values might have been corrupted.
>
>>Having an obscured back door in the server side API obscure(In: JSON, Out: JSON) accepting those dynamic queries embolded above does not add any more risks than executing those calls directly, but marks the dangerous area server side clearly - it becomes a wart you might tighten up sooner than if you accept the pure_parameterized_SQL request metaphore.
>>
>>Post Snowden security scrutiny has shown too often that transport layers requested by standard methods to be safe were not. And client side code cannot be considered safe, as there are hackers out there knowing many more debug tricks than me. As a Web/JS client today often cannot be ruled out forever, creating an architecture not cracked in the first 5 minutes by using web debug tools grows in need similar to the realization of SQL injection risks last century.
>>