Cracking the Code: The 10 Most Exploited Vulnerabilities and How to Mitigate Them

The Role of OWASP in Modern Application Security

The Open Web Application Security Project (OWASP) provides a foundational standard for modern cybersecurity through its widely recognised OWASP Top 10 list. This document is not merely a list but a standard awareness document that represents a broad, data-driven consensus on the most critical security risks facing web applications. The list serves as an essential checklist for developers, security professionals, and organisations striving to build and maintain a mature application security program¹. Its primary purpose is to provide a clear, prioritised framework for identifying and mitigating the most prevalent and impactful security weaknesses, making it a foundational resource for anyone involved in developing or securing web applications.

Figure 1: Comparison between OWASP Top 10 2017 and OWASP Top 10 2021

Figure 1 compares the OWASP Top 10 web application security risks from 2017 to the updated list from 2021. It visualises how the categories have evolved, merged, or been replaced. In the next section, the OWASP Top 10 2021 list will be the focus of a deep dive, covering the definition, business impact, common attack scenarios and vectors, and mitigation strategies for each item.

Deep Dive into the OWASP Top 10 2021

A01:2021 - Broken Access Control

Definition and Business Impact

Broken Access Control represents a failure to properly enforce restrictions on what authenticated users are permitted to do². It allows attackers to bypass authorisation and perform actions outside of their intended permissions, such as accessing other users' accounts, viewing sensitive data, or executing administrative functions. This vulnerability is fundamentally a failure of authorisation (what a user is allowed to do) rather than authentication (verifying a user's identity)³.

The business impact of such a failure can be catastrophic, leading directly to unauthorised information disclosure, data modification, or complete data destruction. Successful exploitation can result in significant data breaches, financial losses, regulatory fines, and severe reputational damage.

Common Attack Scenarios and Vectors

Attackers exploit broken access control vulnerabilities by manipulating application inputs to circumvent security checks that are either missing or improperly implemented. Common vectors include:

URL Manipulation and Force Browsing: An attacker can alter parameters in the URL or directly browse to "hidden" or privileged pages that are not linked from the main user interface. If the server fails to verify authorisation for each request, the attacker can gain access to administrative functions or other users' data⁴. For example, an attacker might change a URL from https://app.com/user/dashboard to https://app.com/user/admin to gain unauthorised access to the administration panel.

Figure 2: Normal User with No Admin Functions in Web User Interface

Figure 3: Normal User Gained Unauthorized Access to Admin Functions via URL Manipulation and Force Browsing to Admin Page

Insecure Direct Object References (IDOR): This is a specific and highly common form of broken access control where an application exposes a direct reference to an internal implementation object, such as a database primary key or a file path, in a URL or API request. An attacker can manipulate this reference to access unauthorised data. A classic example is an e-commerce site using a URL like https://companyname.com/account-payments?id=5436. By simply changing the id parameter to 5437, an attacker could potentially view the payment information of another customer if server-side authorisation checks are absent⁵.

These attack vectors consistently exploit a single fundamental flaw, which is the failure to enforce authorisation on the server side for every single request. Developers sometimes mistakenly believe that hiding a link or button on the user interface is a sufficient security measure, but attackers can easily bypass such client-side controls using proxy tools to craft and send arbitrary requests directly to the server.

Mitigation Strategies

Mitigating broken access controls requires a multi-layered, defense-in-depth approach embedded in the application's architecture and consistently enforced.

Deny by Default: The foundational principle is to deny access to all resources and functions by default. Explicit grants should be required for a user to access any specific resource.
Implement the Principle of Least Privilege (PoLP): Users and services should only be granted the absolute minimum level of access required to perform their necessary functions. Unnecessary permissions should be revoked immediately.
Use Authorisation Tokens: Secure access controls by using authorisation tokens, such as JSON Web Tokens (JWTs), and enforce strict validation for every privileged request.

A02:2021 - Cryptographic Failures

Definition and Business Impact

