Knowing the security boundaries of our applications help building safer code. Read to understand.
So let's start with a solid definition. According to IEEE, security boundaries are:
Every new element we add to our architecture is another element in the security boundary equation: should I trust everything that comes from it or not?
defined by a set of systems that are under a single administrative control. These boundaries occur at various levels, and vulnerabilities can become apparent as data “crosses” each one.A good guideline to understand what the security boundaries of your app are is by:
- examining their applications from both functional and technical perspectives;
- understanding and evaluating the boundaries in and between their applications;
- taking into account all the interfaces and integrations to/from their systems;
- knowing that vulnerabilities can be propagated from one boundary to the other, possibly affecting not only your application but also leaking to your users;
Trust Model
how an organization determines who to trust with its assets or pieces of its assets.
As developers, we could use the same paradigm by considering:
- who should have access to my system;
- what can they access;
- which internal components in my application I trust, which I don't;
- which external components in my application I trust, which I don't;
With all that information you should be able to draw lines (security boundaries) around your architecture, helping you identify what are the trust levels between those boundaries.
Performing security verification
Once we know which are the boundaries of our apps, we could reduce the development effort to check security only in the application boundaries. For example: if my web app talks exclusively (is coupled) to my backend and vice versa, it's fair to say that I only need to validate my data once.
But don't treat that as a general rule. Actually, I would treat that as an exception as applications today are getting more and more complex.
Security checks in the cloud
What if my web app talks exclusively to my backend via a message queue or a storage account in the cloud? Is it safe to say that I should trust everything that reaches the backend? Of course not. After all, being the transport layer publicly available, it could be compromised. Being compromised, messages reaching the backend might also be compromised, resulting in breaches in my system. I should validate them whenever possible.Every new element we add to our architecture is another element in the security boundary equation: should I trust everything that comes from it or not?