Join Us on Apr 30: Unveiling Parasoft C/C++test CT for Continuous Testing & Compliance Excellence | Register Now

Sensitive Data Exposure OWASP in 2024: The Complete Guide

Parasoft cube logo 300x300
November 1, 2023
8 min read

Open Web Application Security Project (OWASP) has helped to provide answers through training and forums to critical IT issues. Read through to find the answers to pressing OWASP Top 10 and web application security questions.

Let’s delve into answers to pressing OWASP Top 10 and web application security questions.

In software development, testing for software weaknesses that expose security vulnerabilities is routine. Web application security, however, has become more complex given the growing use of application programming interfaces (APIs) that increase an attack surface for applications. DevSecOps, AppSec, and application development teams are now seeking practices to mitigate the security risks, reduce the attack surface, and prevent data exposures caused by web application vulnerabilities.

There’s been an onslaught of web application attacks on organizations and it’s steadily increasing. Web applications are known to use vulnerable third-party dependencies. The accessibility and reachability of these vulnerable components have software dependencies that create security risks and expose attack surfaces in web applications. It makes it easy for attackers to create serious disruptions, steal, or tamper with personal information such as credit card data, cause a denial of service, or simply hold the data for ransom. Unfortunately, no business, big or small, gets a pass when it comes to these cybersecurity challenges.

Attackers seek out vulnerabilities and use them to compromise the application’s security. Web application vulnerabilities can be software weaknesses in the application code or misconfiguration issues in web based applications. These vulnerabilities can be the result of:

  • No validation or sanitizing form inputs
  • Misconfigured web servers
  • Application design flaws
  • Poorly implemented and designed authentication mechanisms
  • Application programming interfaces (APIs)

Web application attacks are one the most prevalent attack vectors for cybersecurity incidents and data breaches, as indicated in Verizon’s 2021 Data Breach Investigation Report (DBIR). They require sound preventive and remediation strategies like patching and threat modeling to mitigate.

What Is Sensitive Data Exposure?

Although it may seem obvious, sensitive data today represents a significant part of the information we share online. Exposure means that personal identifying information (PII) is available to attackers who may use it for profit, fraud, or identity theft. PII includes names, addresses, email addresses, phone numbers, and even more critical data like social security numbers and bank and credit card account information. Meanwhile, sensitive business data may expose trade secrets or business plans.

Sensitive data exposure, as outlined in the OWASP Top Ten, is a security vulnerability where an application inadvertently reveals confidential or sensitive information, such as personal user data, financial records, or login credentials, to unauthorized individuals or systems. This exposure can occur due to inadequate data protection measures, weak encryption, or improper access controls, potentially leading to data breaches and compromising user privacy and security.

What’s a Good Starting Point for Web Application Security?

The Open Web Application Security Project (OWASP) is advancing application security (AppSec) practices globally through community engagement, training, and awareness. OWASP Top 10 is the reference standard for organizations that are proactively protecting web applications from security threats to reduce risks. OWASP Top 10 compliance validation is a good first step when attempting to change and improve the software development culture in your organization because of the education and awareness OWASP provides about application threats and things that can go wrong if good coding and application security practices are not followed.

Another resource for improving web application security is the Common Vulnerabilities and Exposures (CVE) system provides a reference to known information-security vulnerabilities and exposures. It allows everyone to keep track of publicly known vulnerabilities and provides telemetry on real world exploits that can be codified in software development practices and threat modeling activities to build security-in.

Web application scanning or testing (such as SAST, DAST, IAST, SCA) is a good foundation for security teams. A web application firewall (WAF) is yet another tool for filtering, monitoring, and blocking web application attacks identified in the OWASP Top 10.

What Is OWASP?

OWASP is an international nonprofit organization dedicated to improving web application security. Its importance lies in its role as a leader in web application security achieved through resources, tools, and guidelines for identifying and mitigating security vulnerabilities. OWASP helps make the web more secure by raising awareness and facilitating best practices.

