What is the OWASP Top 10?

Web application attacks have gotten more severe and complex, necessitating that each firm develops a strategic defense and response strategy based on the most prevalent and perilous web incursion techniques. Web application developers and cybersecurity professionals use the OWASP Top 10 to get an understanding of the most pertinent security concerns.

The OWASP Top 10 is a standard document that contains a list of the ten most prevalent threats to web application security for developer awareness. The OWASP Top 10 is the most famous and commonly utilized web application security awareness guide. By developing code and doing rigorous testing with these threats in mind, developers may build secure apps that protect the sensitive data of their customers from attackers.

OWASP Top 10 reflects a general agreement of the most serious threats to web application security. OWASP Top 10 was established in 2003 to assist companies and developers with safe development. Over time, it has evolved into a pseudo-standard that serves as a foundation for compliance, education, and vendor tools. Developers worldwide know the OWASP Top 10 as the first step towards better secure code.

Businesses should embrace the OWASP Top 10 and begin the process of ensuring that their web applications mitigate these risks. Using the OWASP Top 10 is likely the most effective initial step in transforming your organization's software development culture to generate more secure code.

In this article, we will discuss OWASP's Top 10 security vulnerabilities that are most likely to harm businesses in the next few years. We'll investigate the root of these flaws and how they affect us. We will also discuss the steps we may take to reduce these security flaws.

What is OWASP?

The Open Web Application Security Project (OWASP) is a non-profit organization with the mission of enhancing software security. The Open Web Application Security Project (OWASP) Foundation has conducted extensive research on web application vulnerabilities and attack patterns for over two decades, producing a set of industry guidelines and software security standards. It is a one-stop resource for people, businesses, government agencies, and other organizations seeking failure and real-world application security expertise. It provides its own set of classes on application security and related topics but does not push commercial services or goods.

The OWASP® Foundation supervises the OWASP Top 10 project, which aims to enhance software security via its community-led open source software projects, hundreds of chapters worldwide, and tens of thousands of members, as well as through holding local and global conferences. The OWASP guarantees that all of its resources, including online tools, videos, forums, and events, are accessible to the public through its website.

The most current "Top 10" list provided by OWASP was updated in the fourth quarter of 2021.

What are the Top 10 OWASP Web Vulnerabilities for 2021?

As part of the OWASP 20th Anniversary Celebration, the OWASP Top 10:2021 was published on September 24, 2021.

Risks that make the list at any point are distinguished by their position on the list and the list's publication year. Thus, according to the most current ranking, the greatest security risk is faulty access control. The identification given to it is A01:2021. The letter "A" is followed by the position on the list, the sign ":", and the year.

The numbering method aids in referencing previous versions of hazards, particularly when the name of a category has changed or when categories have merged or grown.

OWASP Top 10:2021 Vulnerability List is given below:

• A01:2021 - Broken Access Control

• A02:2021 - Cryptographic Failures

• A03:2021 - Injection

• A04:2021 - Insecure Design

• A05:2021 - Security Misconfiguration

• A06:2021 - Vulnerable and Outdated Components

• A07:2021 - Identification and Authentication Failures

• A08:2021 - Software and Data Integrity Failures

• A09:2021 - Security Logging and Monitoring Failures

• A10:2021 - Server-Side Request Forgery (SSRF)

Each of them will be explained in the next section.

A01: Broken Access Control

Access control develops ways to prevent users from exceeding the rights granted to them. Due to access vulnerabilities, unauthenticated or unauthorized individuals may get access to classified data and processes, as well as user privilege settings. Metadata manipulation, such as changing or replaying a JSON web token (JWT) access control token, changing cookies or hidden fields to gain more privileges, or taking advantage of JWT invalidation, is an example of an access control vulnerability. A second instance is a violation of the concept of default denial. Access must be restricted to certain jobs, capabilities, or users, but is available to all users. Such flaws may make it easy for attackers to get access to any data they want. However, one may prevent insufficient access security measures and identity or password management concerns by using secure coding strategies and adopting safeguards such as removing administrator accounts and limits and implementing multifactor authentication. Other methods used for preventing broken access control are as follows:

• Models of domains should impose separate application business limit restrictions.

• To limit cross-origin resource sharing, implement access control methods just once and utilize them for the life of the application; (CORS).

• Instead of providing users permission to create, view, alter, or delete data, model access controls must ensure record ownership.

