As Shrek once said, security (and Ogres) are like onions, they have layers.

Web Applications were a game changer because they allowed true “build once, run anywhere” capabilities. But this came with the caveat that your app was now “build once, hack from anywhere”. As long as it was online, even a hacker on the other side of the planet had access and could hack it.

This was because web applications, like Ogres, had many layers. In this series, we will unwrap some of the layers and talk about how to defend them. Web Applications have a wide surface of attack, from the applications themselves to the infrastructure they run on. That is why web security needs a layered approach.

What is Web application security?

Web Application security is the detection and prevention of cyberattacks on web applications. This involves securing the applications and the infrastructure they run on.

Web applications exist on multiple levels, meaning they have numerous attack vectors. Your approach to their security should be done with this in mind. There is no set definition of layers, but we can break them down broadly as

1. Infrastructure
2. Web Application

Each of those has its own layers, i.e.

Infrastructure (everything outside your web application)

• OS
• database
• Server, Datacenter, country
• Build, CI/CD

Web application

• business logic (Python, JavaScript Code)
• External libraries and dependencies
• interpreter CPython, JS sandbox
• Browser support
• API

That’s a lot of layers, and if you drill in, some of those have layers of their own, which results in a huge attack surface. How do we defend such a large surface area? We do it by adding layers of defence that reduce the attack area to more manageable levels, that’s how.

The trick is to walk the fine line between too much and too little, because with every layer of defence you add, you also increase the overall complexity of the system. The goal is to be secure by design and ensure your application is safe from the ground up.

Today, we will mainly focus on the infrastructure layer and talk about the actual web application in the following post. To make things more understandable, and because I don’t have many Ogre analogies aside from that first one, we are going to use another relatable example, i.e., 10th-century architecture. A web application is like a castle, and what you are protecting is the gold inside the castle. There are many ways to defend your treasure from raiders, but not all are made equal.

Infrastructure

Let's talk about our castle. When you want to protect your treasure, you don’t build your castle in a swamp, unless you want it to sink twice, burn down, fall over, then sink again, Monty Python style, before it becomes useful. You build it on defensible, solid terrain. Doing so makes the terrain itself work for you rather than against you.

In web application security, this means that before we write a single line of code, we consider where we will deploy and how secure that place is.

Server

Let’s first consider your chosen OS and server technologies. Just as an old, crumbling castle invites a siege, an unmaintained tech stack invites cyberattacks. Always ensure your OS and core technologies are up to date and opt for Long-Term Support (LTS) versions where possible to guarantee continued security updates.

Life has gotten easier thanks to PaaS(Platform as a Service) providers who handle most of this for you. However, it is still beneficial to check, and if you are using services that allow you to specify a version, then select an LTS version, the service providers will usually update these for you.

And while we are on the topic of core technologies, remember it's better not to have it than to have it unmaintained.

Database

Where would you rather keep your mountains of gold? In a loose pile in the courtyard next to the gate or a locked room deep inside the castle? Database security deserves special consideration. Sensitive data like credit card information should be protected, for example having by having it encrypted or stored in a separate database.

Another way to protect your data is to ensure its integrity. Data integrity means maintaining the accuracy and consistency of data by preventing unauthorized changes and ensuring that the data remains unaltered over its lifecycle. In our castle example, think of this as a guest list. If Lord Farquaad was uninvited, you do not want their plus one to still get into the castle, do you? In this case, uninviting Lord Farquaad should automatically uninvite his plus one. In databases, you use constraints to achieve this, for example, if a record is deleted, all other records that depend on it are also deleted.

Just like how it’s not only raiders who are after your gold, but also a greedy steward, you should also be careful of insider threats to your data. You need to put in place measures to prevent unauthorized access or misuse of data by employees or other insiders.

One way is to use the principle of least privilege. This is when you give users only those privileges that are vital to perform their intended functions. Another thing is to regularly audit those privileges to determine if they are still needed. If not, remove them. Another way is to add row and column-level access to your data, but be aware that this adds additional complexity.

There are other measures you can take, such as using Data Loss Prevention(DLP) solutions, but that would be going too deep into IT policy for this post. But on that note, have an IT security policy.

CI/CD pipeline

In The Lord of the Rings: The Two Towers, the great fortress of Helm’s Deep was breached when the Orcs exploited a tiny, insecure drainage pipe. So it is in software, your CI/CD pipeline can introduce security flaws. CI/CD is used to automate the deployment of your application, so the most critical thing here is to ensure that it doesn’t make it easy for a bad-faith actor to smuggle malicious code directly into your production system.

Knowing what you are building is key to securing it, as is knowing who is triggering a build. Proper access controls are a must, as is verifying the integrity of all artifacts. You should also require manual approval and review before triggering production deployment.

Configuration is also important because if you misconfigure your pipeline, you will leak secrets faster than the time it takes to run the pipeline. For example, security keys saved in variables or the code can be logged when the pipeline is run. This is bad if you are working on an open-source project where the logs can be publicly accessible, but even in private repositories, the people who work for your pipeline providers will have access to those logs, and you probably don’t want them getting your keys either.

