Posted on

OWASP 2022- Latest

Open Web Application Security Project(OWASP)

The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web.

Tools and Resources
Community and Networking
Education & Training

The Latest List of OWASP Top 10 Vulnerabilities and Web Application Security Risks

Broken Access Control
Cryptographic Failures
Insecure Design
Security Misconfiguration
Vulnerable and Outdated Components
Identification and Authentication Failures
Software and Data Integrity Failures
Security Logging and Monitoring Failures
Server-Side Request Forgery



Website security access controls should limit visitor access to only those pages or sections needed by that type of user. For example, administrators of an ecommerce site need to be able to add new links or add promotions. These functions should not be accessible for other types of visitors.

Developers must be encouraged to internalize “security first” discipline to avoid pitfalls, such as content management systems (CMS) that generate all-access permission by default (up to and including admin-level access). Broken access control can give website visitors access to admin panels, servers, databases, and other business-critical applications. In fact, this OWASP Top 10 threat could even be used to redirect browsers to other targeted URLs.

Broken Access Controls Remediation
Broken access control vulnerability can be addressed in a number of ways in OWASP

Adopt a least privileged approach so that each role is granted the lowest level of access required to perform its tasks.
Delete accounts that are no longer needed or active.
Audit activity on servers and websites so that you are aware of who is doing what (and when).
If there are multiple access points, disable the ones that are not required at that moment.
Keep servers lean by shutting down unnecessary services.


Data in transit and at rest — such as passwords, credit card numbers, health records, personal information, and business secrets — require extra protection due to the potential for cryptographic failures (sensitive data exposures). This is especially true if the data falls under any of the privacy laws such as GDPR, CCPA, and others. Is any data is sent in plain text? Are there any outdated or insecure cryptographic algorithms or protocols in use by default or in older code? Is it possible that default crypto keys are being utilized, that weak crypto keys are being generated and re-used, or that proper key management and rotation are being overlooked? Is it possible to check crypto keys into source code repositories? Is encryption not enforced, and is the received data encrypted?

Cryptographic Failures Remediation

On forms that collect data, turn off autocomplete.
Reduce/minimize the size of the data surface area.
Encrypt data while it is in transit and at rest.
Use the most up-to-date encryption techniques.
Disable caching on data-collecting forms.
Use Strong adaptive and salted hashing functions when saving passwords.


Injection vulnerabilities can occur when a query or command is used to insert untrusted data into the interpreter via SQL, OS, NoSQL, or LDAP injection. The hostile data injected through this attack vector tricks the interpreter to make the application do something it was not designed for, such as generating unintended commands or accessing data without proper authentication.

Any application that accepts parameters as input can be susceptible to injection attacks. The level of the threat is highly correlated with the thoroughness of the application’s input validation measures.

Injection Remediation


Injection attacks can be prevented by any combination of the following approaches:

Segregate commands from data to avoid exposure to attacks that replace data with unintended command execution.
Code SQL queries with parameters rather than structuring the command from user input content only. These are called parameterized queries or prepared statements.
Eliminate the interpreter altogether through the use of a safe API.
Implement positive server-side validation as well as an intrusion detection system that spots suspicious client-side behaviors.


Insecure design is a wide term that encompasses a variety of flaws and is defined as “missing or poor control design.” Threat modeling, secure design patterns, and reference architectures are among the new categories for 2021, with a demand for increasing the usage of threat modeling, safe design patterns, and reference architectures. As a community, we must move beyond “shift left” coding to pre-code tasks that are important to the Secure by Design principles.

Insecure Design Remediation

To help analyze and build security and privacy-related measures, establish and use a safe development lifecycle with AppSec professionals.
Create and use a library of secure design patterns or components that are ready to use.
Use threat modeling for crucial authentication, access control, business logic, and key flows.
User stories should include security language and controls.
Integrate plausibility checks into your application at each level (from frontend to backend).
To ensure that all important flows are resistant to the threat model, write unit and integration tests. Make a list of use-cases and misuse-cases for each tier of your app.
Depending on the exposure and protection requirements, divide tier tiers on the system and network layers.
Limit user and service resource consumption.



Gartner estimates that up to 95% of cloud breaches are the result of human errors. Security setting misconfigurations are one of the prime drivers of that statistic, with OWASP noting that, of the top ten, this vulnerability is the most common. There are many types of misconfiguration that expose the company to cybersecurity risk, including:

Accepting default settings that are insecure
Overly accessible cloud storage resources
Incomplete configurations
Misconfigured HTTP headers
Verbose error messages that contain sensitive information