• Log access control failures and notify administrators as necessary.

• To reduce the impact of automated attack tools, restrict access to application programming interfaces (APIs) and controllers.

An example attack scenario for Broken Access Control is given below:

Scenario: An attacker merely compels the target URLs to be visited. Access to the admin page requires the possession of administrative privileges.

https://vulnerable_site.com/app/getappInfo
https://vulnerable_site.com/app/admin_getappInfo

A problem exists if an unauthenticated person can access either page. This is a weakness if non-administrators may access the admin page.

A02: Cryptographic failures

Formerly regarded as sensitive data leakage, cryptographic failures are now ranked second. This is more of a symptom than a root cause. Here, the focus is on cryptographic failures or the lack of them, which often lead to sensitive data being exposed. The following are instances of typical disclosures of sensitive information:

• Usernames and passwords

• Online transactions

• Session tokens

• Personal particulars (switched service network or SSN, health records, etc.)

Using automated database encryption, for example, an application could safely encrypt credit card information. When this information is read, it is immediately decrypted. This lets a SQL injection flaw get credit card information in plain text, which an intruder could use.

Cryptographic failures may be prevented by utilizing the following preventative techniques:

• Produce and store cryptographically random keys as byte arrays. If passwords are used, they must be converted into a key-like object using an algorithm for password-based key generation.

• You should save passwords using resilient, salted, adaptive hashing algorithms with a delay factor, such as Argon2, PBKDF2, or bcrypt.

• Implementing authorized encryption is preferable to just utilizing encryption.

• When sharing sensitive data, older protocols such as file transfer protocol (FTP) and simple mail transfer protocol (SMTP) should be avoided.

An example attack scenario for cryptographic failures is given below:

• Scenario: The password database stores all passwords using unsalted or basic hashes. Because of a flaw in the way files are uploaded, an attacker can get the password database. A rainbow table of precalculated hashes may be used to reveal all unsalted hashes. Even salted hashes created by simple or fast hash algorithms may be broken by GPUs.

A03: Injections

An injection (or SQL injections) is a database attack on a website that employs Structured Query Language (SQL) to collect information or conduct actions that would normally need an authorized user account. These codes are hard for the software to figure out from its code. This lets attackers use injection attacks and impersonate trusted users to get unauthorized access to secure areas and sensitive data. SQL injections, command injections, CRLF injections, LDAP injections, etc., are examples of injections. With a maximum expected frequency of 19%, an average incidence rate of 3%, and 274,000 cases, 94% of the applications were checked for injections. Consequently, Injection dropped to the third spot on the new list. Some preventative measures for injections include:

• Utilizing LIMIT and other SQL limitations inside queries is an excellent technique to prevent the exposure of enormous amounts of data in the event of a SQL injection.

• It is advised to use affirmative server-side validation input. Numerous applications need special characters, including text fields and APIs for mobile apps.

• Employing an API that eschews the interpreter, provides a parameterized API, or translates to object-relational mapping (ORM) instruments is desirable.

An example attack scenario for A03: Injections is given below:

• Scenario 1: An application uses untrusted data to make the following insecure SQL call.

  String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

• Scenario 2: Similarly, an application's unquestioning reliance on frameworks may lead to queries that are nevertheless susceptible to attack (e.g., Hibernate Query Language (HQL)):

  Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

In both cases, the attacker modifies the 'id' parameter value in their browser to send: ' or '1'='1. For example:

http://vulnerable_site.com/app/accountView?id=' or '1'='1

This modifies the intent of both queries to return all account table entries. More perilous assaults might edit or remove data, or even execute stored processes. You may detect and prevent SQLi attack by using one of the best SQLi detection tools on your network.

A04: Insecure Design

This is a brand-new category for 2021 that focuses on design and architectural defects and emphasizes the need for increased threat modeling, design safety guidelines, and reference architectures. Insecure design is a broad category that encompasses several concerns, including "missing or insufficient control design." That does not mean that insecure design is the fundamental cause of each of the other top 10 risk categories. Insecure implementation differs from insecure design. Even if the concept is safe, implementation problems might result in vulnerabilities. On the other hand, a good execution can't make up for a bad design if there aren't the right security measures in place to protect against certain risks. Hazards caused by insecure design are avoided by taking the following preventive measures:

• Design-based tenant segregation across all layers is also seen as a useful preventive measure.

• Establish and use a secure development lifecycle with the aid of App Sec professionals to assess and construct security and privacy protections.

• Include terminology and controls for security in user stories.

• For vital verification, access control, application logic, and essential flows, threat modeling is recommended.

An example attack scenario for A04: Insecure Design is given below:

• Scenario: The e-commerce website of a retail chain lacks security against bots operated by scalpers purchasing high-end video cards for resale on auction platforms. This generates negative PR for video card manufacturers and retail store owners, as well as ill will among aficionados who cannot get these cards at any price. Careful anti-bot design and domain logic criteria, such as purchases made within a few seconds of availability, might recognize and reject inauthentic purchases.

A05: Security Misconfigurations

General security configuration problems, like wrong access restrictions, are very dangerous because they make it easy for attackers to get to important data and site areas. With an average incidence rate of 4% and more than 208,000 instances of a common weakness enumeration (CWE) in this area, OWASP checked 90% of apps for misconfiguration. Notable CWEs include "CWE-16 configuration" and "CWE-611 incorrect limitation of XML external entity reference". To minimize configuration problems, it is necessary to use secure installation approaches, such as:

• It is great for automating operations involved in creating a new safe environment to save time and effort. Remove or do not install unused features and frameworks. The main platform is devoid of unnecessary features, components, documentation, or demonstrations reducing the probability of configuration vulnerabilities.

• A systematic method of reinforcement enables the rapid and straightforward implementation of a safe environment. The setup of the development, quality assurance, and production environments should be comparable, with unique user permissions.

An example attack scenario for A05: Security Misconfigurations is given below:

• Scenario: The default sharing rights of a cloud service provider (CSP) allow Internet access by other CSP customers. This permits access to sensitive data stored in cloud storage.

A06: Vulnerable and Outdated Components

The majority of internet applications are developed using third-party frameworks. Unknown application codes may lead to unpleasant consequences and circumstances, such as access control violations, SQL injections, and so on. There may be vulnerability-related risks if the software is insecure, unsupported, or out of date. The package contains the application/web server, operating system, applications, database management system (DBMS), application programming interfaces (APIs), other parts, libraries, and runtime environments. There are automated methods available to assist attackers in locating poorly configured or unpatched computers. Certain preventative measures for vulnerable and out-of-date components include:

• Keep an eye out for inoperable modules and components that do not give security updates for earlier versions. Consider constructing virtual patches to observe, detect, or protect against the identified vulnerability if patching cannot be performed.

• Eliminate any unnecessary specifications, capabilities, components, files, or documentation.

• It is preferable to get components from authorized suppliers through secure means.

An example attack scenario for A06: Vulnerable and Outdated Components is given below:

• Scenario: Since components normally execute with the same rights as the application, vulnerabilities in any component might have severe consequences. Such faults may be unintentional (e.g., a coding mistake) or deliberate (e.g., a backdoor in a component). Some such exploitable component vulnerabilities found are:
  • CVE-2017-5638, a Struts 2 remote code execution flaw that allows the execution of arbitrary code on the server, has been attributed to severe security breaches.
  • Even though Internet of Things (IoT) devices are usually difficult or impossible to patch, it might be crucial to do so (e.g., biomedical devices).

A07: Identification and Authentication Failures

This category, once known as broken authentication, has fallen from second place and is now comprised of CWEs associated with identity issues. When an adversary acquires user information, password recovery, ID sessions, and other login credentials, security concerns arise. An identity and authentication failure, as the name suggests, involves hackers exploiting such weaknesses to take advantage of poor authentication. If the program allows automated attacks such as credential stuffing - when an attacker has access to lists of genuine users and passwords - or predetermined, weaker, and popular passwords such as "Password1" or "admin/admin," these might be indications of authentication problems. To avoid such authentication flaws, the following preventative steps must be considered:

• Installing default credentials, particularly for administrative users, is discouraged.

• Using identical messages for each conclusion prevents account enumeration attacks on password recovery, registrations, and API routes.

• It is feasible to increase password security by comparing new or updated passwords against a database of the 10,000 worst passwords.

• To prevent automated credential stuffing, brute-force attacks, and the reuse of stolen credentials, multifactor authentication must be utilized wherever possible.

An example attack scenario for A07: Identification and Authentication Failures is given below:

• Scenario: The application session timeouts are not properly configured. A user accesses an application via the use of a public computer. Instead of choosing "logout," the user closes the tab and exits the browser. An attacker employs the same browser an hour later, and the user's authentication remains intact.

A08: Software and Data Integrity Failures

As more sensitive data is kept in databases, making them more susceptible to security breaches, data integrity becomes a need for software. This is a new category that focuses on assuming without validating the integrity of software updates, important data, and CI/CD operations. The usage of extensions, modules, or repositories from content delivery networks (CDNs) or unapproved sources is one example. Unprotected continuous integration and delivery (CI/CD) processes may increase the risk of malicious code, system compromise, and unwanted access. Methods for preventing software and data integrity failures are given below:

• It is vital to ensure that the CI/CD workflow includes the requisite segmentation, access control, and parameters to protect the code integrity throughout the configuration and deployment processes.

• Unsigned or unencrypted compilation data should not be sent to untrusted clients unless integrity testing or a digital signature is in place to detect data modification or duplication.

• A software supply chain security tool, such as OWASP CycloneDX or OWASP Dependency-Check, may be used to ensure that components lack design defects.

• The use of digital signatures to authenticate that data or software originates from anticipated sources and has not been altered.

An example attack scenario for A08: Software and Data Integrity Failures is given below:

• SolarWinds malicious update scenario: Nation-states have been known to target update systems, with the SolarWinds Orion attack being the most recent cyber attack of note. The software development business used secure build and update integrity procedures. Nonetheless, they were subverted, and for many months, the company issued a highly targeted malicious update to more than 18,000 companies, of which around 100 were compromised. It is one of the most extensive and major breaches of this sort in the history of the world.

A09: Security Logging and Monitoring Failures

A lack of monitoring in the presence of suspicious activities and events might elongate unmonitored time gaps, enabling security breaches to go undetected for longer than they would if the better recording were implemented. This area of the OWASP Top 10 2021 is intended to assist with the detection, escalation, and resolution of recent security breaches. Detecting a security compromise without recording and monitoring is unlikely. This failure was shown by a notifiable General Data Protection Regulation (GDPR) event involving a major European airline. Intruders likely exploited payment application security weaknesses to obtain access to information on over 400 thousand customer payments. In response, the privacy authorities punished the airline with 20 million pounds for losing the information. To prevent such attacks, it is prudent for users to:

• Ensure that log data is correctly encoded to prevent cyberattacks or threats to the monitoring systems.

• Ensure that all authentication, access security, and server-side data validation issues are logged with sufficient user information to detect suspicious or fraudulent accounts and are stored for a sufficient amount of time to allow for a delayed, comprehensive investigation.

• Create or implement incident recovery and response plans, such as NIST 800-61r2 or a later version.

• Ensure that logs are produced in formats that log management systems can consume.

An example attack scenario for A09 Security Logging and Monitoring Failures is given below:

• Scenario: Due to a lack of monitoring and recording, the operator of a children's health plan provider's website was unable to discover a breach. A third party told the health plan provider that an attacker accessed and edited thousands of sensitive health information belonging to more than 3.5 million children. A post-incident investigation revealed that the creators of the website had not fixed critical vulnerabilities. Since the system was not logged or monitored, the data breach](/docs/network-security-tutorials/what-is-data-breach) might have been ongoing since 2013, a period of more than seven years.

A10: Server-Side Request Forgery (SSRF)

The testing coverage, occurrence rate, and impact and exploit scores for this category are all above average. SSRF occurs when server-side queries are executed without validating the user-supplied URL. This enables an attacker to cause an application to communicate a forged request to an unauthorized destination, regardless of whether the application is secured by virtual private networks (VPN), firewalls, or network access control lists (ACL). As new internet apps provide end-users with useful capabilities, obtaining a URL has become commonplace. Consequently, the prevalence of SSRF is growing. In addition, the complexity of cloud services and architecture increases the severity of SSRF. It is possible to avert such SRRF attacks by using the following preventative measures:

• To prevent attacks such as DNS remapping and "time of check, time of use", it is important to be aware of URL correctness in (TOCTOU) circumstances.

• To mitigate the consequences of SSRF, remote resource access functions should be separated into independent networks.

• Install "deny by default" firewall settings or network access control rules to restrict all web traffic except for necessary internal traffic.