Cryptographic Failures encompass vulnerabilities arising from the improper implementation or the complete absence of cryptography. This category was previously known as Sensitive Data Exposure, but was renamed to focus on the root cause of failure of cryptographic controls rather than the resulting symptom of exposed data⁶. These failures can compromise the confidentiality and integrity of sensitive data both when it is stored and when it is being transmitted. This includes personally identifiable information (PII), passwords, credit card numbers, health records, and business secrets.

The business impact of cryptographic failures is direct and severe. Successful exploitation can lead to data breaches, resulting in identity theft, financial fraud, and significant reputational damage. Furthermore, such failures often lead to non-compliance with data protection regulations like the General Data Protection Regulation (GDPR) and the Payment Card Industry Data Security Standard (PCI DSS), which mandate strong protection for personal and financial data, resulting in substantial fines and legal liabilities.

Common Attack Scenarios and Vectors

Cryptographic failures arise from a wide range of implementation mistakes, demonstrating that simply "using encryption" is insufficient if not done correctly. Common attack vectors include:

Transmission of Data in Clear Text: The most basic failure is transmitting sensitive data over unencrypted protocols like HTTP, FTP, or SMTP. An attacker on the same network (e.g., public Wi-Fi) can easily intercept this traffic and read the data in plain text.
Use of Weak or Deprecated Algorithms: Employing outdated and cryptographically broken algorithms such as MD5 or SHA-1 for hashing, or DES and RC4 for encryption, provides a false sense of security. These algorithms have known weaknesses that allow attackers to crack hashes or decrypt data with relative ease.
Insecure Password Storage: Storing user passwords in plain text or using weak hashing methods is a critical failure. Passwords hashed without a "salt" (a unique random value per user) are vulnerable to rainbow table attacks, where pre-computed hashes are used to quickly find the original password⁷.

Figure 4: Insecure Password Storage (Password Stored in Plain Text)

Poor Key Management: hard-coding encryption keys directly in source code, storing keys in plaintext configuration files, using weak or default keys, and failing to rotate keys periodically. If an attacker gains access to the source code or a configuration file, the hard-coded key can be used to decrypt all protected data.

Mitigation Strategies

A robust defense against cryptographic failures requires a holistic, proactive approach that spans the entire lifecycle of sensitive data and the cryptographic keys that protect it.

Classify Data: Begin by identifying and classifying all data processed, stored, or transmitted by the application⁸. Determine which data is sensitive (e.g., PII, financial data, health records) and requires cryptographic protection, based on business needs and regulatory requirements such as GDPR or PCI DSS.
Minimise Data Storage: Do not store sensitive data unless it is necessary. When it is no longer needed, it should be securely discarded.
Encrypt Data at Rest: All sensitive data stored in databases, files, or other storage systems must be encrypted using strong, industry-standard algorithms such as AES-256.
Enforce Encryption in Transit: Mandate the use of secure transport protocols like TLS 1.2 or 1.3 for all data transmission, both over external networks and between internal systems. Configure servers to use strong cipher suites and enable features such as HTTP Strict Transport Security (HSTS) to prevent protocol downgrade attacks.
Use Strong Hashing Algorithms: Never store passwords in plain text or with reversible encryption. Use strong, adaptive, and salted hashing functions such as Argon2, scrypt, or bcrypt. These algorithms are computationally intensive, significantly slowing brute-force and dictionary attacks.

Figure 5: Secure Password Storage

Implement Secure Key Management: Establish a formal process for the entire key lifecycle, including secure generation, distribution, storage, and rotation. Never hard-code keys or store them in source code or configuration files.

A03:2021 - Injection

Definition and Business Impact

Injection flaws are a class of vulnerabilities that occur when an application sends untrusted data to an interpreter as part of a command or query⁹. The attacker's malicious data tricks the interpreter into executing unintended commands or accessing data without proper authorisation.

Injection vulnerabilities are consistently among the most dangerous and widespread security risks. The business impact of a successful injection attack can be severe, ranging from data theft and loss of data integrity to complete host takeover. Attackers can bypass authentication, exfiltrate entire databases, modify or delete data, or execute arbitrary commands on the operating system, depending on the type of injection.

