Ein-des-ein blog

Top Web Security Vulnerabilities and How to Avoid Them

Hanna Milovidova
Top Web Security Vulnerabilities and How to Avoid Them

Today’s websites have an extensive range of functions and business opportunities, as well as web security issues compared to their grandparents from the year 2000. Could we imagine doing our banking or registering for a doctor’s appointment through websites? Doubtful. 

However, as in any situation, there is a flip side to the coin. As web technologies have evolved, malware has evolved as well. Today websites process a lot of sensitive user information – credit card numbers, insurance policy numbers, geolocation, and much more. The loss of such data can threaten a company’s reputation, cause lawsuits, and, in the end, substantial financial losses. This is the reason why web app security has become a critical aspect in the development communities.


You might have heard that to protect against web attacks, an application or website should be developed according to OWASP guidelines. Let’s find out what OWASP is.

What is OWASP?

OWASP (Open Web Application Security Project) is an online community that publishes articles on web development security and vast documentation, guidelines for development and testing during all SDLC phases, as well as various tools and technologies. 

Following these guidelines has become synonymous with high-quality and secure code. It guarantees that the most common website security risks do not threaten your site.

Types of security vulnerabilities

  1. SQL Injection
  2. Broken Authentication
  3. Sensitive Data Exposure Threats
  4. External Entities XML (XXE)
  5. Application Misconfiguration
  6. Insecure Deserialization
  7. Session Riding Attacks
  8. Using Components with Known Security Issue
  9. Missing Function Level Access Control
  10. Insufficient Logging & Monitoring

Even the world’s most secure software can suffer cyber-attacks. However, according to OWASP, there are the top 10 web applications security vulnerabilities through which cyber criminals more often carry out their malicious activities. 

SQL Injection

An attacker injects invalid data into a web application to make it do something the application was not designed/programmed for. The most common type of this web application threat is code injection via an SQL query (SQL injection) that uses unreliable data. The main reason for this software security vulnerability is the lack of validation and cleanup of the data used by the web application. This means that this vulnerability is present in any type of technology. 

 Anything that accepts parameters as input could potentially be the target of a similar attack.

How to protect your website

The ability to prevent code injection depends on the technology you use on your site. For example, if you use WordPress, you can minimize potential problems by limiting the number of installed plugins.

If you are in the development stage, it is always better to turn to highly qualified professionals. A team of top-talented developers will help form the security requirements, which will later be followed when writing the software. 

Broken Authentication

This web security threat lies in that an attacker, using manual or automatic methods, can gain control over any account or, even worse, over the system. This is one of the most common types of website vulnerabilities. Authentication breaches are usually related to logical problems in the authentication mechanism, such as poor session management where usernames are enumerated. In this case, the attacker uses brute-force techniques to guess the system’s user data. This vulnerability’s second most common manifestation allows users to use username and password matching for site pages.

Common reasons for creating insecure code containing such vulnerabilities are usually:

  • Developers’ lack of experience 
  • Lack of security requirements
  • Rush to release the product

How to protect your website

To avoid problems related to incorrect authentication, make sure that developers are implementing best practices for site security and have sufficient time to properly test the code before deploying the application in a production environment.

OWASP technical recommendations
  • If possible, implement multi-factor authentication to prevent automated attacks by attackers.
  • Do not use default credentials, especially for administrator roles.
  • Implement password strength checks, including testing new or changed passwords against the 10,000 worst passwords list.

Sensitive Data Exposure Threats

The vulnerability of critical data is one of the most common vulnerabilities. It’s primarily about sensitive data, which requires special attention and protection. These web attacks usually target credit card numbers, medical information, personally identifiable information, etc.

Over the past few years, the disclosure of confidential data has become one of the most common web security threats worldwide. The lack of encryption of sensitive data is the main reason why these attacks still happen so often. Even encrypted data can be compromised because of:

  • Unprotected key generation and management process
  • Vulnerable algorithms, protocols, and ciphers used in web app processes
  • Unsafe password storage methods.

Examples of attack scenarios

Scenario #1. 

The application automatically encrypts credit card numbers in the database. However, when received, this data is automatically decrypted, allowing the vulnerability of the SQL injection to receive credit card numbers in plain text.

Scenario #2. 

The site does not use TLS for all pages or supports weak encryption. The attacker monitors network traffic (e.g., on an unsecured wireless network), downgrades the connection from HTTPS to HTTP, intercepts requests, and steals the user’s session cookie. The attacker then replays those cookies and hijacks the user’s session (already authenticated), gaining access to the user’s private data.

