In this article, we are going to explore the defense-in-depth principle applied to web applications. Actually, it can apply to most software. Nowadays, modern software is designed with an internet connection in mind; even the enclosed embedded systems might resemble a similar architecture.
Worth noting are several other principles. Taking into consideration fail secure, open systems, reusable components, architecture of least privilege, all while considering risk management as well. We will not explore each principle, and some might be common sense by security practitioners; therefore, the article is designed for programmers or developers who want to understand more about securing applications, as well as cybersecurity enthusiasts.
Defense-in-depth
Understanding the two main simple concepts surrounding defense-in-depth is necessary, we will keep in mind: security zones, and diversity of defense.
This means instead of setting up one big firewall or security tool and calling it a day, we must properly understand the application’s design to secure it so that security doesn’t also burden the app’s user experience.
There is nothing wrong with setting up security tools, even blindly; it’s still a good alternative to not doing anything. However, security is about prioritization as well, and understanding the blind spots of the application goes a long way. The blind spot can be even outside of the application: the host, the operating system where the host is, the device used to log in as administrator there.
One of the best ways to understand proper app security is to design it with breaching in mind.
What happens if the admin password is leaked?
A good approach here is to avoid having an administrator who can do everything in the app with elevated privileges. And if it’s a requirement, there’s also the possibility, for example, of implementing an elevated risk with a time gate, that can be accessed with a multi authentication. Therefore, if an attacker manages to log in with my credentials, and tries to do various activities with elevated privilege, that exact functionality needs to be accessible via another authentication method. Triggering a phone / email alert or both.
Diagram
The architecture diagram, as mentioned before, shows a simplified web application; the focus is on security, not the web application’s design.

Most modern web applications are built in layers, much like the layers of an onion, though these layers are typically distributed across different systems and are not really connected directly. Maybe the spider web analogy sounds better only if the spider does a poor job of creating the web connections.
Main layers are:
- User Interface layer. To keep it simple, we will not assume a microfrontend architecture is set in place; however, we will only discuss one additional layer to keep things relatively simple: the authentication layer.
- Processing layer. Since modern web apps are so different, and based on emerging tech, this can be a backend-for-frontend layer, or a regular server-side layer. Usually, it means that the data that needs to be accessed by the UI layer needs to be processed for performance, usability and security reasons.
- Data layer. Where the data is stored. Depending on the technology used, it can be SQL, SQLite, MongoDB, NoSQL, each with its specific strengths and weaknesses.
These are, however, highly simplified representations of the architecture of a web application capable of supporting many users and extensive resources. Depending on the architecture, monolith or microservice, a medium to large web application has a lot more layers to peel from: authorization layer, dozens of services that connect one to another, depending on the case, multiple server-side layers, redundancy built for backup and restore, etc.
Layered defense
The architecture diagram, as mentioned before, shows a simplified web application; the focus is on security, not the web application’s design. Software itself will not be discussed here; however, open-source software will be recommended for each layer.
Deconstructing even further, we can notice that the security diagram has several layers:
Monitoring & Response
This is of course common sense, because monitoring is the backbone of security defense, and the most important tool for when breaches occur. Cybersecurity forensics is only as good as the monitoring itself. Otherwise attackers usually wipe their traces, and the only hint to what group did the attack is by evaluating the region, or the economic activity: Primary (extraction of natural resources), Secondary (manufacturing), Tertiary (services), and Quaternary (knowledge-based activities).
Ideally, for monitoring and response, it should not be on the same server where the app is hosted. This, however, is a general recommendation for each layer that cannot always be implemented. Either because it makes little sense economically, or the owners assume this risk.
Tool: https://prometheus.io/
Security Perimeter
This can be imagined as a prison fence. It’s never the only layer of defense, but it is mandatory as well. This is where we can add a firewall, DDoS protection, and various limiters to help not only with security but with the performance and availability of the application.
Tools:
WAF: https://www.openappsec.io/ Usually, you don’t really need a WAF if you can handle own policy and rules, and leverage mod_security. For some things more complex, and possibly leveraging machine learning to detect patterns, openappsec is a great tool that can help with rate limiting as well.
DDoS: This is a very hard topic to discuss in a few sentences. Ideally, if possible, use Cloudflare. If trying to build a DDoS protection on a self-host, most important thing to understand is that there is no simple solution to install and forget it. Rate limiting is helpful, and other steps include switching IP addresses or entire clusters depending on the assumption that an attack is taking place. In short, rerouting traffic and large bandwith might be required to implement this capability on your own.
Entry-point based layer
For example, an app’s login needs to be secure. If there are APIs connected without an authentication layer and entrypoints within the app protected by authorization, then you can consider weighting risk and prioritize unprotected entrypoints first.
If you start by assuming the application is compromised, you can analyze it from an attacker’s viewpoint to find what they could exploit. While its impact may be less than unprotected entry points, all entry points must be assessed and prioritized based on their individual impact.
Understanding the risk of specific features within the authorization layer differs from experiencing those risks unexpectedly. It’s not only expensive, but it can involve significant legal risks.
Tools:
Here, tools and recommendations are a bit too many to write. If we refer to the application code, we have listed a few mitigation strategies. Depending on the application, this is where DevSecOps comes in, and fortunately is not something developers need to understand thoroughly, but for the curious minds, read more about it here.
A useful read for web developers is regarding security headers: [1],[2],[3].
Last, OWASP 10 should be a good starting point. Understanding the most common attacking techniques and what goes wrong most often within a web application, OWASP got it covered.
Photo by Igor Miske on Unsplash.