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 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
.npmignorefile, in addition to
.gitignorefile, to avoid publishing sensitive files into the npm package.
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.
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.
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.