Common Attack Scenarios and Vectors

Injection vulnerabilities manifest in various forms, depending on the targeted technology and interpreter. The common thread is the failure to properly validate, sanitise, or separate untrusted user input from commands and queries.

SQL Injection (SQLi): This is the most well-known form of injection. An attacker provides specially crafted SQL commands via an input field (e.g., a login form or a search bar). If the application concatenates this input directly into a SQL query, the attacker's commands can be executed by the database. This can be used to bypass authentication (e.g., by injecting ' OR '1'='1'), retrieve sensitive data from other tables, or even delete the entire database.

Figure 6: SQL Injection Caused by Unsafe User Input Concatenation

Cross-Site Scripting (XSS): In an XSS attack, the attacker injects malicious scripts (usually JavaScript) into a web page that is then viewed by other users. The browser, trusting the script came from the web application, executes it. XSS can be used to steal session cookies, hijack user sessions, deface websites, or redirect users to malicious sites.
OS Command Injection: This occurs when an application passes unsanitised user input to a system shell. An attacker can inject OS commands (e.g., rm -rf /), which are then executed with the privileges of the web application¹⁰. This can lead to full server compromise.

Mitigation Strategies

Preventing injection requires a defense-in-depth strategy that treats all user input as untrusted and ensures it is never mixed with executable code or commands.

Parameterised Queries: Use APIs that avoid an interpreter entirely or provide a parameterised interface. This includes using prepared statements (with parameterised queries) for database access. Parameterisation ensures that user input is always treated as data and can never be interpreted as part of the command.

Figure 7: Prevent SQL Injection with Prepared Statements

Server-Side Validation: Perform all input validation on the server side. Client-side validation is useful for user experience, but can be easily bypassed by an attacker.
Use Allow-lists: Implement positive input validation (allow-lists) that restrict input to a set of known-good characters and formats, rather than trying to block a list of bad characters (deny-lists), which is often incomplete.
Escape Special Characters: Ensure that all user-supplied data is properly escaped for the target interpreter to prevent XSS attacks.

A04:2021 - Insecure Design

Definition and Business Impact

Insecure Design is a new category for the 2021 list, representing a broad class of weaknesses stemming from missing or ineffective security controls and architectural flaws¹¹. Unlike implementation bugs (e.g., a missing line of code), an insecure design means the application was fundamentally architected without adequate consideration of security threats. No matter how perfectly the code is written, an insecure design cannot be fixed by a perfect implementation because the necessary security controls were never planned in the first place.

The business impact is substantial because fixing a design flaw is far more costly and complex than patching a simple bug. It often requires re-architecting entire features or workflows, leading to significant development overhead, delays, and potential downtime. Exploitation of insecure design can lead to business logic abuse, data breaches, and systemic failures that are difficult to remediate with simple patches.

Common Attack Scenarios and Vectors

Insecure design vulnerabilities manifest as flaws in an application's business logic, data handling, or control flows. They are often unique to the application's context and require an understanding of how the system is supposed to work in order to abuse it.

Flawed Business Logic: The application's workflow can be exploited in ways the designers did not anticipate. For example, an e-commerce site might allow a user to apply a discount coupon multiple times or combine discounts in a way that results in a negative total because the design did not account for this abuse case. Another example is a movie theater reservation system without a deposit requirement, which could be abused by a bot to reserve all seats, causing a denial-of-service attack and revenue loss.
Insecure Credential Recovery: Workflows for password recovery that rely on easily discoverable information, such as security questions like "What street did you grow up on?", are insecure by design¹². This information is often publicly available or can be found through social engineering, allowing an attacker to take over an account.

Mitigation Strategies

Preventing insecure design requires a cultural shift towards integrating security throughout the entire SDLC.