An example attack scenario for A10: SRRF is given below:

• Port Scanning Scenario: If the network segmentation is not deployed, hackers may map internal networks and identify whether ports on internal servers are open or closed based on connection outcomes, elapsed time to connect, or the rejection of SSRF payload connections.

Why OWASP Top 10 is Important?

The OWASP Top 10 is an excellent starting point for building safe programming. According to research conducted by Veracode, a scan of 130,000 programs revealed that roughly 68% of apps have OWASP Top 10 vulnerabilities.

The OWASP Top 10 is not only an application vulnerability list but also evaluates each defect class using the OWASP Risk Rating methodology and offers recommendations, best practices for avoiding attacks, examples, and references for each risk. By understanding the OWASP Top 10 vulnerabilities and how to fix them, application developers may take meaningful steps toward a more secure application that protects users from harmful assaults.

Collaboration with OWASP may make applications more resistant to cyberattacks, contribute to a more resilient network and cloud encryption, improve the chances of application success, and significantly enhance the company's cyber resilience.

Lastly, auditors often perceive a company's inability to address the OWASP Top 10 as a sign that it may also be failing to fulfill other compliance standards. Incorporating the Top 10 into the software development life cycle (SDLC) demonstrates an organization's commitment to safe development best practices.

What is the Difference Between OWASP 2021 and OWASP 2017?

The OWASP Top 10: 2021 didn't eliminate any items from the OWASP 2017 list. In reality, it widened and merged several of the previous things in order to make way for a few newly-evolved dangers. The differences between OWASP 2021 and OWASP 2017 are as follows:

• Included Vulnerabilities: The list was expanded by three entries. These vulnerabilities include insecure design, software and data integrity failures, and Server-Side Request Forgery.

• Combined Vulnerabilities: Cross-Site Scripting was merged with Injection since it has been seen as a kind of injection attack. Next, XML External Entities were merged with Security Misconfiguration, since these attacks leverage XML standard misconfigurations often. Insecure de-serialization was subsequently merged with a new item titled "Software and Data Integrity Failures".

• Expanded Vulnerabilities: As seen in the figure below, Sensitive Data Exposure was renamed Cryptographic Failures to account for all sorts of data exposures, leaks, and breaches caused by insufficient encryption or database misconfiguration.

Figure 1. OWASP 2021 vs OWASP 2017

How often is the OWASP Top 10 updated?

The OWASP Top 10 list, compiled utilizing research data from hundreds of partner companies, was initially published in 2003 and is updated every three to four years. After the first edition of the OWASP Top 10 list was released, updates subsequently occurred as listed below:

• OWASP Top 10: 2004

• OWASP Top 10: 2007

• OWASP Top 10: 2010

• OWASP Top 10: 2013

• OWASP Top 10: 2017

• OWASP Top 10: 2021

The most current OWASP Top 10 revision was released in 2021. In September 2021, the list was updated for the first time since 2017 to reflect the most recent online security risks.

What are OWASP Projects and Tools?

In addition to the Top 10 list, OWASP has 250 active projects that are classified into three categories:

• Tools and documentation are used to integrate security-related activities into application lifecycle management.

• Tools and documentation are used to prevent security-related design and implementation faults

• Tools and documentation are used to identify security-related design and implementation problems

The OWASP Top 10 is the most well-known OWASP project, but additional OWASP projects and tools include the following:

• Amass: Amass is a tool for comprehensive domain name system enumeration, attack surface analysis, and the detection of external assets.

• Application Security Verification Standard: The Application Security Verification Standard is a framework for assessing the security controls of online applications and a set of secure development standards.

• Cheat Sheet Series: The Cheat Sheet Series is a collection of tips for appropriate application development security practices.

• CSRFGuard: CSRFGuard is a package that provides patterns that reduce the likelihood of cross-site request forgery (CSRF) attacks.

• CycloneDX: CycloneDX is a standard for bill of materials component analysis and security.

• Defectdojo: Defectdojo is a vulnerability management tool for testing security.

• Dependency-Check: As part of software composition analysis, Dependency-Check performs dependency checks for vulnerabilities.

• Dependency-Track: Dependency-Track is a tool for component analysis that detects supply chain concerns.

• Juice Shop: Juice Shop is an example of a web application that has been developed to integrate all of the OWASP Top 10 vulnerabilities. It is developed completely in JavaScript and gives penetration testers and other security experts a hacking target.

