The 10 Most Common Web App Security Vulnerabilities

Dennis

Agile Product Development

Close Banner

Free Template & Financial Spreadsheet

Create your SaaS business plan

Sign Up

Security is a never-ending battle for CIOs, CTOs, and anyone who runs a web application. Your security program must be vigilant, defensive, and proactive. You should assume you are vulnerable at all times and plan for the inevitable data breach.

To help you avoid security pitfalls, we’ve put together this list of the most common security vulnerabilities along with some recommendations on how to avoid them. Speak with your development team (whether they work in-house or you’ve hired an outside development shop) about whether they’ve planned for these potential issues.

1. Injection Flaws

An SQL injection is when a malicious party attempts to insert code into your application with hopes of accessing your database. If they manage to sneak in, they can create, read, update, or delete data stored in your database.

Security VulnerabilitiesImage: Ishara Abeythissa

This is one of most common types of attack against websites and web apps because of the myriad of ways we let users interact with our systems. Anywhere a user inputs data (like a submission form or a search box) is an opportunity for an SQL injection.

2. Sensitive Data Exposure

Sensitive data should be encrypted at all times, whether in transit or at rest. There are no exceptions to this rule these days, yet many organizations fail to encrypt their data because "No one will want to steal this."

It's critical that your data remain encrypted all the time using a strong crypto/hashing algorithm. Use HTTPS with a proper certificate. Session IDs and sensitive data should never travel in the URL. Sensitive cookies should be secured as well. If you don’t need to store something, reduce your exposure by removing it (like credit card data).

Further, encryption Keys should not be stored in the same place as protected data. That's like leaving the key in your lock. Your encryption keys should always be separate and never lost.

3. Missing Function Level Access Control

This is an authorization failure issue. It occurs when server-side authorization is misconfigured, broken, or missing (often because the developer assumed the function was safe because it couldn’t be generated by the UI). This can leave the back-end of your application open to attacks. Prevent these issues by running authorization on every function. No exceptions.

4. Cross-Site Request Forgery

Cross-site request forgeries (often abbreviated as simply CSRF) use social engineering to trick real users into clicking a special link or performing some action that gives the malicious party control of their session. Once the attacker has an authenticated session, they can perform changes and steal or modify data.

This primarily affects applications without proper dual authentication or cross-site tokens. Users who don’t have knowledge or experience with social engineering techniques are vulnerable.

You can prevent CSRF attacks by using secret tokens or cookies. This can help with authenticating real requests vs. malicious ones. It also helps to stop using GET requests and use POST requests only so any information stored in the URL remains uncompromised.

5. Using Components with Known Vulnerabilities

It’s not uncommon to use plugins or third-party applications with code you don’t know intimately. This unfamiliar code may create security issues that you aren’t aware of. For instance, a simple lead generation plugin might allow malicious parties into your database where they can then access customer financial information.

Your first step is to consult the National Vulnerability Database to review a list of known third-party vulnerabilities.This will help you identify problems before they creep up.

After that you’ll have to do some due diligence and auditing to investigate that safety of the third-party code. Speak with the developers about how they developed their application and how/when they patch security flaws.

(Oh, and don’t use random code you find on GitHub.)

6. Security Misconfiguration

Web applications are often misconfigured due to lack of maintenance, which creates a number of opportunities for malicious parties to attack. This might include unused pages, revealing error handling information, running outdated software, using unnecessary services, unpatched flaws, unprotected files, or running software in debug mode.

You can prevent security configuration vulnerabilities by using a deployment protocol to develop and deploy updates. This will keep your applications current and prevent attacks. If you find a security misconfiguration, it’s very important to run a security audit to check for breaches.

7. Broken Authentication

Authentication helps applications validate users. If your authentication doesn’t work properly, your app might allow unintended parties to have the same permissions as valid users. Depending on your permission structure, this could be quite damaging.

The best way to avoid this web security vulnerability is to use a framework rather than trying to create your own authentication code. You should also use multi-factor authentication to verify the correct user, require strong passwords, and configure timeouts properly.

8. Insecure Direct Object References

A direct object reference means that an internal object (like a database key or file) is exposed to the user. This is normally fine if the user should have access to that object .But if the authorization is broken or unenforced, an attacker can do things they normally couldn’t.

For instance, let’s say a button allows a user to download files using a CGI parameter to specify the file name, but the original developer failed to include authorization. An attacker could use this flaw to download any file in the system.

The solution is to perform user authorization properly all the time. Furthermore, you should store data internally rather than relying on it being passed in a discernible manner. Session variables in most frameworks are helpful here.

9. Cross-Site Scripting XSS

Cross-site scripting is the process of injecting code into sites to attack users’ web browsers. The attacker will insert code through a link and use social engineering to convince someone with authorization to click it, thus running the script through their authorization. This is common when inputs are unsanitized and can be fixed by sanitizing them and validating user inputs.

10. Unvalidated Redirects and Forwards

This is yet another input manipulation vulnerability. An attacker might manipulate a URL to redirect users to a malicious site that steals their personal information using other hacks or social engineering.

You can prevent unvalidated redirects and forwards by simply eliminating redirects. They are seldom necessary and there are other solutions. You could also create a static list of valid redirect locations. At the minimum, don’t allow users to input their own URLs.

Identify Security Flaws with Penetration Testing

Now that we’ve covered the 10 most common web app security vulnerabilities, you’re probably wondering how to tell if any apply to you. You can gauge your security profile with a penetration test.

Penetration testing is a simulated cyber attack against your application for exploitable vulnerabilities. You - or a hired security consultant - attempt to breach your application systems to uncover opportunities that hackers might use to access your app. Use the insights from the test to refine your code and adjust your security policies.

A penetration test usually involves five phases: Planning, scanning, gaining access, maintaining access, and analysis and web application firewall (WAF) configuration. A good security program should run a cycle of these phases regularly.

Security VulnerabilitiesImage: Imperva

Key Takeaway

If you aren’t a software engineer, you may not understand how these security vulnerabilities work, but it’s important to understand what they are and how they might affect your application. Work with your security team or developers to ensure you aren’t open to any of them.

Close Banner

Building a product?

Discover the DevSquad Difference

Learn More