Establish a Secure Development Lifecycle: Integrate security practices into every phase of development, from requirements gathering to deployment and maintenance.
Use Threat Modeling: For every new feature or architectural change, perform threat modeling to identify potential threats, abuse cases, and security risks. This proactive process helps teams think like an attacker and build in necessary controls from the start, rather than trying to add them later.
Fail Securely: Design the system to default to a secure state in the event of an error, preventing sensitive information from being exposed in error messages.

A05:2021 - Security Misconfiguration

Definition and Business Impact

Security Misconfiguration refers to vulnerabilities that arise from insecure default settings, incomplete or ad hoc configurations, or the improper implementation of security controls across any part of the application stack¹³.

These vulnerabilities are often easy for attackers to discover and exploit, making them low-hanging fruit for unauthorised access. The business impact can be significant, leading to data breaches, system compromise, or information disclosure that can be used to stage further attacks. A single misconfiguration, such as leaving a cloud storage bucket publicly accessible or failing to change a default password, can expose an entire organisation's sensitive data.

Common Attack Scenarios and Vectors

Security misconfigurations can occur at any level of the application stack, from network services to application code.

Default Configurations: Many servers, frameworks, and applications ship with default accounts and passwords (e.g., admin:admin). If these are not changed during deployment, attackers can easily gain administrative access using publicly known default credentials.
Unnecessary Features Enabled: Installing or leaving unnecessary features, services, ports, pages, or accounts enabled increases the attack surface. For example, a server running an unnecessary service might have a known vulnerability that an attacker can exploit.
Improperly Configured Cloud Services: A very common and high-impact misconfiguration is improperly configured permissions on cloud storage services such as Amazon S3. Leaving an S3 bucket publicly readable can expose massive amounts of sensitive data to the entire internet.

Figure 8: The "Principal": "*" line allows anyone on the internet to read files in the bucket.

Verbose Error Messages: Error messages that reveal excessive detail —such as stack traces, database query errors, or internal server paths —can provide attackers with valuable information about the application's underlying technology and potential flaws.

Mitigation Strategies

Preventing security misconfigurations requires a systematic and automated approach to hardening every layer of the application stack.

Establish a Repeatable Hardening Process: Create a minimal, secure baseline configuration for every component of your stack (OS, web server, DBMS, framework). This process should be automated to ensure consistency and speed across all environments (development, QA, production).
Remove or Disable Unnecessary Features: Remove all unused software, features, components, files, and frameworks. Disable unnecessary services and ports to reduce the attack surface.
Change All Default Credentials: Ensure that all default usernames and passwords are changed to strong, unique credentials before any system is deployed to production.

A06:2021 - Vulnerable and Outdated Components

Definition and Business Impact

Modern applications are rarely built from scratch; they are assembled using a vast array of third-party and open-source components, such as libraries, frameworks, and modules. The Vulnerable and Outdated Components category addresses the risks that arise from using these components when they contain known security flaws or are no longer supported with security patches by their maintainers¹⁵.

The business impact of this vulnerability is significant. A single vulnerable component can open the entire application to attack. If a widely used library is found to have a critical vulnerability, thousands of applications can become vulnerable overnight. Attackers actively scan for applications using components with known exploits, making this a low-effort, high-reward attack vector. Successful exploitation can lead to data breaches, system compromise, and reputational damage.

Common Attack Scenarios and Vectors

Attackers exploit this vulnerability by identifying an application that uses a component with a publicly known Common Vulnerability and Exposure (CVE) and then using a published exploit to compromise the application.

Lack of Inventory and Monitoring: The most common failure is that organisations simply do not know what components are in their applications. Without a complete and accurate Software Bill of Materials (SBOM), they are unable to determine if they are affected when a new vulnerability is announced.
Using Unpatched or Out-of-Date Software: Organisations may fail to apply security patches in a timely manner due to complex dependencies, fear of breaking functionality, or simply a lack of a robust patch management process. This leaves them exposed to known vulnerabilities long after a fix is available.

Figure 9: Using Out-of-Date Apache Web Server

Relying on Unsupported Components: Using libraries or frameworks that are no longer maintained (end-of-life) means that even if new vulnerabilities are discovered, no security patches will be released, leaving the application permanently vulnerable.

