OWASP Top 10: the most common web vulnerabilities explained

The OWASP Top 10 is the standard reference list of the ten most critical security risks for web applications, maintained by the non-profit organisation OWASP (Open Worldwide Application Security Project). The list serves development teams and security professionals as a starting point for identifying and remediating the most common vulnerabilities before attackers can exploit them. The current version was released in 2021 and groups the risks into ten broad categories.

In this article we explain each of the ten categories in plain language, with a concrete example and practical protection steps. The text is intended for business owners, IT teams and developers in Mostar, BiH and the wider region who want to understand where their web applications are most vulnerable.

What the OWASP Top 10 is and why it matters

OWASP is a global community that freely publishes tools, documentation and guidelines for software security. Its best known publication is precisely the OWASP Top 10 list, which is periodically updated based on data collected from hundreds of organisations and security teams around the world.

It is important to understand that the OWASP Top 10 is neither an exhaustive security standard nor a checklist that guarantees complete protection. It is a list of risk categories that appear most frequently and cause the greatest damage. If your application has none of these ten weaknesses, that is an excellent foundation, but not a guarantee of perfect security. For that reason, a serious penetration test goes beyond the list itself.

The OWASP Top 10 list for 2021

The following table provides an overview of all ten categories by their official identifiers. A more detailed explanation of each follows below the table.

Identifier	Category	In brief
A01	Broken Access Control	A user can access data or actions beyond their authorisation
A02	Cryptographic Failures	Weak or non-existent protection of sensitive data
A03	Injection	Untrusted data is executed as a command (e.g. SQL injection)
A04	Insecure Design	Security flaws built into the application design itself
A05	Security Misconfiguration	Incorrect settings for the server, database or application
A06	Vulnerable and Outdated Components	Outdated libraries and components with known vulnerabilities
A07	Identification and Authentication Failures	Weaknesses in login and session management
A08	Software and Data Integrity Failures	Untrusted updates, packages and serialised data
A09	Security Logging and Monitoring Failures	Insufficient logging and monitoring prevent attack detection
A10	Server-Side Request Forgery (SSRF)	The server is tricked into sending requests to unintended destinations

Detailed explanation of each category

A01: Broken Access Control

This is currently the most common vulnerability category. It covers situations in which the application does not properly verify whether a user is entitled to a particular action or piece of data. A typical example: a user changes the number in the URL from /racun/123 to /racun/124 and sees someone else's invoice. Protection is achieved by verifying authorisation on the server side for every request, applying the principle of least privilege and denying access by default.

A02: Cryptographic Failures

Previously known as Sensitive Data Exposure. It refers to sensitive data (passwords, card numbers, personal data) that is not adequately encrypted in transit or at rest. Examples include sending data without HTTPS, storing passwords in plain text or using outdated algorithms. Protection: TLS on all connections, encryption of sensitive data in the database and hashing passwords with a modern algorithm such as bcrypt or Argon2.

A03: Injection

This occurs when an application passes untrusted user input to an interpreter as part of a command. The best known form is SQL injection, where an attacker injects part of an SQL query through an input field and thereby reads or modifies the database. This category also includes Cross-Site Scripting (XSS). Protection is achieved through parameterised queries (prepared statements), input validation and correct output encoding.

A04: Insecure Design

This category emphasises that some vulnerabilities are not a flaw in the code, but in the design of the system itself. An example is a password recovery process that relies on security questions with easily guessable answers. You cannot patch such flaws afterwards without changing the logic. The solution is threat modeling already during the application planning phase.

A05: Security Misconfiguration

This covers everything from open administrative interfaces and default passwords to detailed error messages that reveal the structure of the system. A very common problem among companies in the region is servers put into production with default settings. Protection: remove unnecessary services, change default credentials, disable detailed errors in production and regularly review the configuration.

A06: Vulnerable and Outdated Components

Modern applications consist of dozens of external libraries and frameworks. If any one of them has a known vulnerability and has not been updated, the entire application is exposed. This is especially dangerous because attacks often exploit publicly disclosed vulnerabilities for which ready-made tools already exist. Protection: maintain an inventory of all components, monitor security advisories and update regularly.

A07: Identification and Authentication Failures

This refers to weaknesses in the login process: allowing weak passwords, the absence of protection against password guessing (brute force) and poor session management. Protection includes multi-factor authentication (MFA), limiting the number of login attempts and securely managing session tokens.

A08: Software and Data Integrity Failures

This occurs when an application trusts software, updates or data from untrusted sources without verifying integrity. An example is automatically downloading an update without checking its digital signature, which allows an attacker to plant malicious code. Protection: digital signatures, verified repositories and software supply chain control.

A09: Security Logging and Monitoring Failures

