I know the title of this blog leads to question marks – but give me 5 minutes and I’ll try to put everything into a meaningful context.
I wrote my first web application around 1999 (while I was still at university). In the traditional way, a few scripts were copied to a folder via FTP and the application was made available to the wider world. It was about a marketplace for used trucks and before you ask, no, it was by no means a success.
Personally, however, it was an enriching experience. From then on, it was clear to me which area of IT I wanted to develop further.
I think back to those times here and there. Today’s development of modern web applications has nothing in common with those days. We now all use frameworks for the front and back end. Each of these makes our application thousands, hundreds of thousands or millions of lines of code larger and more complex.
Frameworks help us to structure our software. When used correctly, they also make an important contribution to the quality of the software. They increase the productivity of our developers and allow us to benefit from best practices. In many cases, frameworks also “produce” security.
Without these frameworks and tools, we would no longer be able to hold our own on the market as software developers. They are a central and increasingly important component of our solutions and products. At best, the result of our work is as good as the underlying components.
The currency
There is one important currency in custom software development: trust. The customer must have confidence that we are able to implement the projects or products in the required quality, within the available time frame and within the given budget.
This trust must be earned with technical know-how, sincerity, personal commitment and the technical project tools that enable you to meet the requirements.
In order for me, as the creator of software, to successfully implement a project for all sides, I need to know which criteria I can fulfill and how well. I need to know which parameters I can control myself, where I am controlled externally and which framework conditions I need to adhere to in order to survive in the market. As with all risks, I either accept them and live with them, actively try to minimize them and get them under control or try to insure myself against them.
The reputation
When a customer entrusts us with the development of a web application, it means that they are entrusting us with part of their reputation. We are therefore jointly responsible for how our customer is perceived by the outside world. If an incident occurs that compromises our customer, we are jointly responsible.
We need a large number of components to operate our web applications: From the kernel, the operating system, server applications and runtime environments to the frameworks and third-party components we use, everything must be available.
In the end, it does not matter which of the many components are compromised in an attack. The integrity of the entire solution is compromised in the event of a successful attack.
The risk
The question now is how we deal with this.
We can accept the risk (ok, that was meant ironically).
We can try to minimize the risk by thinking about the types of attack and vulnerabilities of our system. The problem with this is that there are far too many components. A team would need far too many specialists and even then we would not be able to keep up with the dangers lurking on the Internet. The attack vectors are becoming more diverse, methods and tools are developing rapidly. Old patterns, however, remain. The threat situation is additive.
This leaves most software developers with only one last option: we try to insure ourselves as best we can.
The insurance
For these reasons, we use a web application firewall in practically all projects. We therefore place part of the application security in the hands of specialists.
The use of web application firewalls can be relatively difficult at the beginning. The systems must be adapted to the respective application. It is sometimes possible to adapt both the web application and the web application firewall. It can become difficult if third-party components tear entire holes in the web application firewall – then it is necessary to investigate whether to switch to other solutions or accept the consequences. Of course, you shouldn’t have to wait until the end or during the implementation phase of a project to find out. Make sure that the equipment is already available to the developers.
A web application firewall can have a significant influence on the design of a web application. Talk to the manufacturer and its consultants. Ask about the best practices for the respective product. Question the answers. And be prepared to give up a few cherished habits.
It is also important to explain to the developers why we want to use these additional protection mechanisms. It is not uncommon for a solution to work perfectly in principle, but not be suitable for a web application firewall due to the way it is implemented. Make it clear at the start of the project that the WAF is to be understood as an important sub-component of the overall solution.
Allow extra time during the stabilization phase. Only live operation will show whether the coordination between WAF and application is OK in every situation. Make sure that the web application firewall provides you with blocked requests in a suitable form so that you can react quickly.
Web application firewalls help us developers. They relieve us of work, they produce security and increase the value of the solution for our customers and their users. We developers of business applications should be just as concerned with web application firewalls as we are with the latest JavaScript frameworks. In doing so, we serve the customer, but ultimately, above all, we serve ourselves.