Mitigation Strategies

Addressing the risks of vulnerable and outdated components requires a continuous and automated approach to software supply chain management.

Maintain a Component Inventory (SBOM): The first and most critical step is to know what you are using. Maintain a complete and accurate inventory of all third-party components and their dependencies, including their exact versions. This is often referred to as a Software Bill of Materials (SBOM).
Remove Unused Components: Regularly audit your applications and remove any dependencies, features, files, and components that are unused or no longer necessary. This reduces the overall attack surface.
Use Software Composition Analysis (SCA) Tools: Integrate SCA tools (such as OWASP Dependency-Check or commercial alternatives) into your CI/CD pipeline. These tools automatically scan your components and their dependencies against databases of known vulnerabilities (like the CVE database) and alert you to any risks.
Patch Promptly: When a vulnerability is identified in a component you use, apply the security patch in a timely manner, prioritising the most critical vulnerabilities.

A07:2021 - Identification and Authentication Failures

Definition and Business Impact

Identification and Authentication Failures encompass vulnerabilities related to confirming a user's identity, authenticating them, and managing their sessions¹⁶. This category, previously named "Broken Authentication," slid from the second position in 2017 to seventh in 2021, a change attributed to the increased availability and adoption of standardised frameworks that handle authentication more securely. However, it remains a critical risk, as failures can permit attackers to compromise user accounts, impersonate legitimate users, and gain unauthorised access to systems and data.

The business impact of these failures is severe. A compromised user account, especially a privileged one, can lead directly to a major data breach. Attackers can steal sensitive data, initiate fraudulent transactions, or use the compromised account as a pivot point to move laterally within the network. High-profile incidents often involve credential-based attacks, resulting in significant financial losses, regulatory penalties, and a loss of customer trust.

Common Attack Scenarios and Vectors

These failures often stem from weak or improperly implemented authentication and session management controls.

Permitting Weak or Reused Passwords: The most common failure is allowing users to set weak, easily guessable passwords (e.g., "password123") or failing to protect against the use of credentials compromised in other breaches. Attackers exploit this through various automated attacks.
Missing or Ineffective Multi-Factor Authentication (MFA): Relying on a single factor (a password) for authentication is no longer sufficient. The absence of MFA makes accounts highly vulnerable to takeover if their passwords are compromised.
Insecure Session Management: Flaws in how user sessions are managed can allow attackers to hijack them. This includes exposing session IDs in URLs (where they can be logged or leaked), failing to invalidate session IDs upon logout, or setting long, non-expiring session timeouts.

Mitigation Strategies

Protecting against identification and authentication failures requires a layered defense that secures every aspect of the user lifecycle, from registration to logout.

Multi-Factor Authentication (MFA): Where possible, implement MFA for all users to protect against credential stuffing and other password-based attacks. This is the single most effective control for preventing account takeover.
Strong Password Policies: Enforce strong password complexity requirements (length, character types) and check new passwords against a list of known-compromised passwords to prevent reuse.
Generate Random Session IDs: Ensure that session IDs are generated using a cryptographically secure random number generator and are sufficiently long and complex to prevent guessing.
Invalidate Sessions: Invalidate session IDs on the server side immediately upon logout and implement reasonably short session idle and absolute timeouts.

A08:2021 - Software and Data Integrity Failures

Definition and Business Impact

Software and Data Integrity Failures is a new category for 2021 that addresses vulnerabilities related to code and infrastructure that do not protect against integrity violations. This category focuses on risks from making assumptions about the trustworthiness of software updates, critical data, and CI/CD pipelines without verifying their integrity¹⁷.

The business impact is enormous, as a single compromise can lead to breaches across thousands of organizations. Data integrity failures can lead to the injection of malicious code, unauthorised system modifications, or the corruption of critical business data.

Common Attack Scenarios and Vectors

These failures occur when an application trusts data or code without verifying its source and integrity.

