Any SaaS solution is a n-tier system, and as such, all the tiers should be protected, not only the application layer. If we put all our effort in the application and its code, we might miss important vulnerabilities in other parts of the attack surface.

The application is more obvious because it’s what the user sees and interacts with, but the direct attack surface is much larger:

• If the application exposes an API, an API gateway might be in place with its own attack surface.
• There can be a firewall.
• There can be a load balancer.
• There can be a WAF.
• The systems where the application runs can expose other open ports.
• Static artifacts could be published in buckets or other systems.

This list is only about the external threats, but internal threats should be considered as well. All internal components should be identified and the risk evaluated.

My point is that if you are in charge of the security of a SaaS solution, don’t think only about the application and its code, but think also about the other tiers or elements necessary to serve the application. A vulnerability in any component could be used to breach the security of the whole system or be used as a door to access additional functionality that was not supposed to be accessible.

One example where this has to be taken into account is a pentest. If you do a pentest of a SaaS solution, you have to look for web application vulnerabilities, but you also have to do a port scan of the hosts in the scope to identify other points of interaction with the system or its backend. If you focus only on web vulnerabilities, you are missing an important part of the attack surface that attackers are not going to ignore. In fact, it’s frequent that attackers target functionality that we have forgotten is there.

The presence of a WAF, an API gateway, a load balancer, or any other system our requests pass through before reaching the application are relevant because they can have their own vulnerabilities. They are supposed to be transparent, but as long as they process data, there is a possibility that malformed data makes them behave in an unexpected way.

In an n-tier system it is important to understand the different components that compose the solution and how each of them interact with the rest. It is particularly important to know how components communicate, which initiate the communication, how they authenticate and if the communication is authenticated.

With the raise of the zero trust model, it’s important to not consider any zone as trusted. Security controls should be designed minimizing the number of trusts.

A frequent example of a trust in a n-tier system is an internal network. It can happen that we can think that a system doesn’t need to require authentication nor encrypted communication because it’s internal and only can be reached by other internal systems. There has been a paradigm shift during the last years, especially after the Wannacry incident, where we became aware that internal vulnerabilities could be exploited and we have to consider them too. Currently, we should assume that each component in a n-tier system should authenticate who tries to connect to it and should validate the data it receives, even though we think that the previous component should have done that.

It’s true that if we follow the logic of validating everything, each component will need to repeat the validation work done by the previous component. I don’t think this is efficient. Some trusts should exist, but we have to choose wisely depending on the environment, the attack surface, the criticality of the component and our risk appetite.

To sum up, SaaS systems are not only software, but infrastructure too, and we cannot protect a cloud infra without taking into account all its components.