I have long since felt that one of the best ways to effectively implement new security constructs is to implement it in the background, where it is not the primary feature of some new construct. This idea continues to be the basis of many developments for the AJAr Foundation, but I am trying to explain it now as it applies to my day job in FinTech where developers historically have neglected to code for security while using convenient (but unprotected) constructs in order to finish the work quickly.
For example, I have a new construct called
uf_GetUserCustomerData (fake name) which accepts the identity of our intended end-user audience and returns information that only that user should see. It is a DB construct wrapping unprotected constructs such as a View.
I have designed this function with convenient features such as inline decryption of sensitive user data, masking of certain data, and filtered exposure to those unsecured constructs they already know and love. This way, the data is still protected regardless of what happens downstream.
Are there any examples of similar approaches to security? Is there a term for what I'm doing here? And probably most importantly: Am I wrong to think this methodology is good practice?