The main ways applications are vulnerable

The phrase “web application security” might make you think that the attack surface is only about the application itself. The bad news is that it’s unfortunately not. Of course the intrinsic characteristics can, and will, play a big part in the vulnerability of the application, but a list of factors, mostly out of physical reach, are at play.

Areas of risk for an application

  • The technology: When you are choosing a technology to use for developing your web application, you are probably looking at the most popular options of the time. Let’s take the example of JavaScript since it has set itself apart as the primary web language. Client-side Javascript allocates memory and garbage-collects it when needed, which means we do not have to deal with memory allocation. However, when JavaScript expanded server-side, the browser sandbox which prevented access to memory was no longer there. To deal with binary data, you have to create a buffer. The class method allocated the memory but (formerly) didn’t zero it. It would hold whatever was in memory at the time! Consequently, if you forgot to zero the buffer right after creation, a lot of secrets, such as keys or source code, could be exposed. This particular class method has since been deprecated and replaced. In OpenSSL, Heartbleed was a major memory leak vulnerability that was uncovered in 2014. Memory leaks are just one example of technology-related vulnerabilities. Look at the technology traits from a risk perspective. Every benefit comes with its security flaws, and the best way to prevent against them is to know them first. Read More
  • The code: Thanks to many open source dependencies, you do not have to write all the code for your application from scratch, and can leverage some of the many packages made available by the community behind each language. This is great for building off the work of others and speeding up the development process, but it means that many of your application vulnerabilities could come from code that is not your own. Since dependencies often use other dependencies, scan all third-party dependencies you use, and monitor the news updates about newly discovered vulnerabilities (or use a tool to check for vulnerable dependencies automatically). In addition, check your outdated dependencies. You will be asking for trouble if you do not update them in a timely manner: read the release notes to know what the update is about, assess your level of risk, and test the implications of these risks for your applications. In addition, make sure to avoid publishing secrets to the repository: If you are using npm which is Node.js package manager, use .npmignore file, in addition to .gitignore file, to avoid publishing sensitive files into the npm package.
  • The framework: Frameworks have the benefit of speeding up web application development by taking care of the most common development needs: pre-built functions, links to databases, security implementation, documentation, and support. They also allow more frontend functionality, which makes them vulnerable to Cross-Site Scripting (XSS), cross-site request forgery (CSRF or XSRF) – where the attacker tricks the user into visiting a different page that then sends malicious requests to the application web server, and cross-site script inclusion (XSSI) – a JSON vulnerability that can allow an attacker’s website to read data from a JSON API. Angular, one of JavaScript’s popular frameworks, has built-in support to help prevent some of these vulnerabilities. The latter two must be mitigated primarily on the server side, but Angular provides helpers to make integration on the client side easier. Read more: How to prevent - on Angular guide

Areas of risk in the server-side environment

Servers and databases

This is probably not news to you, but the server plays a huge part in the security of the web applications. One the very first objections to cloud services used to be primarily regarding security. Cloud providers have made significant progress in that area by keeping up with the latest security updates and regularly testing the infrastructure. You should do the same if you own on-premise servers and don’t rely on a third-party provider to ensure the level of security that you need. Audit your infrastructure (including the parts in the cloud), decommission any piece that you do not use, and include server security within your software development life cycle so that your developers prioritize server-side mitigation and anticipate the implications of any action on the server as well. Attackers often target servers for the data they store. Do not store unnecessary data, make sure to encrypt any sensitive data you have to store, and use standard encryption. In addition, there are a lot of safe APIs available to handle payment or any credit card-related transactions, so you should consider using them instead of developing your own.


Because an internet-facing network is like having thousands of doors around for attackers to poke through, a DMZ used to be the response of many organizations to any security fear regarding the internet. Enterprises segmented the network in such a way as to protect it from the outside world. With a huge slice of assets now on the cloud, cloud service providers are the ones to set the appropriate firewalls to protect your instances. You will have to be aware of these protections to be able to audit them. Read more: Is the DMZ dead? Not quite


DNS is one of those things that people take care of once and then forget about until something happens. DNS is the backbone of your online assets so make sure to check the settings regularly Read more: Eight reasons why you should conduct a DNS audit

Areas of risk on the client-side environment

The user device

It is tempting to want to offer your web services to everyone in every way. However, this should not come at the expense of your security level. Restrict your application to supported devices, browsers, and operating systems so that it does not run at all under unsupported environments, rather than half-running with flawed security. If a platform does not meet your security requirements, be transparent about why you do not want to offer your services on it and your users will understand that you prioritize their security. Encourage your users, whether employees or clients, to update their devices as soon as the app or operating systems updates are available.

Malicious emails

Let’s imagine your web application is not protected against cross-site request forgery. An attacker could force a logged-in user to perform an action without consent or even knowledge when this user opens an innocent-looking email containing a link.

Your users

Users play a big role in the security landscape, whether through their own actions (such as choosing weak passwords or clicking on suspicious links) or absence of action (such as failing to report an abnormal application behavior). By implementing a strong password policy, encouraging the use of secrets manager, informing your users about phishing, encouraging responsible disclosure etc., you will help your employees and clients to be more security-minded and in turn help your web application be more secure.

And these were just some examples… We will never stress enough that web application security is a matter of people and processes as well as technology. You can use the OWASP Software Assurance Maturity Model as a framework to ensure your software development life cycle strategy is comprehensive and encompasses all levels of your organization.

Ready to protect your apps?

Get started for free · 5 min installation · No credit card required.