• Mobile Security Testing Guide: Mobile Security Testing Guide is a collection of guidelines for testing and verifying the security of mobile applications.

• ModSecurity Core Rule Set: The ModSecurity Core Rule Set is a collection of attack detection rules used by web application firewalls(WAFs).

• Offensive Web Testing Framework: Offensive Web Testing Framework is a penetration testing framework.

• Software Assurance Maturity Model: Throughout the software development lifecycle, Software Assurance Maturity Model examines and enhances software security.

• Security Knowledge Framework: The Security Knowledge Framework is a web application that describes how to implement safe coding concepts in several computer languages.

• Security Shepherd: Security Shepherd is a platform for web and mobile application security training.

• Web Security Testing Reference: Web Security Testing Reference is a thorough guide on web application and web service security testing.

• The Zed Attack Proxy: The Zed Attack Proxy web application scanner is used for penetration testing and teaching. The software is distributed under the Apache open source license.

What is the OWASP Check List?

OWASP created a penetration testing checklist for use by pen-testers to enhance uniformity across internal testing teams and external vendors.

As such, this list has been compiled for several purposes, including:

• Testing Checklist

• RFP Template

• Benchmarks

This checklist contains testing considerations. It does not recommend any specific approaches.

The OWASP Web Application Penetration Check List is given below:

https://owasp.org/www-project-web-security-testing-guide/assets/archive/OWASP_Web_Application_Penetration_Checklist_v1_1.pdf

Category	Ref Number	Name	Objective	Notes
AppDOS	OWASP-AD-001	Application Flooding	Ensure that the application functions correctly when presented with large volumes of requests, transactions, and/or network traffic.	Use various fuzzing tools to perform this test (e.g. SPIKE)
	OWASP-AD-002	Application Lockout	Ensure that the application does not allow an attacker to reset or lockout user's accounts.
AccessControl	OWASP-AC001	Parameter Analysis	Ensure that the application implements its access control model by ensuring that any accessible parameters would not provide an attacker access to other services.	Typically this includes manipulation of form fields, URL query strings, client-side script values and cookies.
	OWASP-AC002	Authorization	Ensure that authorisation-required resources undergo proper authorization checks prior to being provided to a user.
	OWASP-AC003	Authorization Parameter Manipulation	Ensure that after a genuine user has signed in, the session ID parameter cannot be changed to represent another user account.	i.e. accountnumber, policynumber,usernr etc.
	OWASP-AC004	Authorized pages/functions	Determine whether it is feasible to access sites or features that need authentication but may be circumvented.
	OWASP-AC005	Application Workflow	Ensure that the sequence is enforced when the application needs the user to do tasks in a specified order.
Authentication	OWASP-AUTHN-001	Authentication endpoint request should be HTTPS	Ensure that users are only required to input authentication credentials on secure pages.	This guarantees that the user is aware of who is requesting their credentials and where they are being transmitted.
	OWASP-AUTHN-002	Authentication bypass	Make certain that the authentication procedure cannot be circumvented.	Typically this happens in conjunction with flaws like SQL Injection.
Authentication. User	OWASP-AUTHN-003	Credentials transport over an encrypted channel	Ensure that usernames and passwords are sent over an encrypted channel.	Typically this should be SSL.
	OWASP-AUTHN-004	Default Accounts	Check for default account names and passwords in use
	OWASP-AUTHN-005	Username	Ensure that the username is not public (or "wallet") information such as email or SSN.
	OWASP-AUTHN-006	Password Quality	Ensure that the password complexity makes guessing passwords difficult.
	OWASP-AUTHN-007	Password Reset	Ensure that user must respond to a secret answer / secret question or other predetermined information before passwords can be reset.	Ensure that passwords are not sent to users in email
	OWASP-AUTHN-008	Password Lockout	Ensure that the users account is locked out for a period of time when the incorrect password is entered more that a specific number of times (usually 5).
	OWASP-AUTHN-009	Password Structure	Ensure that special meta characters cannot be used within the password	Can be useful when performing SQL injection
	OWASP-AUTHN-008	Blank Passwords	Ensure that passwords are not blank
Authentication. SessionManagement	OWASP-AUTHSM-001	Session Token Length	Ensure that the session token is of adequate length to provide protection from guessing during an authenticated session.
	OWASP-AUTHSM-002	Session Timeout	Ensure that the session tokens are only valid for a predetermined period after the last request by the user
	OWASP-AUTHSM-003	Session Reuse	Ensure that session tokens are changed when the user moves from an SSL protected resource to a non-SSL protected resource.
	OWASP-AUTHSM-004	Session Deletion	Ensure that the session token is invalidated when the user logs out.
	OWASP-AUTHSM-005	Session Token Format	Ensure that the session token is non-persistent and is never written to the browsers history or cache
Configuration. Management	OWASP-CM-001	HTTP Methods	Ensure that the web server does not support the ability to manipulate resources from the Internet (e.g. PUT and DELETE)
	OWASP-CM-002	Virtually Hosted Sites	Try and determine if site is virtually hosted	If there are further sites, they could be vulnerable and lead to the compromise of the base server
	OWASP-CM-003	Known Vulnerabilities / Security Patches	Ensure that known vulnerabilities which vendors have patched are not present.
	OWASP-CM-004	Back-up Files	Ensure that no backup files of source code are accessible on the publicly accessible part of the application.
	OWASP-CM-004	Web Server Configuration	Ensure that common configuration issues such as directory listings and sample files have been addressed
	OWASP-CM-005	Web Server Components	Ensure that web server components like Front Page Server Extensions or Apache modules do not introduce any security vulnerabilities
	OWASP-CM-006	Common Paths	Check for existence of common directories within the application root	/backup & /admin may contain information
	OWASP-CM-007	Language/Application defaults	I.e. J2EE environmental quirks e.g Availability of snoop.jsp /*Spy.jsp and loaded modules
Configuration. Management Infrastructure	OWASP-CM-008	Infrastructure Admin Interfaces	Ensure that administrative interfaces to infrastructure such as web servers and application servers are not accessible to the Internet.
Configuration. Management. Application	OWASP-CM-009	Infrastructure Admin Interfaces	Ensure that administrative interfaces to the applications are not accessible to the Internet.
Error Handling	OWASP-EH-001	Application Error Messages	Ensure that the application does not present application error messages to an attacker that could be used in an attack.	This typically occurs when applications return verbose error messages such as stack traces or database errors.
	OWASP-EH-002	User Error Messages	Ensure that the application does not present user error messages to an attacker that could be used in an attack.	This typically occurs when applications return error messages such as "User does not exist" or "User Correct, Password Incorrect"

What is OWASP Cheat Sheet?

The OWASP Cheat Sheet Series was developed to give a succinct compilation of high-value application security information. These cheat sheets were compiled by application security specialists with experience in certain areas. There are 78 cheat sheets available, indexed in alphabetical order. The Top 10 cheat sheet helps OWASP Top Ten users determine which cheat sheets correspond to each security area. All OWASP cheat sheets are accessible on the foundation website: https://cheatsheetseries.owasp.org/IndexTopTen.html

Is OWASP a Framework?

No, OWASP is not a framework. But, the OWASP foundation creates the OWASP-SKF (OWASP Security Knowledge Framework), an open-source online application that may be used by any business for its safe coding methods and is available in several programming languages.

Does OWASP Apply to Mobile Apps?

Yes. The OWASP flagship project provides a security standard for mobile apps (OWASP MASVS) and a comprehensive testing guide (OWASP MSTG) that covers the processes, techniques, and tools used during a mobile app security test, as well as a comprehensive set of test cases that enables testers to deliver consistent and comprehensive results.

The OWASP MASVS is a mobile application security standard. It may be used by mobile software architects and developers who want to create safe mobile apps, as well as security testers who need to guarantee the completeness and consistency of test findings.

The OWASP MSTG is a thorough guide for testing and reverse engineering mobile app security. It outlines technical procedures for validating the OWASP Mobile Application Verification Standard's controls (MASVS).

The OWASP Mobile Top 10 list was published in 2016. The OWASP Top 10 Mobile Risks - Final List 2016 are given below:

• M1: Improper Platform Usage

• M2: Insecure Data Storage

• M3: Insecure Communication

• M4: Insecure Authentication

• M5: Insufficient Cryptography

• M6: Insecure Authorization

• M7: Client Code Quality

• M8: Code Tampering

• M9: Reverse Engineering

• M10: Extraneous Functionality