Composable architecture offers developers a new paradigm for building websites and web apps. The development approach provides the ability to more rapidly build technology stacks by making use of logically separated reusable and customizable components.
Designing an app to use composable architecture can also promote a better security model, but has its own unique challenges. In this post we’ll explore a bit more about threats and risks of the modern web, how adversaries target websites, and how composable architecture compares to the traditional monolithic development approach.
Before getting too deep into the specifics of composable architecture, it makes sense to take a step back and review the threats and risks of the modern web.
A web of security threats
While this list is not exhaustive, the following are some of the more common contemporary threats to websites and web apps:
Website defacements
Website defacements, where the content of a website is altered, are as old as the web. A famous early example of a website defacement was when the promotional website for the 1995 movie Hackers was defaced by a group called the “Internet Liberation Front”. While this particular defacement has been speculated to have been a marketing stunt, hacktivist groups continue to use defacements as a way to spread their message.
Abused as attack infrastructure
While defacements are meant to be known, many breaches are meant to remain unseen, such as when a website has been compromised with the intention of being used as part of a larger attack infrastructure. Threat researchers often find open website directories hosting a variety of malware, unsuspected by the website owner. Breached legitimate websites make excellent attack vectors to host phishing payloads or as a traffic redirect to malicious Command and Control (C2) infrastructure.
Data theft
Data theft is a threat that’s likely top of mind, especially for e-commerce websites. Often websites are breached with the intent of targeting its visitors and customers for fraud. Much sensitive data is held by and can pass through a website; Personal Identifiable Information (PII), credit cards, and site specific sensitive data. With access to a website, it’s also possible to generate fraudulent SSL certificates for the domain. Data theft may also occur due to compromised third-party included code, such as the attacks widely perpetrated by the threat actor collectively known as MageCart.
Obtain passwords and credentials
Often the most valuable piece of data on a website are the usernames and passwords of its users. Once dumped, hashed passwords can later be cracked offline. These lists can then be abused in Credential Stuffing attacks — where valid username and password combinations are tested on a variety of services, including corporate network logins. A breached server-side environment may also offer up passwords and access tokens, providing access to other backend systems.
Gain an entrypoint to an organization
While stolen credentials are a popular method of breaching the remote network services of an organization, a breached web server on the perimeter of a network can provide an adversary with a foothold into a trusted network.
Distributed Denial of Service (DDoS) attacks
DDoS attacks overload a website with traffic with the intent of creating a service disruption or taking the site entirely offline. DDoS attacks can come in different forms, but typically work by overwhelming a web server with traffic. This traffic can be in one of the lower OSI network layers (e.g. flooding a server with Layer 3 ICMP packets), but more often focuses on Layer 7, the application layer. A Layer 7 DDoS attack would direct a large volume of HTTP traffic to the website, overwhelming the web server. While the intent of a DDoS attack is usually to take a website offline, it may also be abused to increase the datacenter costs of the victim.
How are websites breached?
Threats manifest themselves into risk through an action. Some of the major risks that contribute to website breaches include:
Coding flaws
Vulnerabilities in software — be it in frameworks, plugins, or custom code — are likely the first item that comes to mind when thinking about how a website might be breached. This is a large bucket of possibilities with attacks ranging from Cross Site Scripting (XSS) to Server-side Request Forgery (SSRF) to Broken Authentication, injection attacks, or perhaps the most serious — Remote Code/Command Execution (RCE). Many of these flaws are classified within the OWASP Top 10 — or the ten most common vulnerabilities on the web.
Server breach
A server breach can also lead to a website breach. The cause of a server breach could be as simple as an adversary logging in to the server with compromised credentials, poor patch management, or the compromise of another piece of software on a host that was not logically or physically separated from the application.
Files with sensitive data found allowing access
Adversaries understand the types of mistakes often made by development teams, such as files with sensitive data exposed in the open. In some cases, a web server misconfiguration may provide an open directory listing, allowing an adversary to browse easily for sensitive data. In other cases tools may be employed to scan a website for common file names and extensions. Adversaries look for sensitive files that may provide further access. Specific examples include exposed database backups, configuration files containing passwords, or version control directories (e.g. .git/).
What attack surface is reduced with composable architecture?
Composable architecture is not a panacea. Insecure code and application architecture will affect any software, but if employed correctly, composable architecture can reduce some common risks that affect websites built on a monolithic software stack.
An example of a monolithic website stack is the LAMP architecture. This could be a WordPress website running integrated third-party plugins on an Apache web server with a connected MySQL database.
A composable architecture version of this same stack might be a headless WordPress website and database which are not publicly accessible, with a frontend interface developed using the Gatsby framework. The site is then built statically, and deployed to and cached on the Netlify edge network.
In the composable scenario above, there is no code being processed by a web server. The website code is built ahead of time in an isolated environment, protected by Netlify’s robust security architecture and segmented from other Netlify users. Once deployed, public static assets are mirrored out to the Netlify CDN edge network as stateless files served up to visitors.
Common misconfigurations, such as accidentally exposing sensitive database backups or version control directories, are mitigated by the build and deploy process. The codebase that creates the website is separate from the assets that are served to the customer. The backend Content Management System is physically isolated from the frontend website. In addition, no code is executed server-side, reducing the impact of a backend vulnerability, and the site itself remains decoupled from organizational architecture.
DDoS attacks are reduced in impact, since the edge network the site is deployed to is designed to handle a vast amount of traffic.
By using a composable architecture, certain classes of OWASP Top 10 vulnerabilities are reduced in risk. A great example of this are Server-side Request Forgery (SSRF) vulnerabilities. The largest exploitable risk of a SSRF vulnerability is when they can be used to access backend infrastructure. Deploying a site to an edge network like in the scenario decouples the site from any infrastructure of note, ensuring that even if a SSRF vulnerability were discovered in the composable web app, the impact would be reduced.Other classes of OWASP vulnerabilities such as Cross Site Scripting (XSS) remain a concern, especially if best practices for eliminating these vulnerabilities are not followed — such as using JSX templating.
Composable or not, it remains important to understand where data is present in an application, how the data is accessed, and test for potential vulnerabilities that may expose this data to portions of the application that violate the expected segmentation. Ultimately, the segmentation and isolation of composable architecture applications can be a boon to security when used correctly.
For a deeper dive on this topic, check out our recent webinar on the security benefits of composable architecture.
