Eye on the End User: Application Layer Security
by Gary Stevens
The application layer is where users interact with your apps, so its security should be paramount. Here are a few considerations
Securing applications can be a struggle at the best of times. Today, developers need to ensure that every level of their applications are audited for—and protected against—common vulnerabilities.
In recent years, much of the focus has been on ensuring the resilience of the technical systems that make up applications, such as secure networking protocols and cloud-native app security.
There is another aspect of web application security, however, that is often overlooked: the way that users interact with your apps. Securing this aspect of your apps—which is often referred to as the application layer—is just as critical as ensuring that your back-end systems are secure. But doing so often means that developers meet with organizational resistance from UX and executive-level stakeholders.
In this article, we’ll go through a quick definition of what application layer security is, the threats that this layer of your apps is exposed to, and what you can do to mitigate them.
What is the Application Layer?
The “application layer” is one of the seven layers that appears in the Open Systems Interconnection (OSI) model. This is a security framework that allows developers to conceptualize the security of their software as seven interconnected layers:
- The physical layer
- The data link layer
- The network layer
- The transport layer
- The session layer
- The presentation layer
- The application layer
Three of these layers relate to media, and four to hosting. They run from the most basic hardware and infrastructure level—the physical layer—to the layer that is closest to the way that users actually interact with software, the application layer. Each layer is designed to build upon the last, and viewing software like this allows developers to isolate security threats to the level of hardware or software that they are most relevant to.
For most software developers, layers 4 to 7 are the most important to watch for vulnerabilities. Layers 1 through 3 are typically administered in-house or on-premises and taken care of by most leading web hosting providers. On the other hand, the most common security vulnerabilities that businesses face usually appear in the later layers, which are more user-focused. Of these, the application layer is by far the most liable to be attacked, but is often forgotten about.
Threats to the Application Layer
The application layer is the most vulnerable layer in the OSI model for two reasons. The first is that, since it is closest to the end user, it offers a larger attack surface than any of the layers that precede it. Second, the layers “below” the application layer only typically see interactions with users who are more conscious of security.
The types of threats that the application layer is exposed to will be familiar to any developer who has worked with web security:
- DDoS attacks, which require applications to be shielded.
- HTTP floods that aim to lock up applications and deny access to legitimate users.
- SQL injections on applications that have poorly verified user input protocols.
- Cross-site scripting and parameter tampering.
All of these attacks, it will be observed, make use of a simple principle: imitating legitimate users to flood applications with traffic or to inject malicious code.
Threats like these are nothing new, of course. They have been observed since the early days of the web. However, they are enjoying a resurgence for a few key reasons. For one, the rise of SaaS as a business model has essentially transformed many business utilities into web apps, thereby making them susceptible to web-based attacks. This is significant because it is expected 86% of companies will use SaaS for the vast majority of their software needs by 2022.
The second reason is developers have spent much of the past decade focused on network and session security and have often failed to pay attention to the threat that users (legitimate or not) pose to their software.
Mitigating the threats the application layer presents first requires a focus on the end user. Though stack-based approaches to threat mitigation—such as hardening backup systems and employing threat intelligence software—can help to limit the effect of application layer attacks, it is critical that developers seek to limit the opportunities for them at a more basic level.
This can be achieved by implementing a number of tools and approaches. Primarily, you should ensure that application layer security requires that user input be carefully controlled. This means not only locking down session security and user access, but also hardening your apps against SQL injections, one of the most common forms of cyberattack—65% of online businesses have been a victim of an SQL injection at least once. It also, at an even more basic level, requires that strong user password policies are enforced.
At a broader level, employing perimeter scanning software can also help defeat application layer attacks. Monitoring user connections and network loads, and implementing the ability to limit these, can be used to defeat DDoS attacks that can be very damaging.
Ultimately, ensuring application-layer security means remembering that old adage of cybersecurity: Never trust the user. Though developers are often all too aware of the dangers of allowing users too much freedom when it comes to interacting with software, UX departments can be resistant to implementing restrictions that they see as adversely affecting usability.
At the moment, unfortunately, this remains a source of tension between developers and managerial staff within many companies. Although new and AI-driven approaches to monitoring user activity promise to make this easier in the years to come, at the moment negotiating this compromise requires that developers constantly argue for the importance of application layer security in every piece of software they publish.
We hope that the approach we’ve described above will help you to do that, but if you want to read further you can check out our series on application security, which takes a deep dive into some of the issues above.