OWASP Top 10 -
2021
1. A02 Cryptographic Failures - Scenario 1: An application encrypts credit card numbers in a database using
automatic database encryption. However, this data is automatically decrypted when retrieved, allowing a SQL injection
flaw to retrieve credit card numbers in clear text.
2. A02 Crytographic Failures - Scenario 2: A site doesn't use or enforce TLS for all pages or supports weak
encryption. An attacker monitors network traffic (e.g., at an insecure wireless network), downgrades connections from
HTTPS to HTTP, intercepts requests, and steals the user's session cookie. The attacker then replays this cookie and
hijacks the user's (authenticated) session, accessing or modifying the user's private data. Instead of the above they could
alter all transported data, e.g., the recipient of a money transfer.
3. A02 Cryptographic Failures - Scenario 3: The password database uses unsalt- ed or simple hashes to store
everyone's passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes
can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be
cracked by GPUs, even if they were salted.
4. A01 Broken Access Control: Access control enforces policy such that users cannot act outside of their intended
permissions. Failures typically lead to unautho- rized information disclosure, modification, or destruction of all data or
performing a business function outside the user's limits. Common access control vulnerabilities include:
Violation of the principle of least privilege or deny by default, where access should only be granted for particular
capabilities, roles, or users, but is available to anyone. Bypassing access control checks by modifying the URL
(parameter tampering or force browsing), internal application state, or the HTML page, or by using an attack tool
modifying API requests.
Permitting viewing or editing someone else's account, by providing its unique iden- tifier (insecure direct object
references)
Accessing API with missing access controls for POST, PUT and DELETE. Elevation of privilege. Acting as a user
without being logged in or acting as an admin when logged in as a user.
Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token, or a cookie
or hidden field manipulated to elevate privileges or abusing JWT invalidation.
CORS misconfiguration allows API access from unauthorized/untrusted origins. Force browsing to authenticated pages
as an unauthenticated user or to privileged pages as a standard user.
5. A01 Broken Access Control - Scenario 1: The application uses unverified data in a SQL call that is accessing
account information:
, OWASP Top 10 -
2021
pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.exe- cuteQuery( );
An attacker simply modifies the browser's 'acct' parameter to send whatever account number they want. If not correctly
verified, the attacker can access any user's account.
https://example.com/app/accountInfo?acct=notmyacct
6. A01 Broken Access Control - Scenario 2: An attacker simply forces browses to target URLs. Admin rights are
required for access to the admin page. https://example.com/app/getappInfo https://example.com/app/admin_getappInfo
If an unauthenticated user can access either page, it's a flaw. If a non-admin can access the admin page, this is a flaw.
7. A03 Injection - How To Prevent: Preventing injection requires keeping data separate from commands and
queries:
The preferred option is to use a safe API, which avoids using the interpreter entirely, provides a parameterized interface,
or migrates to Object Relational Mapping Tools (ORMs).Note: Even when parameterized, stored procedures can still
introduce SQL injection if PL/SQL or T-SQL concatenates queries and data or executes hostile data with EXECUTE
IMMEDIATE or exec().
Use positive server-side input validation. This is not a complete defense as many applications require special characters,
such as text areas or APIs for mobile applications.
For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.Note:
SQL structures such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names
are dangerous. This is a common issue in report-writing software.
Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
8. A03 Injection - Scenario 1: An application uses untrusted data in the construc- tion of the following vulnerable
SQL call:
String query = "SELECT \* FROM accounts WHERE custID='" + request.getPara- meter("id") + "'";
9. A03 Injection - Scenario 2: Similarly, an application's blind trust in frameworks may result in queries that are still
vulnerable, (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: ' UNION SLEEP(10);--. For
example:
http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--
, OWASP Top 10 -
2021
This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could
modify or delete data or even invoke stored procedures.
10.A04 Insecure Design - How To Prevent: Establish and use a secure develop- ment lifecycle with AppSec
professionals to help evaluate and design security and privacy-related controls
Establish and use a library of secure design patterns or paved road ready to use components
Use threat modeling for critical authentication, access control, business logic, and key flows
Integrate security language and controls into user stories
Integrate plausibility checks at each tier of your application (from frontend to back- end)
Write unit and integration tests to validate that all critical flows are resistant to the threat model. Compile use-cases and
misuse-cases for each tier of your application. Segregate tier layers on the system and network layers depending on the
exposure and protection needs
Segregate tenants robustly by design throughout all tiers Limit resource consumption by
user or service
11.A04 Insecure Design - Attack Scenario 1: A credential recovery workflow might include "questions and
answers," which is prohibited by NIST 800-63b, the OWASP ASVS, and the OWASP Top 10. Questions and answers
cannot be trusted as evidence of identity as more than one person can know the answers, which is why they are
prohibited. Such code should be removed and replaced with a more secure design.
12.A04 Insecure Design - Attack Scenario 2: A cinema chain allows group book- ing discounts and has a maximum
of fifteen attendees before requiring a deposit. Attackers could threat model this flow and test if they could book six
hundred seats and all cinemas at once in a few requests, causing a massive loss of income.
13.A04 Insecure Design - Attack Scenario 3: A retail chain's e-commerce website does not have protection against
bots run by scalpers buying high-end video cards to resell auction websites. This creates terrible publicity for the video
card makers and retail chain owners and enduring bad blood with enthusiasts who cannot obtain these cards at any price.
Careful anti-bot design and domain logic rules, such
as purchases made within a few seconds of availability, might identify inauthentic purchases and rejected such
transactions.
14.A05 Security Misconfiguration: The application might be vulnerable if the application is:
Missing appropriate security hardening across any part of the application stack or
2021
1. A02 Cryptographic Failures - Scenario 1: An application encrypts credit card numbers in a database using
automatic database encryption. However, this data is automatically decrypted when retrieved, allowing a SQL injection
flaw to retrieve credit card numbers in clear text.
2. A02 Crytographic Failures - Scenario 2: A site doesn't use or enforce TLS for all pages or supports weak
encryption. An attacker monitors network traffic (e.g., at an insecure wireless network), downgrades connections from
HTTPS to HTTP, intercepts requests, and steals the user's session cookie. The attacker then replays this cookie and
hijacks the user's (authenticated) session, accessing or modifying the user's private data. Instead of the above they could
alter all transported data, e.g., the recipient of a money transfer.
3. A02 Cryptographic Failures - Scenario 3: The password database uses unsalt- ed or simple hashes to store
everyone's passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes
can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be
cracked by GPUs, even if they were salted.
4. A01 Broken Access Control: Access control enforces policy such that users cannot act outside of their intended
permissions. Failures typically lead to unautho- rized information disclosure, modification, or destruction of all data or
performing a business function outside the user's limits. Common access control vulnerabilities include:
Violation of the principle of least privilege or deny by default, where access should only be granted for particular
capabilities, roles, or users, but is available to anyone. Bypassing access control checks by modifying the URL
(parameter tampering or force browsing), internal application state, or the HTML page, or by using an attack tool
modifying API requests.
Permitting viewing or editing someone else's account, by providing its unique iden- tifier (insecure direct object
references)
Accessing API with missing access controls for POST, PUT and DELETE. Elevation of privilege. Acting as a user
without being logged in or acting as an admin when logged in as a user.
Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token, or a cookie
or hidden field manipulated to elevate privileges or abusing JWT invalidation.
CORS misconfiguration allows API access from unauthorized/untrusted origins. Force browsing to authenticated pages
as an unauthenticated user or to privileged pages as a standard user.
5. A01 Broken Access Control - Scenario 1: The application uses unverified data in a SQL call that is accessing
account information:
, OWASP Top 10 -
2021
pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.exe- cuteQuery( );
An attacker simply modifies the browser's 'acct' parameter to send whatever account number they want. If not correctly
verified, the attacker can access any user's account.
https://example.com/app/accountInfo?acct=notmyacct
6. A01 Broken Access Control - Scenario 2: An attacker simply forces browses to target URLs. Admin rights are
required for access to the admin page. https://example.com/app/getappInfo https://example.com/app/admin_getappInfo
If an unauthenticated user can access either page, it's a flaw. If a non-admin can access the admin page, this is a flaw.
7. A03 Injection - How To Prevent: Preventing injection requires keeping data separate from commands and
queries:
The preferred option is to use a safe API, which avoids using the interpreter entirely, provides a parameterized interface,
or migrates to Object Relational Mapping Tools (ORMs).Note: Even when parameterized, stored procedures can still
introduce SQL injection if PL/SQL or T-SQL concatenates queries and data or executes hostile data with EXECUTE
IMMEDIATE or exec().
Use positive server-side input validation. This is not a complete defense as many applications require special characters,
such as text areas or APIs for mobile applications.
For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.Note:
SQL structures such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names
are dangerous. This is a common issue in report-writing software.
Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
8. A03 Injection - Scenario 1: An application uses untrusted data in the construc- tion of the following vulnerable
SQL call:
String query = "SELECT \* FROM accounts WHERE custID='" + request.getPara- meter("id") + "'";
9. A03 Injection - Scenario 2: Similarly, an application's blind trust in frameworks may result in queries that are still
vulnerable, (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: ' UNION SLEEP(10);--. For
example:
http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--
, OWASP Top 10 -
2021
This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could
modify or delete data or even invoke stored procedures.
10.A04 Insecure Design - How To Prevent: Establish and use a secure develop- ment lifecycle with AppSec
professionals to help evaluate and design security and privacy-related controls
Establish and use a library of secure design patterns or paved road ready to use components
Use threat modeling for critical authentication, access control, business logic, and key flows
Integrate security language and controls into user stories
Integrate plausibility checks at each tier of your application (from frontend to back- end)
Write unit and integration tests to validate that all critical flows are resistant to the threat model. Compile use-cases and
misuse-cases for each tier of your application. Segregate tier layers on the system and network layers depending on the
exposure and protection needs
Segregate tenants robustly by design throughout all tiers Limit resource consumption by
user or service
11.A04 Insecure Design - Attack Scenario 1: A credential recovery workflow might include "questions and
answers," which is prohibited by NIST 800-63b, the OWASP ASVS, and the OWASP Top 10. Questions and answers
cannot be trusted as evidence of identity as more than one person can know the answers, which is why they are
prohibited. Such code should be removed and replaced with a more secure design.
12.A04 Insecure Design - Attack Scenario 2: A cinema chain allows group book- ing discounts and has a maximum
of fifteen attendees before requiring a deposit. Attackers could threat model this flow and test if they could book six
hundred seats and all cinemas at once in a few requests, causing a massive loss of income.
13.A04 Insecure Design - Attack Scenario 3: A retail chain's e-commerce website does not have protection against
bots run by scalpers buying high-end video cards to resell auction websites. This creates terrible publicity for the video
card makers and retail chain owners and enduring bad blood with enthusiasts who cannot obtain these cards at any price.
Careful anti-bot design and domain logic rules, such
as purchases made within a few seconds of availability, might identify inauthentic purchases and rejected such
transactions.
14.A05 Security Misconfiguration: The application might be vulnerable if the application is:
Missing appropriate security hardening across any part of the application stack or