How to protect your website

  • Do not store confidential data unnecessarily. Data that is not stored cannot be stolen.
  • Ensure up-to-date and reliable standard algorithms, protocols, and keys are in place; use proper key management.
  • Encrypt all transmitted data using secure protocols, such as TLS, with secure parameters and server prioritization of encryption
  • Disable caching for responses containing sensitive data
  • Store passwords using powerful adaptive and “salted” hashing functions such as Argon2, scrypt, bcrypt or PBKDF2

External Entities XML (XXE)

The website security threats occur when a poorly configured XML parser processes XML input containing a reference to an external object. Most XML parsers are vulnerable to XXE attacks by default. It is primarily the responsibility of the developer to ensure that the application does not contain this vulnerability.

Attack vectors for external XML objects

According to the OWASP Top 10, the main attack vectors for external XML objects (XXE) include the use of:

  • Vulnerable XML processors (attackers can load XML or include malicious content in an XML document)
  • Unprotected code
  • Vulnerable dependencies and integrations

How to protect your website

  • Implement server-side positive validation (“whitelisting”) of input data and filtering to prevent malicious data from being used in XML documents, headers, or nodes.
  • Ensure that the XML or XSL upload function validates incoming XML using XSD or a similar tool.
  • Use SAST tools to help detect XXE in the source code (although manual code checking is a better alternative in large and complex applications with many integrations).

Application Misconfiguration

There are many variants of this attack, and the most common is brute force. In its essence, this is an attempt to enter many possible combinations. Here are the reasons that can make this kind of web attack successful:

  • Uncorrected flaws in the code
  • Use of default configuration
  • Existence of unused pages
  • Unprotected files and directories
  • Unnecessary services used

One of the most common mistakes webmasters make is keeping the default CMS settings. Modern CMS applications, while easy to use, can be insecure for end users. Most web attacks are fully automated, and attackers rely on users having default settings. This means that many website security threats can be wiped out by changing the default settings when installing the CMS.

File permissions are another place, which should be enforced in the use of default settings.

Vulnerable objects

Security misconfigurations can occur at any level of the application stack:

  • Network services
  • The platform
  • Web server
  • The application server
  • Database
  • Frameworks
  • User code
  • Pre-Installed virtual machines
  • Containers
  • Stores

One example of application misconfiguration is Memcached servers used for DDoS attacks on services in the technology industry.

Examples of attack scenarios

Scenario #1 

The server comes with sample applications that have known security flaws. Attackers can break into the server if one of these is the administrator console (and the default accounts have not been changed). The attacker logs in with the default passwords and takes control.

Scenario #2

The cloud provider has sharing permissions by default. This allows attackers to access sensitive data in cloud storage.

How to protect your website

  • Regularly check and update configurations to meet all security requirements. In particular, review permissions for cloud storage.
  • Create applications with a segmented architecture that provides efficient and secure separation between components or clients
  • Automated process for checking the efficiency of configurations and settings in all environments

Insecure Deserialization

The OWASP Top-10 notes that this web vulnerability was added to the list based on the results of an industry survey, not a study of quantifiable data.

Attackers will always try to “play” with everything interacting with an application, from URLs to serialized objects.

What is deserialization

To simplify understanding some of the key concepts, let’s introduce you to the accepted terminology:

  • The OWASP Top-10 notes that this vulnerability was added to the list based on the results of an industry survey, not a study of quantifiable data.
  • The serialization process is the conversion of objects into byte strings.
  • The deserialization process is the conversion of byte strings into objects.

Examples of deserialization attack scenarios

Scenario #1

The React application calls a set of Spring Boot microservices. Being functional programmers, the developers tried to ensure that their code remained consistent. The solution they came up with was to serialize the user state and pass it back and forth with each request. The attacker notices the signature of the “R00” object and uses the Java Serial Killer tool to execute the code on the application server remotely.

Scenario #2

The PHP forum uses the serialization of an object to store a supercookie containing the user’s ID, role, password hash, and other states. Then the attacker modifies the serialized object to gain administrator rights.

One of the attack vectors is a supercookie that contains serialized information about the logged-in user. This cookie specifies the user’s role.

When an attacker successfully deserializes this object, he or she changes the user’s permissions, gives himself the administrator’s role, and serializes the object again. This set of actions can create a considerable website security threat.

How to protect your website

  • Implement integrity checks on any serialized objects to detect the creation of malicious objects or tampered data
  • Enforcing strict restrictions during deserialization
  • Restricting or monitoring inbound and outbound network connections from deserialized containers or servers 
  • Monitoring deserialization – alerting if a user is performing deserialization all the time

Session Riding Attacks

One of the most widespread session Riding or session hijacking attacks is a cross-site scripting (XSS) software attack. XSS is a standard web security issue that affects many sites. XSS attacks involve injecting malicious client scripts into a site and then using the site as a distributor.

