Monolithic applications have fallen out of favor in the era of microservices, but that may change soon. Organizations are starting to pay attention not only to the advantages but also to the downsides of using microservices, including the context of security.
Popularity of microservices
The original motivation for building software from modules, rather than a single piece of code for the entire application, remains unchanged. Modular software is easier to develop, maintain, test, extend, and reuse. The combination of cloud deployments with agile development has made these advantages even more attractive. This is especially true for startups. Small teams with only laptops can now use microservices to quickly create innovative software without an upfront investment. For containerized cloud applications, microservices have become the mainstream architecture. Cloud providers are now developing out-of-the-box environments and capabilities for building highly distributed software.
But despite all its benefits, a microservice architecture does not fit everywhere. For example, in the Amazon case study, using them by default turned out to be a fundamentally wrong decision. Due to the type and sheer volume of microservice calls, the distributed architecture based on AWS serverless components was slow, expensive, and unable to scale to the required level. Moving to a monolithic application resulted in a 90% reduction in cloud costs and improved performance in this specific situation.
This case study comes at a time when more organizations are rethinking their cloud strategy and seriously weighing the pros and cons of deploying in the cloud versus on-premises. While this is largely driven by cloud costs, the choice of application architecture also has serious security consequences.
Monolithic architecture: harder to update, but easier to secure
Having a monolithic application that contains the entire codebase in one place has traditionally been considered a bad engineering practice. In particular, any change usually requires rebuilding the entire application, even if it is just a single line of code. Depending on the internal structure, a monolithic architecture can also be difficult to maintain, as any change can break functionality. And it can also be prone to bloat, since it is faster and safer to add a new feature than to adapt or remove an existing one. But from a security perspective, a monolithic application can be much easier to secure rather than more distributed models.
To begin with, the attack surface of a monolithic application is typically smaller compared to architectures where each microservice is a separate target. Less distributed applications also tend to have fewer external dependencies, so it is easier to understand what to test. In a monolith, all business logic and communication between functions is handled internally, rather than through API call streams exchanged between the frontend and backend. It is also easier to configure data protection, network security, and runtime security tools, such as a web application firewall (WAF).
Security testing is also simplified, as the team has access to most or all source code (often with the same technology stack and programming language). Then teams are able to apply not only dynamic application security testing (DAST), like Invicti and Acunetix solutions, which can be implemented at various stages of the software development life cycle (SDLC), from the first builds to the final application in production. But it is also possible to use static application security testing (SAST) and software composition analysis (SCA), like Mend.io.
One of the drawbacks of a monolithic architecture is that the process of debugging and fixing security flaws can be slower compared to microservices, where it is easier to isolate and remediate vulnerabilities in a specific service (if the development team has access to the source code).
Cons and pros of microservices in terms of security
The advantages of microservices must be weighed against potential security issues. The attack surface expands to dozens or even hundreds of independent services. At the infrastructure security level, each service often runs in its own cloud container. These services are organized using Kubernetes or a similar solution, making cloud security essential. All application components communicate via API calls. Ensuring their security is critical for both operations and testing. Authentication is a particular concern. Since each service is separate, monitoring becomes another weak point. Attackers can potentially target individual services without triggering a notification that the application is under attack.
With cloud applications, it is easy to rely on third-party dependencies and services. The company does not control these services and can only test them externally. This limitation restricts security checks to DAST and manual penetration testing. Applications often use multiple programming languages and technologies. As a result, code analysis tools like SAST and SCA become less effective. Even if a team controls and tests its core codebase, this is not enough. It cannot fully cover the entire attack surface.
As mentioned before, the advantage of microservices is their ability to isolate security flaws more easily than in a monolithic application. It is easier to pinpoint a vulnerability within a specific service. Applying a firewall or blocking a service entirely is also simpler if an immediate fix is not possible. Additionally, services are usually self-contained. This reduces the risk of a complete system compromise if one component of the application is breached.
Robust application security testing regardless of architecture
The relative ease and speed of building and modifying web applications also extends to changes in architecture and deployment models. But while the software development and infrastructure aspects of such projects are often understood and manageable, security does not always keep up. For example, if an application is migrated to a different technology stack and programming language, the existing SAST tools and workflows may no longer be suitable. Or if a development company that previously relied heavily on SAST to test its monolithic applications starts building software using microservices and finds that they don’t have DAST to test their entire environment that heavily relies on APIs.
In principle, DAST solutions have the advantage of being able to scan web applications regardless of their technologies and architectures. But in practice, they can vary in accuracy and practical usefulness. For instance, many companies rely on cloud-based vulnerability scanners to test their cloud applications. When they decide to move some of their software to on-premises deployments, they often discover an issue. The product they use no longer meets their needs. Similar surprises can occur when shifting to microservices. Companies sometimes realize too late that they now need to scan many APIs. Their existing tools cannot handle this new requirement.
A universal option is a DAST solution that works effectively regardless of architecture or deployment model. For example, Invicti, a leader in dynamic web application scanners, allows organizations to embed application security testing into their DevOps pipelines to automatically run scans, confirm vulnerabilities, and send vulnerability reports directly to issue tracking systems. And all this for both cloud and on-premises applications, with support for security checks of various API types.
