10 Web Application
Security Threats and How
to Mitigate Them


StackHawk|March 1, 2023

Delve into 10 common web application security threats, their consequences, how web apps are vulnerable to them, and how to mitigate them.

Web application security is crucial to ensuring the safety and security of online systems and their users. As more and more daily activities and transactions move online, the importance of securing web applications becomes increasingly clear. Daily reports of breaches and always-changing security threats mean that security is a top priority for every organization.

In this article, we'll explore ten common web application security threats, the consequences of these threats, how web applications are vulnerable to them, and how to mitigate them.

10 Web Application Security Threats

Here are the ten common web application security threats we will cover in this article:

  1. SQL injection

  2. Cross-site scripting (XSS)

  3. Cross-site request forgery (CSRF)

  4. Insecure direct object references

  5. Remote code execution

  6. Insufficient logging and monitoring

  7. Insecure cryptographic storage

  8. Failure to restrict URL access

  9. Cross-origin resource sharing (CORS) misconfiguration

  10. Using components with known vulnerabilities

1. SQL Injection

A SQL injection attack is executed when an attacker injects malicious code into an application's database through user input fields. These types of attacks can accomplish many different things. Two of the most common outcomes include allowing the attacker to gain unauthorized access to sensitive data stored in the database. Depending on what data the database is storing, the attack could get access to passwords, financial information, and personal data. The second outcome could be the manipulation or deletion of data. For instance, a user may be able to execute a DROP TABLE or DROP DATABASE command.

You can mitigate this with the following steps:

  • Validate user input.

  • Use output encoding, which involves converting special characters such as < and > into their HTML entity equivalents, to prevent them from being interpreted as HTML code.

  • Use prepared statements, parameterized queries, or stored procedures instead of dynamic SQL whenever possible.

Most languages and frameworks have recommended ways of handling form input. By combing frontend and backend standards to prevent SQL injection from happening, your application can increase its security against this type of threat.

2. Cross-Site Scripting (XSS)

Cross-site scripting (XSS) attacks involve injecting malicious code or a malicious script into a website. The website then executes the script, allowing the attacker to steal sensitive user data, like session tokens and cookies, or perform other actions.

There are two main types of XSS attacks: reflective and stored. Reflective XSS attacks involve injecting malicious code into a website that is immediately executed. Stored XSS attacks involve injecting malicious code into a website that is stored and executed at a later time.

If successful, a cross-site scripting attack can result in the theft of user session IDs, website defacement, and redirection to malicious sites, thereby enabling phishing attacks.

You can mitigate this with the following steps:

  • Validate user input.

  • Use output encoding techniques.

  • Use auto-sanitization libraries such as OWASP AntiSamy.

  • Implement a content security policy.

Similar to the recommendation for SQL injection, using modern web frameworks generally tends to steer developers towards secure coding practices to avoid XSS and similar attacks.

3. Cross-Site Request Forgery (CSRF)

Cross-site request forgery (CSRF) is a type of attack that involves tricking a victim into performing an action on a website without their knowledge. This can be done by injecting a malicious link or form into a website that the victim is already authenticated on.

When the victim clicks the link or submits the form, the action is performed on their behalf, potentially leading to data loss or unauthorized access.

You can mitigate this with the following steps:

  • Leverage CSRF protections already built into the framework you are using, if applicable.

  • Use CSRF tokens. These are unique, randomized values associated with a user's session and are included in forms and links to verify the authenticity of the request.

  • Use SameSite cookies. These are a type of cookie that is only sent with requests to the same origin as the cookie's creation. This can help prevent attackers from being able to send requests on behalf of a victim, as they would not have access to the victim's SameSite cookies.

4. Insecure Direct Object References (IDOR)

Insecure Direct Object References, or IDOR, occur when an application exposes direct object references, such as URLs or database keys, that allow attackers to access restricted data by manipulating these references.

For example, an application may allow users to access their account information by entering their account number in a URL, such as "www.example.com/account/123". An attacker could potentially access other users' account information by changing the account number in the URL.

You can mitigate this with the following steps:

  • Implement proper access controls and session management. This involves setting up mechanisms to ensure that only authorized users have access to certain resources or data. The OWASP cheat sheets on authorization and authentication can be helpful resources for reviewing best practices in these areas.

  • Validate user input. To help prevent attackers from manipulating direct object references to access-restricted data, ensure that user input is the correct type, length, and format.

  • Avoid using predictable references. Instead, consider using globally unique identifiers (GUIDs) to prevent attackers from guessing the direct object references they need to access restricted data.

As noted in the mitigation steps above, IDOR-based vulnerabilities don’t occur on their own. These vulnerabilities must be coupled with other vulnerabilities to become an effective attack vector.

5. Remote Code Execution (RCE)

Remote Code Execution (RCE) attacks allow attackers to execute arbitrary code on a server, potentially leading to full system compromise and unauthorized access to sensitive data.

RCE attacks can occur through a variety of means, such as exploiting vulnerabilities in code libraries or injecting malicious code through user input fields.

A successful RCE attack can have several consequences. These include Denial of Service (DoS) attacks, exposure of sensitive data, illicit cryptocurrency mining, and execution of malware. In some cases, a successful RCE attack can even give full control over the compromised machine to the attacker.

public class WebConfig implements WebMvcConfigurer {
   public void addCorsMappings(CorsRegistry registry) {
               .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")

StackHawk  |  March 1, 2023

More StackHawk

Add AppSec to Your CircleCI Pipeline With the StackHawk Orb

Add AppSec to Your CircleCI Pipeline With the StackHawk Orb

Application Security is Broken. Here is How We Intend to Fix It.

Application Security is Broken. Here is How We Intend to Fix It.

Using StackHawk in GitLab Know Before You Go (Live)

Using StackHawk in GitLab Know Before You Go (Live)