Table of Contents

1. SQL Injection.........................................................................................................................................3
2. Cross-Site Scripting (XSS)....................................................................................................................4
3. Cross-Site Request Forgery (CSRF)......................................................................................................4
4. Insecure Direct Object References (IDOR)...........................................................................................5
5. Remote Code Execution (RCE).............................................................................................................6
6. Insufficient Logging and Monitoring.....................................................................................................7
7. Insecure Cryptographic Storage.............................................................................................................8
8. Failure to Restrict URL Access / Broken Access Control......................................................................9
9. Cross-Origin Resource Sharing (CORS) Misconfiguration...................................................................9
10. Using Components with Known Vulnerabilities................................................................................10

Web Application
Security
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.
You can mitigate this with the following steps:
•Sanitize user input.
•Implement secure memory management. RCE attackers can
potentially take advantage of memory management flaws such as
buffer overflows. Conducting regular security vulnerability scans
on your applications can help you identify buffer overflow and
memory-related vulnerabilities that an attacker could exploit.
•Always keep your operating system and your third-party
software up to date to ensure that you have the latest security
patches.
•Limit the attacker's ability to move through a network y
implementing network segmentation, access management, and a
zero-trust security strategy.
RCE attacks have been a major source of breaches in the last few
years, many leading to worldwide security emergencies. One that
many people will remember is the Log4j fiasco discovered in 2021
where multiple RCE vulnerabilities were discovered in Log4j. These RCE
vulnerabilities allowed attackers to exploit vulnerable applications to
execute Cryptojacking attacks and other malware on compromised
servers.

6. Insufficient Logging and Monitoring

Insufficient logging and monitoring refer to a lack of proper logging
and monitoring processes in place to detect and respond to security
threats. This can allow attackers to go unnoticed and continue to
compromise the system, potentially leading to data loss and financial
loss.
It’s also important to be aware of what is being logged. If secure
information, such as credit card numbers or passwords, are being
written to logs, attackers who gain access to the logs could use this
information maliciously. Fraudulent credit card charges or
unauthorized access to a system could be easily executed.
You can mitigate this with the following steps:
•Enable logging for key events and actions in your application
and monitor logs regularly.
•Use log analysis tools. These can help automate the process of
reviewing logs and identify potential security issues or anomalies
more quickly and efficiently.
•Set up alerting systems to notify administrators of any potential
security issues in real time, allowing them to respond more
quickly to potential threats.
•Ensure that sensitive information is either not included in logs or
is properly masked.
7. Insecure Cryptographic Storage
Insecure cryptographic storage refers to the improper handling of
cryptographic keys, such as storing them in plain text or using weak
keys. This can allow attackers to gain access to sensitive data through
compromised cryptographic keys.
You can mitigate this with the following steps:
•Use strong cryptographic algorithms, such as AES or RSA, to
secure stored data.
•Implement key management best practices, such as regularly
rotating keys and securely storing them, to help prevent
unauthorized access to encrypted data.
•Use secure storage solutions, such as hardware security modules
or encrypted storage devices, to help further protect encrypted
data.
One suggestion is also to audit the data that you need to store in an
encrypted state. The best way to protect data is to simply not store it
at all. If sensitive data is being stored without need, it may be best to
forego the storage of this data to lessen the data that potential
attackers have access to.

8. Failure to Restrict URL Access / Broken Access Control

Failure to restrict URL access refers to a lack of proper access controls
that allow unauthorized users to access restricted pages and
resources. This can allow attackers to access sensitive data and
potentially compromise the system.
This security threat is mostly similar and related to the IDOR
vulnerabilities we discussed earlier. The core differentiating factor
between the two is that IDOR tends to give the attacker access to
information in the database, while failure to restrict URL access allows
the attacker access to special functions and features that should not
be available to any typical user.
You can mitigate this with the following steps:
•Implement proper access controls by setting up authentication
and authorization processes to ensure that only authorized users
have access to certain resources or functions.
•Use role-based authorization. The enforcement mechanism
should deny all access by default, requiring explicit grants to
specific users and roles for access to every page.
•Implement adequate authorization measures at relevant stages
of user web app use.
Many routing libraries and routing mechanisms built into modern web
frameworks tend to protect against this by default. By making sure
that the application routing is set up correctly, these types of
vulnerabilities can be completely avoided.

9. Cross-Origin Resource Sharing (CORS) Misconfiguration

Cross-Origin Resource Sharing (CORS) is a security feature that allows
a web server to specify which domains are allowed to access its
resources. However, if CORS is misconfigured, it can allow attackers to
access restricted resources from a different origin. This could
potentially expose data through services that can be used without
authorization.
You can mitigate this with the following steps:
•Properly configure CORS headers.
•Use CORS libraries that provide an easy-to-use interface for
configuring CORS headers to help you configure CORS properly.
Many server-side frameworks and platforms can aid developers in
properly configuring CORS for their services. Developers should be
aware of how CORS can be configured in the framework of their
choosing. One common reason for CORS security misconfiguration is
that when developers are creating applications locally they will set an
entirely open CORS policy for easier development. Ensuring that these
policies do not get checked into production code is crucial.

10. Using Components with Known Vulnerabilities

Using components with known vulnerabilities refers to the use of
outdated code libraries, frameworks, or other components with known
vulnerabilities.
Many websites today are built using complex components, which can
make it difficult for development teams to understand their internal
workings. This can create potential vulnerabilities if a component
contains known security issues that are not properly addressed.
You can mitigate this with the following steps:
•Keep track of component versions. You can address any
vulnerabilities by regularly checking for updates and staying up
to date with the latest versions of components.
•Use security scanners to help you identify known vulnerabilities
in components and alert developers to potential issues.