Without quality logs and monitoring, an attack can go unnoticed for days or months. Many companies only discover a breach when someone outside the organisation informs them. Protection: log all security-relevant events, store the logs in a secure location and set up alerts for suspicious patterns. It is precisely in this area that the continuous monitoring provided by the Guardian 360 SOC service comes into its own.

A10: Server-Side Request Forgery (SSRF)

The newest entry on the list. It occurs when an attacker tricks the server into sending a request to a destination of their choosing, for example to internal systems that are not otherwise accessible from outside. This can be used to reach internal metadata or unprotected services. Protection: validate and filter all URLs the server uses, along with network segmentation.

How these vulnerabilities combine in a real attack

In practice, attackers rarely exploit just one vulnerability. Far more often they chain them one after another to reach their goal. Understanding these combinations helps clarify why security must be viewed as a whole rather than category by category.

Imagine a typical scenario at the web shop of a retailer from the region. The attacker first finds a product search form that is not protected against injection (A03: Injection) and uses it to read the user table from the database. The passwords are, unfortunately, stored without modern hashing (A02: Cryptographic Failures), so they are easily uncovered. Since the site has no protection against repeated login attempts and no multi-factor authentication (A07), the attacker logs in as an ordinary user. They then notice that by changing the identifier in the address they can access other people's orders (A01: Broken Access Control). Finally, because the company does not monitor its logs or traffic (A09), the entire process goes unnoticed for weeks.

This example illustrates the key message: individually, each weakness may seem moderate, but in combination it leads to a complete compromise of the system and a leak of customer data. This is exactly why a proper assessment looks at how vulnerabilities build on one another.

How to identify these vulnerabilities in your own application

Understanding the list is the first step, but the real value comes from applying it. Here are practical steps a company can start with:

• Inventory of applications and components: list all the web applications, libraries and services you use. You cannot protect what you do not know about.
• Automated scanning: static and dynamic analysis tools detect part of the vulnerabilities on the list, especially injection and outdated components.
• Manual penetration testing: automated tools do not detect logic flaws such as Broken Access Control or Insecure Design. Here an expert hand is essential.
• A regular cycle: security is not a one-off project. New vulnerabilities emerge constantly, so testing needs to be repeated.

For many companies in BiH the greatest challenge is not a lack of awareness, but a lack of time and specialised staff. This is where working with a specialised team helps. If you want to find out where you stand, you can fill in our penetration test questionnaire and receive a scope assessment.

How to set remediation priorities

Once you have identified the vulnerabilities, the next challenge is deciding what to address first. Not all of them carry the same weight. It is useful to assess each one through two questions: how easy is the weakness to exploit, and how much damage results if it is. A weakness that is easy to exploit and leads to a leak of personal data has the highest priority, while a theoretical vulnerability with low impact can wait.

In practice, we advise companies to start with categories A01, A02 and A03, because they are the most common and have a direct impact on user data. Only after that should configuration and process flaws be addressed. This priority-based approach prevents resources from being wasted on less important items while critical ones remain open.

Penetration testing as a verification

A professional penetration test regularly uses this list as a starting framework, but builds on it with real attack scenarios tailored to your application. The test shows not only which vulnerabilities exist, but also what real impact they can have if an attacker exploits them in combination. The result is a prioritised report with concrete remediation recommendations, giving your team a clear plan of action.

For organisations preparing for a certification such as ISO 27001, regular testing of web applications is often a formal requirement as well. If you need a security assessment of your systems, feel free to contact us and we will arrange a discussion about the scope and objectives.

Frequently asked questions

What is the OWASP Top 10?

The OWASP Top 10 is a list of the ten most common and most critical security risks for web applications, maintained by the OWASP organisation. It serves development teams and security professionals as a reference framework for identifying and remediating vulnerabilities. The current version was released in 2021.

How often is the OWASP Top 10 list updated?

The list is not updated on a fixed schedule, but periodically, roughly every few years, once enough new data on real vulnerabilities has been gathered. Previous major versions were released in 2013, 2017 and 2021. Categories are merged, renamed or added over time as attack patterns change.

Does compliance with the OWASP Top 10 mean the application is completely secure?

No. The OWASP Top 10 covers the most common risks, but it is not an exhaustive security standard. An application can be resilient against all ten categories and still have specific logic flaws or vulnerabilities outside the list. The list is an excellent minimum, but only a thorough penetration test provides the complete picture.

Do companies outside the IT sector also need to understand the OWASP Top 10?

Yes. Any company that has a website, web shop or customer portal is exposed to these risks, regardless of its line of business. Owners and management do not necessarily need to know the technical details, but it is useful to understand that standard risks exist and that they should be checked regularly, especially if the application processes users' personal data.

Related guides: Cyber security in BiH - the complete guide · Black box, white box and grey box testing - the differences · Penetration testing vs vulnerability scanning - which to choose