Insecure CI/CD Pipelines: If a Continuous Integration/Continuous Deployment (CI/CD) pipeline is not properly secured, an attacker can gain access and inject malicious code into the application during the build or deployment process. This malicious code is then packaged with the legitimate application and deployed to production.
Unsigned Software Updates: Many applications, especially IoT devices and consumer software, use an auto-update feature. If these updates are not digitally signed, or if the application fails to verify the signature, an attacker can host a malicious update file. The application will then download and execute the attacker's code, compromising the system.
Use of Dependencies from Untrusted Sources: Downloading libraries or modules from untrusted third-party repositories or public CDNs without verifying their integrity can lead to the inclusion of malicious or compromised code in the application.

Figure 10: Execution of Downloaded Code from Untrusted Sources Without Verifying Their Integrity

Mitigation Strategies

Protecting against software and data integrity failures requires establishing and verifying trust at every step of the software lifecycle.

Use Digital Signatures: Ensure that all software, updates, and critical data are digitally signed by the source. The receiving application must then verify this signature before processing or executing the code or data. This confirms that the asset is from a trusted source and has not been tampered with.
Secure the CI/CD Pipeline: Implement strong access controls, segregation of duties, and configuration hardening for all components of the CI/CD pipeline (e.g., source code repositories, build servers, artifact registries). Regularly review code and configuration changes to minimise the chance of malicious code being introduced.
Use Trusted Repositories: Only consume libraries and dependencies from trusted, official repositories. For high-security environments, consider hosting a private, internal repository of vetted and approved components.

A09:2021 - Security Logging and Monitoring Failures

Definition and Business Impact

Security Logging and Monitoring Failures encompass weaknesses in an organisation's ability to detect, respond to, and conduct forensics on security incidents. Without adequate logging and monitoring, breaches cannot be detected or are detected too late, allowing attackers to maintain persistence, escalate privileges, and exfiltrate data over extended periods.