OWASP Top 10 Web Application Security Risks

The OWASP Top 10 is a list of the most known vulnerabilities and dangerous security risks for web applications. It’s updated periodically to stay ahead of increasing and evolving threats. Developers widely recognize the OWASP Top Ten list as the guideline for web app security.

What Are OWASP Top 10 Attacks & Which Vulnerabilities Are Part of the OWASP Top 10 Today?

OWASP provides documentation for the Top 10 list, with a website dedicated to each vulnerability, that outlines the threat, risk, and mitigation strategies. The site describes what each vulnerability is and provides a risk score, which is used to help prioritize and triage possible vulnerabilities.

The following vulnerabilities A1-A10 comprise the OWASP Top 10, last updated in 2021.

1. A01:2021—Broken Access Control

Topping the list as the most serious web application security risk, broken access control had 34 CWEs mapped to it. That’s more than occurrences in applications than any other category. A web application’s access control model is closely tied to the content and functions that the site provides. If it’s not configured properly, hackers can gain access to sensitive files and deface the site.

2. A02:2021—Cryptographic Failures

Cryptanalytic software involves different software programs used to crack encryptions. Formally called Sensitive Data Exposure, a cryptographic failure means the information that is supposed to be protected from untrusted sources has been disclosed to attackers. Hackers can then access information such as credit card processor data or any other authentication credentials.

3. A03:2021—Injection

When an attacker uses malicious SQL code to manipulate a backend database, so it reveals sensitive information it’s called an injection attack. Injection flaws, such as NoSQL, OS, LDAP, and SQL injection, occur when untrusted data is sent to an interpreter as part of a command or query.

Cross-Site Scripting (XSS) attacks are another type of injection. Malicious scripts are injected into otherwise benign and trusted websites that can rewrite the content of the HTML page.

Sever-Side Request Forgery (SSRF) is a type of attack that can occur when a hacker can not only view unauthorized lists, delete tables and have unauthorized administrative access but also perform remote code execution from the back-end server of a vulnerable web application.

4. A04:2021—Insecure Design

This is a new category for 2021 and the focus is on the risks related to design flaws. More threat modeling, secure design patterns and principles, and reference architectures are needed to protect against insecure designs for web pages.

This is an important addition because developers need to be aware of how design and architectural concepts need to be configured and implemented correctly in code. Implementing design and architectural concepts incorrectly in code can create security vulnerabilities.

5. A05:2021—Security Misconfiguration

XML External Entities attacks have been rolled into security misconfiguration this year. It’s an increasing threat because of more shifts in software configurations.

6. A06:2021—Vulnerable and Outdated Components

Previously titled Using Components with Known Vulnerabilities, this category represents a known issue that OWASP experts have found that many continue to struggle to test for risk assessment.

Many security issues have been attributed to outdated third-party software components. A growing concern further compounds this that the time to exploit is shrinking and organizations are not patching or remediating vulnerabilities fast enough.

7. A07:2021—Identification and Authentication Failures

Authentication vulnerabilities as a category has dropped from the second position in the top ten because the increased availability of standardized frameworks seems to be helping. It was previously called Broken Authentication vulnerability because it can result in a denial of service when user accounts aren’t able to be authenticated. Multi-factor authentication isn’t deployed in most instances. It now includes CWEs that are more related to identification failures.

8. A08:2021—Software and Data Integrity Failures

As a new category for 2021, this focuses on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. A8:2017—Insecure Deserialization is now a part of this larger category.

The growing concerns over recent attacks associated with the SolarWinds breach and securing the build environment increase the importance of this threat. Software integrity has been called out specifically in the Executive Order on Cybersecurity, section 4.

9. A09:2021—Security Logging and Monitoring Failures (Formerly A10 OWASP Top 10 2017)

This category has been expanded to include more types of failures that can directly impact visibility, incident alerting, and forensics.

10. A10:2021—Server-Side Request Forgery

The data show there is a low incidence rate for this category that has just been added to the Top 10.

