Web application attacks are on the rise, with a 69% increase from Q3 2016 to Q3 2017. There has been a large increase in attacks coming from the U.S., with an increase of more than 200% in U.S.-based attacks on web applications in just one year.

If you weren’t worried about security issues with your web applications before, you should be now. This article provides more details on why web application security should always be on your mind, and what you need to do to protect yourself, your business, and your users.

Why security issues with web apps are a growing concern

We are surrounded by web applications – even more than most of us realize. The trend of increasing use of web applications will continue, creating a bigger landscape for potential application security problems.

We interact with web applications in so many aspect of our lives. Even when we do not see them. They are used for Internet of Things (IoT) devices, smart appliances, and home voice assistants such as Amazon Alexa. Even what appear to be static websites, when built with application software such as WordPress and Drupal, are actually web applications.

IoT devices in particular are a growing concern. Shodan is a search engine for Internet-connected devices that lets hackers locate IoT devices that have not been patched with the latest security updates, or devices that have not reset the default administrator passwords. These devices are susceptible and can easily be located and taken over by hackers.

The shift to Agile methodologies, while a very good thing for improving the development and delivery of software, did open the door to more vulnerabilities in some cases where adoption happened rather quickly. Security sometimes took a back seat to Agile’s rapid release cycles. There is also a tendency to pay lip service to web application security, but there are no shortcuts. You may think about security upfront and then forget about it. Or you may neglect security until development is done and then quickly test the application against one or two dynamic tools. Neither approach effectively addresses the issue. These shortcuts create even more vulnerable web applications.

Hackers are constantly finding new ways to exploit vulnerabilities. Web application security should be one of the first things you think about when building a web application, and you should never stop thinking about it. A web application vulnerability report from 2017 found vulnerabilities in every web application that was analyzed, and 58% had at least one high-severity vulnerability.

The “set it and forget it” mentality is not enough, and there are no magic solutions. Relying solely on a web application firewall (WAF), for example, doesn’t cut it either – it’s an effective layer of defense, but by no means enough. Security has to be built in from the ground up.

Even if you build it right, launching a secure application is just the first step in the process. You cannot let this give you a false sense of security: security must be a part of ongoing maintenance, because your web application can become exposed to new threats after it is deployed.

The Equifax incident that compromised the personal data of over 143 million Americans is a perfect example of what can go wrong when you do not maintain web application security throughout the life of your application.

This does not mean you give up on web application security. It means you need a plan of attack to keep your application as secure as possible throughout the entire application lifecycle.

Test your readiness with these questions

Ask yourself these questions to expose weaknesses in your web application security strategy:

  • What is the cost to your business if you are hacked? Things to consider are:
    • Exposure of sensitive data (this is especially true in the healthcare and finance industries)
    • Losing customers and their trust
    • Negative press
    • Shareholder impact
    • Losing an edge to your competition
  • Is your source code secure?
    • Are your application developers trained in secure coding? Do they even know what “secure coding” means?
    • Has your code been scanned and reviewed for potential security vulnerabilities?
  • What third-party libraries have been bundled into your application, and do they contain any known vulnerabilities now? What about six months from now, when new vulnerabilities may have been discovered?
  • Do you have someone in-house who can patch a vulnerability quickly if required?
  • Is your web application still supported by the developers who created it?
  • Are you prepared to take your web application offline if a big enough security issue arises?
  • What is the risk of your application being attacked given its purpose and the sensitive nature of the data it may contain? Ask yourself if you’re a likely target.
  • How easy is it to hack your application? Have you had someone try to hack it?

Work with an outside application security consulting firm if you cannot answer these questions in-house.

What you should be doing for web application security

Web application security must be incorporated throughout the entire software development lifecycle (SDLC). It is important during development, at deployment, and for the entire life of the web application. You must constantly monitor your web application for security vulnerabilities. This includes monitoring and testing the technology used to build the application, the server it is running on, and any third-party libraries you may pull in from other sources.

WAFs can help by applying a set of rules that help protect against common attacks, such as cross-site scripting (XSS allows attackers to execute scripts in the visitor’s browser on behalf of a vulnerable website, unbeknownst to the user, redirecting them to malicious sites or subjecting them to other malicious activity) and SQL Injection (the insertion of a SQL query via the input data from the client to the application to read sensitive data from the database, modify database data, or perform other malicious activity) but they are not foolproof and are not enough as a standalone defense.

Application security testing tools must be used. One tool and/or one type of tool is not enough, because no one tool finds all the vulnerabilities. The following tools and processes should be evaluated for use:

  • Static Application Security Testing tools (SAST)
  • Dynamic Application Security Testing tools (DAST)
  • Interactive Application Security Testing tools (IAST)
  • Threat Modeling tools
  • Manual testing and code review

For a closer look at these tools and what each adds to application security testing, check out this resource from Code Dx

Multiple tools may seem overwhelming, but there are ways to streamline the process. Code Dx consolidates the results from multiple tools into one report through automated application vulnerability correlation. You get the benefits of comprehensive testing, but without the headache of siloed results riddled with duplicates.

You can’t protect your web application against every threat. Knowing some of the most common ones, and the ones currently on the rise, allows you to adjust your testing accordingly and prioritize known vulnerabilities.

Some of the top threats to look out for in 2018 include XSS, IoT vulnerabilities, and third-party plug-ins from CMS systems such as WordPress. More details on these threats are available here.

You need a formal security policy that covers the entire lifecycle of your web application. Resources specific to running a strong application security process alongside development are available to help guide you:

Establishing a policy and adhering to it will protect your web applications from security threats and vulnerabilities. The time and resources required for web application security are well worth the protection you get in return for your business and your customers.