Security Misconfiguration Remediation

Security misconfigurations can strike almost anywhere in the environment, including network-attached devices, databases, web and application servers, and containers. The following practices can help maintain a well-configured environment:

Use templates to deploy development, test, and production environments that are preconfigured to meet the organization’s security policies.
Leverage segmented application architectures that minimize the risk from an insecurely configured element; maintain a library of properly configured container images.
Deploy minimal platforms and remove unused features and services.
Continuously monitor cloud resources, applications, and servers for security misconfigurations and remediate detected issues in real time, using automated workflows wherever possible.


Modern distributed web applications often incorporate open source components such as libraries and frameworks. Any component with a known vulnerability becomes a weak link that can impact the security of the entire application.

Although the use of open source components with known vulnerabilities ranks low in terms of security problem severity, it is #1 when ranking the OWASP Top 10 by how often a vulnerability was the root cause of an actual data breach.

Vulnerable and Outdated Components Remediation

The most effective defense is continuous scanning of all code components for known vulnerabilities and deploying a patch or other remedy as quickly as possible when a vulnerability is detected. There are a number of best practices that enhance the effectiveness of this line of defense:

All components integrated into the company’s frameworks should be under configuration management.
The scanner must be able to automatically discover all the components to be monitored.
Scanning should be conducted against a comprehensive vulnerability database that is enriched with threat intelligence data.
The patch management workflows for identifying, testing, and deploying the right patch should be as automated as possible in order to reduce to a minimum the operational risk associated with patching.


When applications incorrectly execute functions related to session management or user authentication, intruders may be able to compromise passwords, security keys, or session tokens and permanently or temporarily assume the identities and permissions of other users. This vulnerability poses a grave threat to the security of the application and the resources it accesses and can also severely compromise other assets connected to the same network.

Authentication Remediation

The key OWASP best practice recommendations to mitigate broken authentication vulnerabilities are:

Implement multi-factor authentication.
Do not deploy with default credentials, especially for users with admin privileges.
Enforce strong passwords.
Carefully monitor failed login attempts.
Use a secure session manager that generates random, time-limited session IDs. Never include session IDs in URLs.


Code and infrastructure that do not guard against integrity violations are referred to as software and data integrity failures. A program that uses plugins, libraries, or modules from untrusted sources, repositories, or content delivery networks (CDNs) is an example of this. Unauthorized access, malicious code, or system compromise can all be risks of an unsecured CI/CD pipeline. Finally, many programs now have auto-update capabilities that allow updates to be obtained without necessary integrity checks and applied to previously trusted applications. Attackers could potentially distribute and run their own updates across all systems with this functionality.

Software and Data Integrity Failures Remediation

Use digital signatures, or other similar measures, to ensure that the program or data is genuine and has not been tampered with.
To reduce the risk of harmful code or configuration being introduced into your development pipeline, make sure there is a review procedure in place for code and configuration modifications.
Ascertain that libraries and dependencies, such as npm or Maven, use trusted repositories. Consider hosting an internal, approved known-good repository if you have a higher risk profile.
To protect the integrity of the code going through the build and deploy processes, make sure your CI/CD pipeline includes adequate segregation, configuration, and access control.
Ensure that unsigned or unencrypted serialised data is not delivered to untrustworthy clients without some kind of integrity check or digital signature to detect alteration or replay.


Studies indicate that the time from attack to detection can take up to 200 days, and often longer. This window gives cyber thieves plenty of time to tamper with servers, corrupt databases, steal confidential information, and plant malicious code.

Implement readily available logging and audit software to quickly detect suspicious activities and unauthorized access attempts. Even if a detected attack has failed, logging and monitoring provide invaluable tools for analyzing the source and vector of the attack and learning how security policies and controls can be hardened to prevent intrusions.


Server-side request forgery (also termed as SSRF) is a web security flaw that allows an attacker to force a server-side application to send HTTP requests to any domain the attacker chooses.

When a web application fetches a remote resource without validating the user-supplied URL, an SSRF fault occurs. Even if the program is secured by a firewall, VPN, or another sort of network access control list, an attacker can force it to send a forged request to an unexpected location.

Implement input validation.
Use Regular Expressions (RegEx).
Only accept the intended IP address format (IPv4 or IPv6).
To compare against the allow list, use the method/output library’s value as the IP address.
Validate incoming Domain Names.
Review the OWASP Cheat Sheet Series

Also read – Click Here

You can also visit –

1 Comment

Leave a Reply

Your email address will not be published. Required fields are marked *