13 Best Practices for Improving Web Application Security

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.

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.

More on Security:What You Need to Know About Regression Testing

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.

More on EngineeringStop Talking About ‘Technical Debt’

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 any different from seeing if somebody’s luggage has the password 1-1-1.”

An example of this type of mistake is forgetting to change the default account that a security tool comes with, Martin said. If attackers know the tool’s default, they could easily get into the application.

But there are less obvious ways to misconfigure security as well. Setting up authentication for web applications, for example, requires many customizations and configurations. Even a few mistakes can result in insecure applications.

The best defense against security misconfigurations is carefully following documentation when setting up security tools, and relying on other developers to catch mistakes. Development teams that have code review practices in place might prevent misconfigurations by detecting them before they get to production.

Set Up DevSecOps

There are many tools that help developers build applications more securely — some are even built into popular IDEs, Sotnikov said. But rather than leaving it up to the developers to decide whether to use these tools, companies can build them into their development lifecycles.

“Companies should try to enforce that — so not just hope that the developers would use that, but also implement DevSecOps,” Sotnikov said.

DevSecOps is DevOps but with security as an additional integral part of the automated CI/CD processes.

“So within their CI/CD pipeline, any code changes that developers make are not only compiled and not tested for functionality, but also for security,” Sotnikov said.

Application security is more robust when it isn’t just a once-a-year audit, but instead a regular, continuous process.

“So not just a one-time snapshot review, but establish an automated process in which any change and any new piece of functionality get tested for security,” he said.

Practice Good Password Hygiene

Good habits for personal online security also apply to web application security. Russell said developers who are careless about password management may also put their applications at risk. Web applications often require passwords and secrets to protected services, and vulnerabilities can occur if any are compromised.

“There’s still a lot of clients and people out there who will just happily post their username and password in an email and send that to you — and that’s a no-no,” Russell said. “Rather than relying on email or pasting those passwords and credentials in a Slack message, we’re always trying to advocate they use a temporary secret-type tool, like 1Password or LastPass.”

Password manager tools give companies finer control over who has access to which passwords, and also prevent sensitive passwords from getting out by being forwarded in an email or on a slip of paper.

“It’s not uncommon for us to inherit software projects that have API keys that have been the same API key for six-plus years.”

It’s also important to occasionally change old passwords, because the older a password is, the more likely it is that others know it.

“It’s not uncommon for us to inherit software projects that have API keys that have been the same API key for six-plus years, that have gone through multiple freelance developers that all had access to that key — nobody had ever changed it,” Russell said. “And so, in theory, former developers might still have that, which means they could access the same data that your applications access, which might mean they could access it and modify it or delete it.”

Bring in the Experts

Sometimes it can be helpful to get fresh eyes on a company’s security practices. Some companies hire penetration testers to test an application’s security robustness.

“Having it conducted by a different team, sometimes it’s helpful,” Russell said. “There’s a lot of software developers that can put enough measures in place to hopefully protect the application and cross their fingers. But I think what most teams probably lack is having anyone with experience making sense of whether or not a hack has occurred, and to what extent.... That’s not something you’re going to learn in the first few years of being a software developer.”

Sotnikov said external security experts can’t be expected to manually review an application’s entire codebase, but they can help ensure companies have the right automated security practices in place.

“I think what external consultants or internal champions can do and should do is try to establish security processes within the company, those automated enforcement points as part of the DevSecOps process,” Sotnikov said.

Stay in the Loop

Software development and security are constantly changing — ultimately, the best protection against security vulnerabilities is educating oneself and keeping up with changes in the field.

Developers can learn about emerging best practices by reading security and development blogs, subscribing to newsletters and talking to other developers.

“New attacks emerge, new technologies emerge,” Sotnikov said. “Get educated, try to stay up to speed. It’s all very much a changing area.”

More on Software DevelopmentTime Estimation Debates Aren’t Really About Estimates