How can we do this? Well, first, instead of saving secrets in code or local variables, you save them as environment variables. If your platform allows it, you should also use a secret manager, so that secrets are encrypted before storing, automatically decrypted when needed in your pipeline, and usually removed from the logs.

The principle of least privilege also applies to secrets in your pipeline. The processes should have just enough privileges to do what needs to be done and no more.

Take your pipeline seriously.

Network and the Internet

Firewalls and intrusion detection/prevention systems (IDS/IPS) act as the outermost defenses of your digital fortress. Firewalls keep out unwanted visitors, while IDS/IPS actively monitor for and neutralize threats before they breach.

So, in our castle analogy, the firewall would be the actual wall, and IDS/IPS would be the guards who actively check that no rogue people have entered to cause problems.

Not all hacks are about getting something out, though. Another type of attack is the distributed denial of service(DDoS). That is when hackers flood your application with requests that aim to overwhelm your system so that it can no longer handle legitimate requests.

Think of it like a massive, angry mob crowding at the gates, hurling insults. They aren’t trying to get in, but they block the entrance so that the merchants who bring food also can’t get in.

Load balancing can help lessen that burden by distributing incoming requests across multiple servers. It’s like your guards telling your merchants to use a different gate when one is crowded.

While talking about load balancing, I should also mention Content Delivery Networks (CDNs). CDNs distribute content across multiple servers, reducing the load on any single server and making it harder for attackers to overwhelm the target.

They sound similar, but generally, load balancing is distributing traffic across a group of servers, often within a specific data center, while CDNs distribute content in different geographic locations, such as different cities or countries.

While it’s good to distribute the load, you can also limit how often particular IP addresses access the application.

None of the solutions we mentioned above will stop a DDoS attack on their own, but when combined, you should be able to survive it.

In extreme cases, you can also configure your firewall to start blackholing requests. Blackholing is a countermeasure to mitigate an attack in which network traffic is dropped based on some strict requirements. It has the side effect that if you get the requirements wrong, it will also affect legitimate requests, and that’s why I think it should be used as a last resort.

General Advice

It’s a fact of life that there will never be enough time or budget to do everything you want to do. But systems still need to be secured, so you need to make the most of the time and budget that you have. Let’s talk about some general things that are not layers per se, but help make your application more secure.

Complexity

You can add additional layers of security, but in my experience, that’s not always the best approach. Additional security layers also add additional complexity to your system and can add additional vulnerabilities. The more complex your system is, the higher the chances are that you will overlook something, and you lose overview with the more layers you add.

Adding additional layers also comes at a price, either in complexity or cost; adding an external firewall from a big-name provider can cost an arm and a leg, while rolling out a free one will cost you your time.

Logging and Monitoring

A well-monitored system can catch threats before they escalate, while detailed logs will ensure that if the worst happens, you can trace exactly how it happened and prevent it from happening again in the future. After all, if you wake up one day with half the treasure room gone, you would want to know who took it and how they did it, because if you don’t find that out fast, they might come back tomorrow night and take whatever is left.

Your logs ideally should never stay on the same server that hosts your web application. After all, if they gain access to the server, it’s trivial to cover their tracks.

Also, like all good things, there are such things as too little and too much. Log too little, and you risk missing vital information because it wasn’t logged. Log too much, and it becomes almost impossible to find the root cause due to information overload. You need to strike a perfect balance between too little data and too much.

Encryption

We already talked about encrypting passwords and communication, but encryption is such an important topic that I felt it needed its own category. Encryption is one of those words everyone has heard but not everyone fully understands. Encryption is the process of transforming information in a way that, ideally, only authorized parties can decode.

Remember when King Henry VIII wrote several love letters to Anne Boleyn, and they somehow ended up in the Vatican being read by the Pope? That’s an example of unencrypted communication. But if Harry and Ann had created a code that only the two of them had, and those letters were sent in that code, no one would have known what the letters said, and their secrets would have stayed safe; that’s encryption.

There are a few points I want to make,

1. Use encryption in transmission. Ensure all connections are encrypted, make sure all communication uses Transport Layer Security(TLS), not just web traffic, but also communication to the database, mail server, etc.
2. Use Encryption at rest. How is your data stored? Use of safe hashes for passwords, integrity checks, and digital signatures. If you have sensitive information like credit card numbers, encrypt those too.
3. Keep your encryption keys and other secrets, like passwords, safe. All the encryption in the world won’t save you if hackers can easily access the passwords. Basically, don't put your system password on a sticky note stuck to the monitor. Or in your castle example, don't hang the keys above the lock.

Encryption should never be an afterthought, it should be part of initial planning.

Stick to well-established encryption standards instead of rolling out your own. History is full of failed attempts by people who thought they could do better.

Conclusion

A castle isn't just about its walls, it’s about the strategy behind them. The same goes for security. You don’t need the latest and greatest tech just because it's shiny. Stable, well-maintained solutions are often the best choice. If you know the layers of attack and their boundaries, you can safely structure your security.

Understanding the role of each layer is key to building secure web applications and in our next post, we’ll learn more about the layers of defence in web applications, follow us on LinkedIn to get notified when that post comes out.