Securing a web application can be daunting. News of security breaches and hacks are reported frequently, and, sometimes, it seems like sophisticated attackers can do just about anything.
Because web applications can be accessed from anywhere, they are possible targets for anyone in the world. And the sheer number of things that can go wrong can make it difficult to know where to start when thinking about securing a web application.
But there are standards and best practices in place for security, and tools that help developers create secure applications. Automated processes can make security an ingrained part of the software development lifecycle, and other developers can be valuable resources for figuring out how to navigate the security landscape.
We talked with a few experts in web application security to get a sense of how they stay on top of it all.
WEB APPLICATION SECURITY TIPS
- Use a web application firewall
- Keep track of APIs
- Control access to APIs
- Enforce expected application behaviors
- Follow the OWASP Top 10
- Use existing tools and standards
- Update dependencies
- Track dependency risks
- Check that security is configured correctly
- Set up DevSecOps
- Use password managers
- Get help from experts
- Stay educated on security changes
Use a Web Application Firewall
One way to protect your web applications is to use a web application firewall (WAF), said Robby Russell, CEO of Planet Argon, which specializes in helping companies improve their Ruby on Rails web applications.
“You put that in front of your web application, you route all of the web traffic through that — kind of like a proxy,” Russell said. “Those web application firewalls have their own database of patterns that they keep an eye out for, and that can add another level of protection. If they detect that there might be someone trying to poke at your application to find a vulnerability, then the web application firewall might detect that and maybe temporarily block those people.
There are many different WAF vendors, such as Imperva, AWS and Cloudflare. WAFs are available for applications hosted on the cloud as well as for those running on physical servers.
Keep Your Security Tools Close, but Your APIs Closer
Web applications often call multiple APIs, making API security an integral part of web application security. Dmitry Sotnikov, chief product officer of 42Crunch and curator of APIsecurity.io, said it’s important for developers to treat APIs as part of an application’s attack surface, and to keep track of all APIs in an application and their security measures.
“They need to know which APIs they have,” he said. “They need to have some sort of discovery process within that company so that no developer comes up with yet another API without any control, security review or user testing.”
Part of the problem, Sotnikov said, is that habits from the days before microservices have carried over into the present.
“In the past, people would work on traditional applications that would decompose the application into components and different functions,” he said. “And those functions would talk to each other in different objects, different classes, but they would all be within the same server.”
These days, services within an application are often communicating over networks, which makes them more vulnerable to attack. As a result, they also require more rigorous security precautions.
“People treating APIs and microservices as an implementation detail,” can be dangerous, Sotnikov said. And the first step to securing APIs is keeping track of them.
Access Control Is Critical for API Management
After accounting for all the APIs used in an application, the next step is managing access to those APIs.
Developers should make sure that “only components and users who are supposed to be calling this API can call this API,” Sotnikov said. “What the architect needs to do is know that this API is only supposed to be called by these other three microservices, and they should authenticate in this particular way.”
In addition to restricting access to internal APIs only to services that need them, developers should also make sure APIs only give out information necessary for their function. APIs giving out more information than necessary complicates security tracking.
“They should implement a zero-trust approach in which any call needs to strictly follow the requirements for the API.”
“They should implement a zero-trust approach in which any call needs to strictly follow the requirements for the API,” Sotnikov said. “If the API expects these particular parameters of these particular types within these particular ranges, that should be enforced.”
Access control considerations should include both types of concerns — restrictions on applications and users allowed to call an API, and restrictions on what information an API is allowed to provide.
One is: “‘Who is calling the API? Which component of the application? On behalf of which users?’” Sotnikov said. “The second one is: ‘What do they include in the call? What kind of parameters? What kind of payload?’”
Enforce Expected Application Behaviors
Even when developers are paying close attention to security, it’s difficult to account for all security vulnerabilities in an application.
“There’s an infinite number of different variations that you can use to call an API, and only a small fraction of those were actually in the minds of the developers when they were working on the application,” Sotnikov said.
That’s why security that focuses on what is permitted works better than security centered on what is not permitted. Sotnikov said it’s better to use allow lists rather than block lists to catch unforeseen vulnerabilities, and, once developers determine application behavior, they should create rules to ensure the application is actually behaving that way. For instance, if users are supposed to enter their phone numbers in an input, the application should not allow them to input letters.
“And so that means that, not only should they be testing within these scenarios that they had in mind, they should enforce these scenarios,” he said. “They should enforce those data contracts on the APIs.”
Consult the OWASP Top 10
Tackling web application security may seem daunting, but there are organizations that can help. The Open Web Application Security Project publishes a yearly updated list of top web application security risks, known as the OWASP Top 10.
Sotnikov, who helps curate a similar list for API security risks, said developers should pay the most attention to issues at the top of the OWASP ranking, because the list takes into account both impact and likelihood.
“We will try to look at how frequently we see a particular issue in the wild, and then how potentially impactful it is,” Sotnikov said. “And so when you start going through OWASP Top 10, start with the No. 1, and then go into No. 2, etc. Don’t start with No. 10.”
Following well-known and extensively researched guides such as the OWASP Top 10 helps developers focus their energy on preventing the most likely and most devastating types of attacks. For development teams that have a lot of responsibilities, that can mean gaining time back so they can build more robust applications.
Don’t Build Everything From Scratch
Russell from Planet Argon said an easy way to adhere to the OWASP Top 10 is by following standards and using existing tools rather than trying to code up everything from scratch.
“If you are opting to write the code from scratch to handle, say, authentication and security in your application … that would be something I would strongly discourage people from doing.”
“If you are opting to write the code from scratch to handle, say, authentication and security in your application, depending on your skill level, that would be something I would strongly discourage people from doing,” Russell said.
While some developers might find the challenge fun, the risk of introducing security vulnerabilities into the code is high. Russell said it’s better to use “a maintained and community-supported tool that has a lot more eyes on it and people trying to protect each other through participating in an open source project.”
“Yes, you can build your own security thing and only you would understand how it works,” he said. “But you would also need to make sure that you account for all of these 10 security risks within your own team, and you’re probably more likely to miss something.”
Using existing tools is also useful for mitigating newly discovered security vulnerabilities, because maintainers of the tool and others in the community could step in to quickly patch the vulnerability. Developers who build their own tools, meanwhile, may have security holes that go undetected for a long time.
“You may not be able to quickly patch that because you may not be aware of it, or because you’re not thinking about it until you actually get a hacker,” Russell said.
Stay Up to Date With Dependencies
Existing tools and libraries are only secure as long as they are kept up to date. Maintainers of those tools may be diligent about patching new security vulnerabilities, but that won’t help if developers are still using older versions. That’s why staying current on dependencies is important.
“If your team has not prioritized keeping those things updated, then you could have a hole sitting there,” Russell said.
That can be especially dangerous, because once the security flaw prompting the patch is made public, anyone can target older versions of the tool that still have the flaw. Applications that have not upgraded to the latest version could be more at risk than before.
“As long as you regularly keep those updated, then you’re less likely to have that pop up,” Russell said.
…but Mitigate Dependency Risks
That’s not to say dependencies themselves don’t carry risks. Jeffrey Martin, assistant vice president of product management at WhiteSource, said companies these days rely on countless dependencies, and that can cause problems if even a couple have security flaws or are not current with the latest patch.
WhiteSource helps companies track and audit their open-source dependencies by checking them against a database of known security vulnerabilities. Then it helps companies prioritize how to fix their vulnerabilities by evaluating risk.
“It’s literally not possible to get rid of them all. That’s why we call this risk management — not risk avoidance, not risk elimination.”
“It’s literally not possible to get rid of them all,” Martin said. “That’s why we call this risk management — not risk avoidance, not risk elimination.”
And staying current with dependencies may be easier said than done. The sheer number of open-source tools available makes it difficult to even figure out which ones a company’s code is using. And because each dependency is really just software that might have dependencies of its own, getting to the bottom of any of it is difficult.
“So I’m consuming one thing, but there’s this huge dependency tree underneath it, all the different components,” Martin said. “Sometimes these things are nested, like parent-child relationships, 50 times deep.”
Check Whether Security Tools Are Configured Correctly
No. 6 on the OWASP Top 10 list of security risks is security misconfiguration, which occurs when developers apply security protocols incorrectly. This often happens because many security standards, although widely used, can be complex.
“You can basically give somebody the entire keys of the kingdom,” Martin said. “And it’s the first thing everybody checks. It’s really not…