The risks associated with this web vulnerability allow an attacker to inject content into the site and change its display. It forces the victim’s browser to execute code provided by the attacker when the page loads.

XSS vulnerabilities are present in about two-thirds of all applications. Typically, they require some type of user interaction, which must be initiated either through social engineering or by visiting a specific page. An unpatched XSS vulnerability can be very dangerous for any site.

According to the OWASP Top 10, there are three types of cross-site scripting:

Session Riding Attacks

Reflected XSS: 

The application or API includes unverified and unscreened user input in the HTML output. A successful attack will allow the attacker to load arbitrary HTML and execute JavaScript in the victim’s browser. Typically, the user needs to interact with some malicious link to a page controlled by the attacker.

Stored XSS:

An application or API stores raw user input that another user or administrator later views. Stored XSS code is often considered high or critical risk.

DOM XSS: 

JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controlled data are vulnerable to DOM XSS.

How to protect your website

  • Use frameworks designed without using XSS. 
  • Enabling a content security policy (CSP) is comprehensive protection that reduces the risk of XSS attacks. 
  • Applying context-sensitive coding when modifying a client-side browser document

Using Components with Known Security Issue

These days, even simple sites, such as personal blogs, have many integrations with third-party services, plugins, and other applications that can become a site of attack.

Not being able to update every piece of software on the server and client-sides of a site, sooner or later, creates serious security risks.

In 2019, 56% of all CMS applications were out of date when they were infected.

Using Components with Known Security Issue

The reasons for the existence of this vulnerability

  • Webmasters/developers can’t keep up with updates (after all, proper updates take time).
  • Outdated code will not work with newer versions of its dependencies.
  • Webmasters are afraid that their site will stop functioning correctly.
  • Webmasters don’t have the expertise to install updates correctly.

It may sound overly dramatic, but every time you ignore an update warning, you allow an already known vulnerability to survive on your system. Trust me, cybercriminals are quick to investigate software and change lists.

How to protect your website

  • Remove all unnecessary dependencies
  • Make an inventory of all your components – both server-side and client-side
  • Purchase components only from official sources
  • Remove components that are not actively used
  • Use virtual patches

Missing Function Level Access Control

Most content management systems (CMS) are subject to this web security threat. By default, everyone has access to the admin login page. In most cases, even the two-factor authentication (2FA) method is not used.

Examples of violated access control

Here are a few examples of what we include in the concept of access:

  • Access to the hosting control panel/administrative panel
  • Access to the server via FTP/SFTP/SSH
  • Access to your site’s administrative panel
  • Access to other applications on your server
  • Database access.

Attackers can use authorization flaws for the following purposes:

  • Accessing unauthorized features and/or data.
  • Viewing sensitive files
  • Changing access rights

How to protect your website

To protect against this vulnerability, you need to follow the security principles described in OWASP during the design and configuration of the site. 

  • Implement access control mechanisms and use them in all phases of the application. Minimize the use of CORS
  • Disable the webserver directory list and make sure that file metadata (such as .git) and backup files are not in the root directory of the webserver
  • Limit the frequency of API requests to minimize damage from automated attacks.

Insufficient Logging & Monitoring

The importance of web security cannot be underestimated. While 100 percent security is not an achievable goal, there are ways to keep your website under constant monitoring so that you can take immediate action when something happens.

Eventually, a lack of adequate monitoring can lead to increased damage from a website hack.

Attacks Scenario

Scenario #1

An open-source platform run by a small team was hacked using a vulnerability in its software. The attackers managed to destroy the internal repository with all the contents inside. The content could be recovered, but the lack of monitoring led to much more severe consequences. 

Scenario #2

Attackers are looking for users with a shared password. They can access all accounts with that password. For all other users, this scan leaves only one false login. After a few days, the process repeats, but with a different password.

How to protect your website

Keeping audit logs allows you to be aware of any suspicious changes. This is a document in which all events occurring on the site are recorded. It enables you to detect any anomalies so that you can contact a specialist in time to confirm or deny a website attack.

How to prevent web application security threats?

As you can see, modern websites have a massive number of web security vulnerabilities, and we have listed only the most common ones. To ensure that your site is protected, you need to entrust its development to experts who use OWASP guidelines and strictly follow them.

Ein-des-ein banner

If you want to build anew or refresh your website, let us know and get a free consultation! Our team is experienced in developing, rebranding, and improving websites and web platforms.

Follow us!

Interested in our monthly newsletter? Get the insights, updates and discounts right into your inbox only once a month.



    ein-des-ein needs the contact information you provide to us to contact you about our products and services. You may unsubscribe from these communications at any time. For information on how to unsubscribe, as well as our privacy practices and commitment to protecting your privacy, please review our Privacy Policy.