The business impact of these failures is profound. The average time to detect a breach is often measured in months (an average of 197 days⁾¹⁸, giving attackers a vast window of opportunity to achieve their objectives. Inadequate logging cripples incident response and forensic analysis, making it difficult or impossible to determine the scope of a breach, which data was compromised, and how attackers gained access. This can lead to increased remediation costs, larger regulatory fines (as compliance with standards such as PCI DSS and HIPAA often requires logging), and a complete loss of customer trust.

Common Attack Scenarios and Vectors

These failures are not typically exploited as a direct entry point but are enabling factors that make other attacks more likely to succeed and more damaging.

Insufficient Logging: Key security events are not logged at all. This includes failed logins, access control failures, and high-value transactions. Without these logs, there is no record of an attack attempt.
Inadequate Log Detail: Logs are generated but lack sufficient context to be useful for forensics. For example, a log entry might record a failed login but not the source IP address or the username that was attempted, making it impossible to trace the attack.

Figure 11: Inadequate Log Detail (no username, no source IP, no request/session id, no reason)

Lack of Monitoring and Alerting: Logs are generated and stored, but are never reviewed or analysed. No automated alerts are configured to notify security teams of suspicious activity, such as a high volume of failed logins from a single IP address.
Insecure Log Storage: Logs are stored locally on the compromised server, allowing an attacker to modify or delete them to cover their tracks. Logs are also not protected against tampering.
No Incident Response Plan: Even if an alert is generated, there is no clear, tested plan for responding, leading to a chaotic, ineffective response to the incident.

Mitigation Strategies

Effective logging and monitoring require a comprehensive strategy that covers log generation, collection, protection, analysis, and response.

Log Key Events: Ensure that all auditable events are logged with sufficient user context. This includes logins (successful and failed), access control failures, server-side input validation failures, and high-value transactions.
Use Standardised Formats: Generate logs in formats that are easily consumed by centralised log management solutions (e.g., JSON). Ensure logs include contextual information such as timestamps, source IP addresses, user IDs, and the specific event that occurred.
Prevent Tampering: Use integrity controls, such as append-only storage or digital signatures, to ensure log data cannot be altered after it is written.
Develop and Test a Plan: Adopt or create a formal incident response and recovery plan (e.g., following NIST 800-61r2)¹⁹. This plan should clearly define roles, responsibilities, and procedures for responding to different types of security incidents. The plan should be tested regularly through drills and simulations.

A10:2021 - Server-Side Request Forgery (SSRF)

Definition and Business Impact

Server-Side Request Forgery (SSRF) is a vulnerability that allows an attacker to coerce a server-side application into making HTTP requests to an arbitrary domain of the attacker's choosing²⁰. SSRF flaws occur when a web application fetches a remote resource (e.g., an image, a PDF, or data from another API) using a URL provided by the user, without properly validating that URL. The attacker can manipulate this input to force the server to send a crafted request to an unexpected destination.

SSRF can have a significant impact on business operations by effectively turning the vulnerable server into a proxy for the attacker. This allows them to bypass firewalls and other network access controls to scan internal networks, access internal services (like databases or admin panels), query cloud provider metadata services to steal credentials, and exfiltrate sensitive data.

Common Attack Scenarios and Vectors

SSRF attacks exploit any application functionality that makes a server-side request to a URL supplied by the user.

Accessing Internal Services: The primary danger of SSRF is its ability to reach internal, non-public services. An attacker can supply a URL with a private IP address (e.g., http://10.0.0.5/admin) or the loopback address (http://127.0.0.1/server-status). Because the request originates from the trusted server itself, it can often bypass firewall rules and access sensitive internal endpoints that may lack authentication.

Figure 12: Sample Snippet of Code that is Vulnerable to SSRF.

Cloud Metadata Attacks: In cloud environments (like AWS, GCP, Azure), virtual machines can query a special metadata service at a fixed IP address (e.g., 169.254.169.254 in AWS) to retrieve information about the instance, including temporary security credentials. An attacker can exploit an SSRF vulnerability to cause the server to request this metadata URL, thereby stealing cloud credentials that can be used to take over the entire cloud account.
Internal Port Scanning: By systematically changing the port number in the supplied URL (e.g., http://10.0.0.5:80, http://10.0.0.5:81, etc.) and observing the server's response times or error messages, an attacker can map out the internal network and identify open ports and running services.

Mitigation Strategies

Mitigating SSRF requires a combination of network-level controls and strict application-level input validation.

Validate and Sanitise All User Input: Never trust user-provided URLs. Rigorously validate and sanitize all input that is used to construct a request URL.
Disable Unused URL Schemas: Only allow the URL schemas that are absolutely necessary for your application (e.g., http and https). Disable potentially dangerous schemas such as file://, gopher://, or dict://.

Conclusion

The OWASP Top 10 is far more than a technical checklist to be audited against. Its greatest value lies in its role as a cultural and educational tool. Organisations that treat the list as a mere compliance item to be "checked off" miss its fundamental purpose. The ten categories are not just a list of bugs to fix but represent underlying patterns of failure in software development and security practices.

A mature security program uses the Top 10 to foster a security-conscious culture. It becomes a common language that enables developers, security teams, and business leaders to discuss risk in a prioritised, data-driven manner. By focusing on the root causes highlighted in the OWASP Top 10 list —such as flawed design, insecure dependencies, and inadequate monitoring —organisations can move beyond a reactive, "bug-hunting" mindset. The ultimate goal is not simply to be compliant with the OWASP Top 10, but to change the development and operational processes that allow these vulnerabilities to be identified in the first place.

--------------

The Role of OWASP in Modern Application Security

Deep Dive into the OWASP Top 10 2021

A01:2021 - Broken Access Control

A02:2021 - Cryptographic Failures

A03:2021 - Injection

A04:2021 - Insecure Design

A05:2021 - Security Misconfiguration

A06:2021 - Vulnerable and Outdated Components

A07:2021 - Identification and Authentication Failures

A08:2021 - Software and Data Integrity Failures

A09:2021 - Security Logging and Monitoring Failures

A10:2021 - Server-Side Request Forgery (SSRF)

Conclusion

Reference