OWASP Compliance With SAST

Because cyberattacks are constantly in the news, you cannot afford for your web applications to fall prey to attackers because of security vulnerabilities that can be avoided. Static application security testing (SAST), or static code analysis, allows your organization to perform automated testing and analysis of your web application source code.

SAST is the process of parsing through the code to check for software weaknesses that could expose security vulnerabilities in web applications. SAST tools don’t need a running application to perform an analysis. SAST can analyze code in real time to let you know about OWASP Top 10 violations sooner rather than later.

A good practice for reducing security vulnerabilities is to embed the guidance from the OWASP Top 10 into your software development activities from the start and use static application security testing to validate compliance. By incorporating static application security testing early in the development process, you can identify security weaknesses and any application vulnerability—when they are the easiest and least expensive to fix while meeting your security compliance mandates.

Dealing with the output of security tools can be overwhelming so you’ll want to look for automated SAST tools that incorporate a few security industry risk models. OWASP is a good place to start because it addresses the most important issues and vulnerabilities. You can improve upon that once your team feels they’ve got it under control. The expanded secure coding standards listed in the table below will help you broaden your security and set you up for future success.

Secure Coding Standards

The following are common secure coding standards that organizations can adapt and adopt to improve their security posture and prevent many of the software weaknesses that lead to security vulnerabilities.

1. CERT (Computer Emergency Response Team)

Guidelines for various languages to help developers avoid errors during coding and implementation, and also detect low-level errors in design.

2. OWASP Top Ten

Web application and software developers use these standards to identify and remedy high-security risks in web applications.

3. CWE (Common Weakness Enumeration)

This is a category system that helps developers identify vulnerabilities and weaknesses in software and assists them in understanding software flaws. Developers also use the system to develop tools to fix and prevent flaws.

4. DISA Application Security and Development STIGS

Helps managers, designers, developers, and system administrators in developing and maintaining security controls in applications and application development.

Automated SAST solutions like Parasoft offer an updated compliance pack per the OWASP updates. The new rules become checkers to help developers enforce the new secure coding practices, as shown in the image below, for popular programming languages like Java, C/C++, .NET, Python). This helps guide developers by eliminating the top ten risks that have been identified by OWASP. Additionally, a feature like automated prioritization leveraging AI/ML can take the guesswork out of manual triage.

Parasoft Checker/Rulers Support for OWASP Top 10

The image below displays Parasoft’s checkers/rules support for the latest version of the OWASP Top 10 2021.

Screenshot of Parasoft's checkers/rules support for the updated version of the OWASP Top 10 2021

OWASP Top 10 API Security Risks

The OWASP Top 10 API security risks is a list of common security issues specifically related to APIs (application programming interfaces) in web applications. These vulnerabilities are often exploited to compromise data and system integrity when APIs are involved.

The main difference between the OWASP Top 10 and the OWASP Top 10 API vulnerabilities is a focus on the use of APIs, which may expose data or functionality, and are prevalent in modern web and mobile applications. The reason for the separate emphasis on APIs by OWASP is the fact that APIs make up a majority of cloud security attacks. According to the 2021 IBM Security X-Force Cloud Threat Landscape Report, two-thirds of security incidents in the cloud last year involved improperly configured APIs. However, the underlying software weaknesses are aligned with those from the web applications. From a SAST and DAST tools perspective, the issues detected are similar although the mapping will change.

SAST vs. DAST

Another weapon in your web application security toolbox is dynamic application security testing (DAST). With DAST, malicious attacks and other external behaviors are stimulated by searching for ways to exploit security vulnerabilities during runtime or black-box testing.

So, while SAST analyses every line of code without running the application, with DAST you’ll need to execute the application before it can start scanning for vulnerabilities, which is as soon as you have running software.

Deciding about static and dynamic code analysis for your organization depends on many variables. Read our blog post about SAST where there’s a great side-by-side comparison of the two tools.

Getting Started With a Static Analysis Tool