OWASP Top Ten 2021 (Major Update from 2017)

Someone once said never commit to memory what you can write down. So here is the OWASP Top Ten for all those attending interviews and need to brush up what the current order of the OWASP Top Ten Application vulnerabilities. This is the current 2021 OWASP Top Ten.

(1) A01:2021 Broken Access Control

Moves up from the fifth position; 94% of applications were tested for some form of broken access control. The 34 Common Weakness Enumerations (CWEs) mapped to Broken Access Control had more occurrences in applications than any other category.

Access control refers to a system that controls access to information or functionality. Broken access controls allow attackers to bypass authorization and perform tasks as though they were privileged users such as administrators. For example, a web application could allow a user to change which account they are logged in to simply by changing part of a URL, without any other verification.

Access controls can be secured by ensuring that a web application uses authorization tokens* and sets tight controls.

Many services issue authorization tokens when users log in. Every privileged request that a user makes will require that the authorization token be present. This is a secure way to ensure that the user is who they say they are without having to constantly enter their login credentials.

  • – Allows access to restricted resources

(2) A02:2021 Cryptographic Failures

Shifts up one position to #2, previously known as Sensitive Data Exposure, which was a broad symptom rather than a root cause. The renewed focus here is on failures related to cryptography which often leads to sensitive data exposure or system compromise.

(3) A03:2021 Injection

Slides down to the third position. 94% of the applications were tested for some form of injection, and the 33 CWEs mapped into this category have the second most occurrences in applications. Cross-site Scripting is now part of this category in this edition

If web applications don’t protect sensitive data such as financial information and passwords, attackers can gain access to that data and sell or utilize it for nefarious purposes. One popular method for stealing sensitive information is using a man-in-the-middle attack.

Injection attacks happen when untrusted data is sent to a code interpreter through a form input or some other data submission to a web application. For example, an attacker could enter SQL database code into a form that expects a plaintext username. If that form input is not properly secured, this will result in that SQL code being executed. This is known as an SQL injection attack.

Injection attacks can be prevented by validating and/or sanitizing user-submitted data. (Validation means rejecting suspicious-looking data, while sanitization refers to cleaning up the suspicious-looking parts of the data.) In addition, a database admin can set controls to minimize the amount of information an injection attack can expose.

– OS
– Log

(4) A04:2021 Insecure Design

A new category for 2021, focusing on risks related to design flaws. If we genuinely want to “move left” as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures.

(5) A05:2021 Security Misconfiguration

Moves up from #6 in the previous edition; 90% of applications were tested for some form of misconfiguration. With more shifts into highly configurable software, it’s not surprising to see this category move up. The former category for XML External Entities (XXE) is now part of this category.

Security misconfiguration is the most common vulnerability on the list and is often the result of using default configurations or displaying excessively verbose errors. For instance, an application could show a user overly-descriptive errors, which may reveal vulnerabilities in the application. This can be mitigated by removing any unused features in the code and ensuring that error messages are more general.

(6) A06:2021 Vulnerable and Outdated Components

Many modern web developers use components such as libraries and frameworks in their web applications. These components are pieces of software that help developers avoid redundant work and provide needed functionality; common examples include front-end frameworks like React and smaller libraries that are used to add share icons or a/b testing. Some attackers look for vulnerabilities in these components, which they can then use to orchestrate attacks. Some of the more popular components are used on hundreds of thousands of websites; an attacker finding a security hole in one of these components could leave hundreds of thousands of sites vulnerable to exploitation.

Component developers often offer security patches and updates to plug up known vulnerabilities, but web application developers don’t always have the patched or most-recent versions of components running on their applications. To minimize the risk of running components with known vulnerabilities, developers should remove unused components from their projects, as well as ensure that they are receiving components from a trusted source and ensuring they are up to date.
Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.

  • Shodan

(7) A07:2021 Identification and Authentication Failures

Previously Broken Authentication and is sliding down from the second position, and now includes CWEs that are more related to identification failures. This category is still an integral part of the Top 10, but the increased availability of standardized frameworks seems to be helping.

Vulnerabilities in authentication (login) systems can give attackers access to user accounts and even the ability to compromise an entire system using an admin account. For example, an attacker can take a list containing thousands of known username/password combinations obtained during a data breach and use a script to try all those combinations on a login system to see if there are any that work.

Some strategies to mitigate authentication vulnerabilities are requiring 2-factor authentication (2FA) and limiting or delaying repeated login attempts using rate limiting.

  • Weak Password Policy
  • Weak Cryptography
  • User Access Controls

(8) A08:2021 Software and Data Integrity Failures

A new category for 2021, focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) data mapped to the 10 CWEs in this category. Insecure Deserialization from 2017 is now a part of this larger category.

(9) A09:2021 Security Logging and Monitoring Failures

Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.


App Logging

Crash Logging

Exception Handlling

(10) A10:2021 Server-Side Request Forgery

Added from the Top 10 community survey (#1). The data shows a relatively low incidence rate with above-average testing coverage, along with above-average ratings for Exploit and Impact potential. This category represents the scenario where the security community members are telling us this is important, even though it’s not illustrated in the data at this time.

The official OWASP PDF for the OWASP Top Ten 2021 can be found here.


Security Assertion Markup Language (SAML)

SAML Security we got this.

What is SAML?

SAML is a (XML) open standard for the digital mechanics when performing and sharing Authorization and Authentication between two parties, namely (SP) Service Provider and (IdP) Identity Provider.

How does the SAML Work?

1. User initiates a request to a resource (www.mybankApp.com)

2. (SP) Service Provider picks up the request (should be from behind a API gateway protected by a WAF and Edge controls) , checks to see if the request needs to be authenticated, if so the SP will send a SAML request to the IdP via the users browser.

3. Users browser forwards the SAML request to the IdP.

4. IdP sends a HTTPS request to the user with a SAML authentication request. User responds with valid authentication credentials (USER && PASS && OTP).

5. If authentication is successful the IdP will send a response back to the SP via the users browser.

6. User browser forwards to the authenticated response back to the SP to request the restricted resource.

7. SP will check if the authenticated user has the rights to access the resources if so an authenticated session will be established with the user and resource via the SP.

Key Terms relating to SAML

SAML TERMDescription
IDPIdentity Provider responsible for Authentication
SPService Provider responsible for managing authorisation of resources.
SAML RequestIssued from SP to user’s browser for redirecting to IdP
SAML ResponseTrusted response sent from SP to requestor with access to the requested resource or failed response with no access to the resource. Should always be signed by a private key
AssertionSecure encrypted XML entity with sensitive data
XML Signature (DSIG)Typically a configuration of a shibboleth library within the SP to carry out hashing
AttributesUser attributes encrypted within an assertion
Relay StateUsed for pre authed users requests, set to use once to stop replay attacks
SAML TrustTrust store and configuration for certificates. (Certificate Trust configuration)
MetadataXML Configuraiton files for discover and configuration convenience.
Core SAML terms and descriptions

What is SAML used for?

It’s basically a standard way of using XML to facilitate SSO.

SAML is used to authenticate users in a (SSO) Single Sign On scenario. As we explained more technically above, it passes user identity credentials between a SP and IDP such as Azure AD.

SAML can be configured to be IdP initiated or SP initiated these are the 2 uses case flows for SAML. Both have different use cases:

Use case 1 IdP Initiated: Used for protected resources, only a valid authenticated response is needed to access the resource.

Use case 2 SP Initiated: is used to access the resource directly, the SP will determine if the user is needed to authenticate before accessing the resource. If the resource is protected (non public data) a request will then be sent to the IdP in order for the user to authenticate first with the IdP in order to create the correct assertion to be sent to the SP to allow access to the resource.

A modern based cloud architecture for SAML SSO via application proxies with AAD on Azure Cloud.

SAML Architecture is based on existing standards such as:

Security Concerns & Best Practices for SAML

Denial of Servicce (DOS) – Parsers should be reviewed for unused functions, design review of the request creation and parsing technologies used.

Flawed assertion validation – Signature checks, Assertion Consumer Service insecure configuration, Trust Store, SAML Response validation

XML Parser – Unused functions, known vulnerabilities, Document Type Definition (DTD) Fetching see XXE. Canonicalized XML (comment stripping)

XXEXML External Entity (Injection) – Due to the fact that SAML Responses are deflated and base64’d XML documents, we can test for XXE by manipulating the XML document sent as the SAML Response. Example:

Schema Validation – Signature Wrapping (XSW) Attacks, Signature Validation & Function Validation, Explicit Expressions

Validate Every Signature – Limit Algos (SHA256), None =(,

HTTPS – Not self signed

Validate Parties – Destination, Issuer, Recipient,

Validation Window – Session Time

Historical Cache – No Duplicates (Replay Attacks)

Limit Buffer Size – DOS, Biuffer Overflow.