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?

  • 4
    For relevant reading, look up the least privilege principle
    – Natanael
    Commented Feb 26, 2019 at 23:13
  • 1
    I would call this security and robustness by design instead of the more commonly security as something added later on top. Principle of least privilege is an example of security by design, simple APIs with secure defaults are another. But this is less security as a side effect and more security as a thing so deeply baked in the initial design that it is actually harder to use it in an insecure way than to use it in a secure way. Commented Feb 27, 2019 at 4:24

3 Answers 3


Yes! This is fantastic practice and a core element of modern security.

What you’re describing is security engineering at its core: that is, taking 2 problems (developing and securing a product) where some may only acknowledge 1 (the former) and solving both simultaneously. As with any economics, good security engineering makes it cheaper and easier and more elegant to implement the more secure option than the less secure one. If someone has already built your web framework to sanitize input, for example, then you have much less work to do than if you do it yourself.

To that end, it might be difficult to find much information on your topic (I’m guessing, if you’re posting here, your prior research hasn’t yielded much results?). This is because the thing you’re referring to is both fundamental and sophisticated, encompassing a combination of the basic unit of engineering (solving problems given constraints) and high expertise (security is, by its nature, a complex field). I love it. It’s the best.

I can give you a keyword that may help your research, however: “secure development”. More specifically, you’ll want to find out more about the “secure development lifecycle,” or SDLC (not that SDLC, if you’re a normal developer). It probably just sounds like a descriptor, but it’s in fact a growing field in the industry as we all try and figure out how to bake smarter choices into our softwares and systems.

I can give tons of examples of the type of thing you’re talking about, as well:

  • As I mentioned, web frameworks sanitize user inputs so you don’t have to.
  • We all know not roll our own crypto! Instead, use a library like scrypt - it’s a more secure outcome and easier anyway.
  • Need to take query parameters from users? Why not put them in the URL, which is simpler and where there’s no way to do any JavaScript funny business?

It goes on. Great question though, good for you for being aware and developing consciously, and good luck! Please, ask any questions about this you want.


Unsure where this is really relevant, but what you describe looks like a separation of concern. It is used for example in Java with aspects. The developper code the business rule classes without worrying about the authorizations required to run the methods. Then the authorization rules are implemented in an aspect, basically wrapping the methods.

The well known Spring Security framework makes a heavy use of that pattern.


I think what you are seeking after, apart from what was mentioned by securityOrange - SDLC - could be described as either Privacy By Design or to DevSecOps.

Both Concepts tend to advocate that Security shall be proactive rather than reactive measures - which you seem to indicate in your initial question.

In regards to if this is a good or bad design topic - I'd like to point out that depending on what the scope of your application is - since it's within FinTech - you could have several Legislative Bodies that need to be followed ( PCI-DSS, GDPR)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .