Top 10 Web Application

Security Risks
Who is the OWASP® Foundation?

• 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
Top 10 Web Application Security Risks
A01:2021-Broken Access Control
• Access control enforces policy such that users cannot act outside of
their intended permissions.
• Failures typically lead to unauthorized information disclosure,
modification, or destruction of all data or performing a business
function outside the user's limits.
A01:2021-Broken Access Control
• 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
• Permitting viewing or editing someone else's account, by providing its unique
identifier (insecure direct object references)
• Elevation of privilege.
• Etc.
How to Prevent
1. Continuous Inspection and Testing Access Control
2. Deny Access By Default
3. Limiting CORS(Cross-Origin Resource Sharing) Usage .
4. Model access controls should enforce record ownership rather than accepting that the user can
create, read, update, or delete any record.
5. Enable Role-based Access Control:
This is a widely used access control mechanism. According to this, users are given permissions
based on their roles. Instead of identifying each user individually, users are assigned to a group of
roles, this way the struggle of IT support and administration can be reduced, and operational
efficiency will be maximized.
6. Enable Mandatory access control:
It is a security method, that restricts the ability to access resources based on the sensitivity of the
information, that the resource contains. This security policy can only be controlled by the
administrator, regular users don’t have the ability to change that policy. Because of this centralized
 Example Attack Scenarios
• Scenario #1: The application uses unverified data in a SQL call that is
accessing account information:
• An attacker observes the following request made by the application when
loading their banking dashboard.
• https://mybankingapp.test/cgi-bin/hpe.py?accountId=4462
• The attacker modifies the request to use the bank account number of
another user by changing the accountID parameter from 4462 to 4463.
• https://mybankingapp.test/cgi-bin/hpe.py?accountId=4463
• The application's response provides the attacker with another person's
account details.
• {“AccountID”: 4463, “Balance”: “$167,183.09”}
Example Attack Scenarios
• 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.
A02:2021-Cryptographic Failures
• The first thing is to determine the protection needs of data in transit
and at rest.
• For example, passwords, credit card numbers, health records, personal
information, and business secrets require extra protection,
• EU's General Data Protection Regulation (GDPR), or regulations, e.g.,
financial data protection such as PCI Data Security Standard (PCI
DSS).
Protecting Data in Transit
• Both types of data should be protected. When considering data
in transit, one way to protect it on a website is by having an SSL
certificate.
• SSL is the acronym for Secure Sockets Layer. It is the standard
security technology for establishing an encrypted link between
a web server and a browser. SSL certificates help protect the
integrity of the data in transit between the host (web server
or firewall) and the client (web browser).
• Guide to help every website owner learn how to install an SSL
certificate. https://sucuri.net/guides/how-to-install-ssl-
certificate/
 Example Attack Scenarios

• 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.
• 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.
Example Attack Scenarios

• Scenario #3: The password database uses unsalted 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
Why is Cryptographic Failure so
common?
• Over the last few years, sensitive data exposure has been
one of the most common attacks around the world. Some
examples of data leaks exposed sensitive data include:
• The Equifax data breach of 2017 resulted in the compromise of
personal information of nearly 150 million Americans, over 15
million British citizens and almost 20,000 Canadians. In a resulting
lawsuit the firm was ordered to pay over half a billion dollars in
fines/payouts. One law firm launched the largest class action
lawsuit in US history against Equifax seeking up to $70 billion USD
in damages
 Why is Cryptographic Failure so
common?
• In June of 2021 LinkedIn reported that information from 90% of its user
base was compromised and posted on the dark web. Fortunately no
sensitive personal information was compromised, but the leaked details
included things like email addresses, phone numbers and geolocation data
(certainly enough to aid hackers in spear phishing campaigns).
• Clocking in as the most severe data breach of all time: Yahoo! reported that
years prior their entire user 3-billion-strong base had been compromised.
Specific details of material taken include names, email addresses, telephone
numbers, encrypted or unencrypted security questions and answers, dates
of birth, and hashed passwords. The company was in the middle of being
acquired by Verizon at the time and the reported breach cost Yahoo! $350
million USD, not including a litany of class action lawsuits launched against
the company.
A02:2021-Cryptographic Failures
• Non-encrypted sensitive data is the main reason these
attacks are so widespread. However, even if data is
encrypted, it can still be broken due to weak areas like:
● Key generation process
● Key management process
● Algorithm usage
● Protocol usage
● Cipher usage
● Password hashing storage techniques
• This vulnerability is difficult to exploit; however, the
consequences of a successful attack are profound
 How to Prevent
Some of the ways to prevent data exposure, according to OWASP,
are:

• Classify the data processed, stored, or transmitted by an application.

• Identify what data is sensitive according to privacy laws, regulatory
requirements, or business needs.
• Apply controls as per the classification.
• Don’t store sensitive data unnecessarily.
• Discard sensitive data as soon as possible or use PCI DSS-compliant
tokenization or truncation. Remember: data that is not retained cannot
be stolen.
• Make sure to encrypt all sensitive data at rest.
 How to Prevent
• Ensure that up-to-date and strong standard algorithms, protocols, and keys are in
place; use proper key management.

• Encrypt all data in transit with secure protocols such as TLS with perfect forward
secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters.

• Enforce encryption using directives like HTTP Strict Transport Security (HSTS).

• Disable caching for responses that contain sensitive data.

• Store passwords using strong adaptive and salted hashing functions with a work
factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2.

• Verify independently the effectiveness of configuration and settings

 3- A03:2021– Injection
• A code injection happens when an attacker sends invalid data
to the web application with the intention of making it do
something that the application is not designed/programmed to
do.
• The most common example around this security vulnerability is
the SQL query consuming untrusted data
• SQL injection attack
 4 – A04:2021 – Insecure Design
• A new addition to the OWASP Top Ten, clocking in at number
four on the list, is insecure design.
• This focuses on the ground-up development of web applications
from the very beginning of its life cycle.
• This is not to be confused with insecure implementation of web
applications or policies.
• It is, essentially, the avoidance of hard-coded security protocols
and methods within the initial development of a web application,
• as well as the failure to take into account risks and attack vectors
during the planning, development, and implementation of a web
application.
Examples of Insecure Design
• Most CMS platforms, including WordPress, do not limit the number
of failed logins on the administrator panel. This renders them
particularly vulnerable to brute force attacks and requires the
installation of third-party security extensions to mitigate.
• Many CMS platforms use a default administrator panel URL. For
example, wp-admin in WordPress and administrator in Joomla.
• Many eCommerce platforms do not contain built-in protection
from automated bot transactions. This renders them vulnerable to
both scalpers buying up tickets or computer components, and
attackers testing stolen credit card details on victim websites.
 How to Prevent Insecure Design
• “Secure design is a culture and methodology that constantly evaluates threats and
ensures that code is robustly designed and tested to prevent known attack
methods”
• By taking security into account from the very bedrock of the development of a
web application, many easily preventable risks can be avoided. Secure design
is not a ruleset nor a tool, it is a culture, mindset and methodology.
• Security specialists should be consulted at the beginning of a project and
throughout the entire development lifecycle
• Make heavy usage of threat modeling
• Consider potential attack vectors and the level of exposure that your web
application will have
• Analyze (and re-analyze) all data flows, particularly ones that resist the threat
modeling
• Use a href=”https://owaspsamm.org/SAMM” as a guide to development
5 – Security Misconfigurations
• Moving up from #6 in the previous edition, 90% of applications were
tested for some form of misconfiguration, with an average incidence
rate of 4.%.
• One of the most common webmaster flaws is keeping the CMS default
configurations.
The application might be vulnerable if the
application is:
• Missing appropriate security hardening across any part of the application stack or improperly
configured permissions on cloud services.
• Unnecessary features are enabled or installed (e.g., unnecessary ports, services, pages, accounts,
or privileges).
• Default accounts and their passwords are still enabled and unchanged.
• Error handling reveals stack traces or other overly informative error messages to users.
• For upgraded systems, the latest security features are disabled or not configured securely.
• The security settings in the application servers, application frameworks (e.g., Struts, Spring,
ASP.NET), libraries, databases, etc., are not set to secure values.
• The server does not send security headers or directives, or they are not set to secure values.
HTTP Strict Transport Security header (HSTS)
• The software is out of date or vulnerable (see A06:2021-Vulnerable and Outdated Components)
Where Can Security
Misconfiguration Happen?
Misconfiguration can happen at any level of an application stack,
including:
● Network services
● Platform
● Web server
● Application server
● Database
● Frameworks
● Custom code
● Pre-installed virtual machines
● Containers
● Storage
 Examples of Security
Misconfiguration Attacks
• Scenario #1: The application server comes with sample applications that are
not removed from the production server. These sample applications have
known security flaws that attackers use to compromise the server. If one of
these applications is the admin console and default accounts weren’t
changed, the attacker logs in with default passwords and takes over.
●Scenario #2: Directory listing is not disabled on the server. An attacker
discovers they can simply list directories. They find and download the
compiled Java classes, which they decompile and reverse engineer to view the
code. The attacker then finds a serious access control flaw in the application.
• Scenario #3: The application server’s configuration allows detailed error
messages, e.g. stack traces, to be returned to users. This potentially exposes
sensitive information or underlying flaws, such as component versions. They
are known to be vulnerable.
How to Secure Installation Systems
In order to prevent security misconfiguration use
• A repeatable hardening process that makes it fast and easy to deploy another
environment that is properly locked down. Development, QA, and production
environments should all be configured identically, with different credentials used in
each environment.
• A minimal platform without any unnecessary features, components, documentation,
and samples. Remove or do not install unused features and frameworks.
• A task to review and update the configurations appropriate to all security notes,
updates, and patches as part of the patch management process. In particular, review
cloud storage permissions.
• Sending security directives to clients, e.g. Security Headers.
• An automated process to verify the effectiveness of the configurations and settings in
all environments.
6 – Vulnerable and Outdated
Components
• It was #2 from the Top 10 community survey but also had enough data
to make the Top 10 via data.
• Even simple websites such as personal blogs have a lot of
dependencies, plugins, extensions and third-party code.
Failing to update every piece of software on the backend and
frontend of a website will introduce heavy security risks
sooner rather than later.
• Attackers actively seek out websites using vulnerable
components and aggressively exploit them to spread
malware, spam and phishing.
You are likely vulnerable:
• If you do not know the versions of all components you use (both client-side and server-
side).
• If the software is unsupported, or out of date. This includes the OS, web/application
server, database management system (DBMS), applications, APIs and all components,
runtime environments, and libraries.
• If you do not scan for vulnerabilities regularly and subscribe to security bulletins related
to the components you use.
• If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a
risk-based, timely fashion. This commonly happens in environments when patching is a
monthly or quarterly task under change control, leaving organizations open to days or
months of unnecessary exposure to fixed vulnerabilities.
• If software developers do not test the compatibility of updated, upgraded, or patched
libraries.
How to Prevent
There should be a patch management process in place to:
• Remove unused dependencies, unnecessary features, components, files, and documentation.
• Continuously inventory the versions of both client-side and server-side components (e.g.,
frameworks, libraries) and their dependencies using tools like versions, OWASP
Dependency Check, retire.js, etc.
• Continuously monitor sources like Common Vulnerability and Exposures (CVE) and
National Vulnerability Database (NVD) for vulnerabilities in the components. Subscribe to
email alerts for security vulnerabilities related to components you use.
• Only obtain components from official sources over secure links.
• Monitor for libraries and components that are unmaintained or do not create security
patches for older versions. If patching is not possible, consider deploying a virtual patch to
monitor, detect, or protect against the discovered issue.
Example Attack Scenarios
• Scenario #1: Components typically run with the same privileges as
the application itself, so flaws in any component can result in serious
impact. Such flaws can be accidental (e.g., coding error) or intentional
(e.g., a backdoor in a component).
• There are automated tools to help attackers find unpatched or
misconfigured systems. For example, the Shodan IoT search engine
can help you find devices that still suffer from Heartbleed
vulnerability patched in April 2014.
7 – Identification and Authentication
Failures
• Previously number two on the OWASP list, “broken authentication” has
been renamed to this and now ranked at number seven.
• A broken authentication vulnerability can allow an attacker to use
manual and/or automatic methods to try to gain control over any
account they want in a system – or even worse – to gain complete
control over the system.
• Websites with broken authentication vulnerabilities are very common
on the web.
• Broken authentication usually refers to logic issues that occur on the
application authentication’s mechanism, like bad session management
prone to username enumeration – when a malicious actor uses brute-
force techniques to either guess or confirm valid users in a system.
Identification and Authentication
Failures
• To minimize authentication failure risks avoid leaving the login
page for admins publicly accessible to all visitors of the
website:
● /administrator on Joomla!
●/wp-admin/ on WordPress
●/index.php/admin on Magento
●/user/login on Drupal.
• Brute force username/password combinations against those
pages.
Types of Authentication Failure
Vulnerabilities
These vulnerabilities can come in many forms. A web application contains a
broken authentication vulnerability if it:

• Permits automated attacks such as credential stuffing, where the attacker

has a list of valid usernames and passwords.
• Permits brute force or other automated attacks.
• Permits default, weak, or well-known passwords, such as”Password1″ or
“admin/admin.″
• Uses weak or ineffective credential recovery and forgot-password processes,
such as “knowledge-based answers,” which cannot be made safe.
• Uses plain text, encrypted, or weakly hashed passwords.
• Has missing or ineffective multi-factor authentication (MFA).
Types of Authentication Failure
Vulnerabilities cont.
● Exposes session IDs in the URL (e.g., URL rewriting).
• For example, an airline website might use the following URL:
http://example.com/sale/saleitems?jsessionid=2P0OC2JSNDLPSKHCJUN2JV.
Users may wish to share information about the sale on that page with their friends, so
they email them the link. When the friends follow the link they are unknowingly
gaining access to the entire authenticated session, complete with credit card info.
• Solution: Never put the session ID in a URL. Use POST rather than GET.
● Does not rotate session IDs after successful login.

● Does not properly invalidate session IDs. User sessions or

authentication tokens (particularly single sign-on (SSO) tokens)
aren’t properly invalidated during logout or a period of inactivity.
How do you prevent authentication
failures?
• In order to avoid authentication failure make sure the developers
apply to the best practices of website security. Support them by
providing access to external security audits and enough time to
properly test the code before deploying to production.
• OWASP’s technical recommendations are the following:
• Where possible, implement multi-factor authentication to prevent automated,
credential stuffing, brute force, and stolen credential reuse attacks.
• Do not ship or deploy with any default credentials, particularly for admin
users.
• Implement weak-password checks, such as testing new or changed passwords
against a list of the top 10,000 worst passwords.
• Align password length, complexity and rotation policies with NIST 800-63 B’s
guidelines.
How do you prevent authentication
failures? Cont.
● Limit or increasingly delay failed login attempts. Log all
failures and alert administrators when credential stuffing,
brute force, or other attacks are detected.
● Use a server-side, secure, built-in session manager that
generates a new random session ID with high entropy after
login.
● Session IDs should not be in the URL. Ids should also be
● Securely stored and invalidated after logout, idle, and
absolute timeouts.
8 – Software and Data Integrity Failures

• Another new addition to the 2021 roster is software and data integrity
failures.
• These failures can take many forms, particularly since as the web evolves
it is more and more common to use third party code and services within
web applications.
• These failures can be summarised as follows:
1. Usage of code that does not verify integrity of source
2. Usage of third party plugins where you do not control the source
3. Plugins and extensions from untrusted sources
4. The introduction of or potential for compromise or unauthorised access
5. Auto-updates assume trust of the source
Software and Data Integrity Failures
cont.
• WordPress website administrators make heavy usage out of the official
WordPress repository.
• Other CMS platforms have similar libraries that are used.
• These repositories are all open source and the code is publicly accessible
and able to be analyzed. This is a major advantage but not foolproof.
• Many open source plugins over the last few years have been targeted by
attackers after serious vulnerabilities were discovered within them.
• Common for website owners to use hacked or “nulled” plugins/themes
on their website.
• These are almost always coupled with backdoors that will be used to
compromise the website environment.
Examples of Integrity Failure

• In 2021, attackers were able to circumvent Microsoft’s

verification process and were able to release a digitally
signed driver infected with rootkit
• The SolarWinds hack distributed backdoored software to
thousands of organisations including US government and
hundreds of major corporations
• In 2016 the website of the popular Linux distribution Linux
Mint was hacked and the ISO file replaced with backdoored
version
How to Prevent Integrity Failure

The following principles should be adhered to:

• Use software that was digitally signed by a trusted vendor
• Use trusted software repositories or your own repository
• Verify that your extensions contain no known vulnerabilities
• Verify checksums and file hashes
• Ensure there is a review process for code changes/updates
• Ensure proper access control to ensure data integrity
9 – Security Logging and Monitoring
Failures
• The importance of securing a website cannot be
understated. While 100% security is not a realistic goal, there
are ways to keep your website monitored on a regular
basis.
• This allows you to take immediate action when something
happens.
• Not having an efficient logging and monitoring process in
place can increase the damage of a website compromise.
 Example of Logging and Monitoring
Attack Scenarios
• According to OWASP, these are some examples of attack scenarios due to insufficient
logging and monitoring:
●Scenario #1: An open-source project forum software run by a small team was hacked
using a flaw in its software. The attackers managed to wipe out the internal source
code repository containing the next version and all of the forum contents. Although
the source could be recovered, the lack of monitoring, logging, or alerting led to a far
worse breach. The forum software project is no longer active as a result of this issue.
●Scenario #2: An attacker scans for users with a common password. They can take
over all accounts with this password. For all other users, this scan leaves only one false
login behind. After some days, this may be repeated with a different password.
●Scenario #3: A major U.S. retailer reportedly had an internal malware analysis
sandbox analyzing attachments. The sandbox software had detected potentially
unwanted software, but no one responded to this detection. The sandbox had been
producing warnings for some time before detecting the breach due to fraudulent card
transactions by an external bank.
How to Have Efficient Website
Monitoring
• Keeping audit logs give visibility to suspicious changes to your
website.
• An audit log is a document that records the events in a website so
you can spot anomalies and confirm with the person in charge
that the account hasn’t been compromised.
• Whatever the reason for running out-of-date software on your
web application, you can’t leave it unprotected.
• It’s hard for some users to perform audit logs manually.
• You can use our free WordPress Security Plugin to help you with
your audit logs. The plugin can be downloaded from the official
WordPress repository
10 – Server-Side Request Forgery
• OWASP resource:
• SSRF flaws occur whenever a web application is fetching a remote
resource without validating the user-supplied URL. It allows an attacker
to coerce the application to send a crafted request to an unexpected
destination, even when protected by a firewall, VPN, or another type of
network access control list (ACL).
• As cloud services increase in usage and popularity as well as their
complexity, the prevalence and risk of SSRF attacks increase too.
• As cloud services increase in usage and popularity as well as their
complexity, the prevalence and risk of SSRF attacks increase too.
How to Prevent SSRF in Web
Applications
● Sanitize all user input
● Use a positive allow list rather than a punitive block list
● Do not send raw responses to users/clients
● Disable unencrypted (HTTP) redirections
Example Attack Scenarios
• Attackers can use SSRF to attack systems protected behind
web application firewalls, firewalls, or network ACLs, using
scenarios such as:
• Scenario #1: Port scan internal servers – If the network
architecture is unsegmented, attackers can map out internal
networks and determine if ports are open or closed on
internal servers from connection results or elapsed time to
connect or reject SSRF payload connections.
Scenario #2: Sensitive data exposure – Attackers can access
local files such as or internal services to gain sensitive
information such as file:///etc/passwd.
Example Attack Scenarios cont.
• Scenario #3: Access metadata storage of cloud services –
Most cloud providers have metadata storage such as
http://169.254.169.254/. An attacker can read the metadata
to gain sensitive information.
Scenario #4: Compromise internal services – The attacker
can abuse internal services to conduct further attacks such
as Remote Code Execution (RCE) or Denial of Service (DoS).