OWASP Top 10 for Developers: How to Avoid the Most Common Vulnerabilities

What the OWASP Top 10 are

The OWASP Top 10 is a list of the ten most critical security risks for web applications, published by the Open Worldwide Application Security Project (OWASP) Foundation. The list is updated every few years and is based on the analysis of thousands of real-world vulnerabilities in web applications worldwide.

The current version (2021) differs from the previous version (2017) in several ways. Some categories were consolidated, new ones were added, and the ranking changed. Injection, which held the number one spot for years, dropped to third place, while Broken Access Control moved to first place because it represents the most common problem in practice.

The OWASP Top 10 is not a standard in the formal sense, but it is referenced by regulatory frameworks (PCI DSS, NIS2 implementation guidelines) and security standards (ISO 27001, NIST). If you develop web applications, every auditor and penetration tester will use the OWASP Top 10 as a baseline for their assessments.

A01: Broken Access Control

Broken Access Control is by far the most common security risk in web applications. It occurs when users can perform actions or access data that fall outside their permissions.

Typical manifestations

Insecure Direct Object References (IDOR): The URL /api/users/42/profile displays the profile of user 42. What happens when you replace 42 with 43? If the application takes the ID from the URL and returns the data without an authorization check, any authenticated user can view the profiles of all other users.

Missing function-level access control: The admin interface is only visible to administrators (the menu is hidden). But the API endpoint /api/admin/users does not check whether the calling user is actually an administrator. A regular user who knows the URL has full access.

Metadata manipulation: A user sends a JSON object to the server and adds a field "role": "admin" that the application blindly accepts, promoting the user to administrator (Mass Assignment).

Prevention

Check access permissions server-side on every request. Never trust the frontend, cookies, or headers alone. Implement centralized authorization logic that is invoked in every controller method or middleware. Use UUIDs instead of sequential IDs for resources (making it harder to guess valid IDs). Implement row-level security: every database query filters by the currently logged-in user. Test authorization explicitly: for every API route, a test should verify that an unauthorized user is rejected.

A02: Cryptographic Failures

This category (formerly "Sensitive Data Exposure") covers all vulnerabilities resulting from missing, flawed, or outdated encryption.

Typical manifestations

Plaintext storage of passwords: Passwords are stored as MD5 or SHA1 hashes in the database. Both algorithms are not designed for password hashing and can be cracked with modern GPUs in seconds.

Missing transport encryption: The application is accessible via HTTPS, but internal API calls between microservices run over HTTP. An attacker on the same network can read the traffic.

Outdated encryption protocols: The application still supports TLS 1.0 or TLS 1.1, or uses insecure cipher suites.

Prevention

Use only algorithms specifically designed for password hashing: bcrypt, scrypt, or Argon2id. The corresponding cryptography policy defines which algorithms and key lengths are permitted within the organization. SHA-256 is not a password hashing algorithm. Enforce HTTPS everywhere, including internally. Use HSTS headers. Use TLS 1.2 or higher and disable outdated protocols. Do not store sensitive data you do not need. If you do not need to store a credit card number long-term, do not store it. Use established libraries for encryption (libsodium, OpenSSL) and never implement your own cryptography.

A03: Injection

Injection vulnerabilities occur when user input is interpreted as code or commands. The most well-known form is SQL injection, but OS command injection, LDAP injection, and NoSQL injection also fall into this category.

How SQL injection works

A vulnerable query looks like this: query = "SELECT * FROM users WHERE name = '" + userInput + "'". If the user enters ' OR '1'='1 as input, the query becomes SELECT * FROM users WHERE name = '' OR '1'='1', which returns all users. With '; DROP TABLE users; --, the attacker can delete the entire users table.

Prevention

The solution is simple and has been known for decades: use parameterized queries (prepared statements). Every modern programming language and framework provides standard mechanisms for this. In PHP PDO, it looks like this: $stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?"); $stmt->execute([$userInput]);. The user input is passed as a parameter and automatically escaped by the database driver. There is no reason to ever use string concatenation for SQL queries.

For other injection types, similar principles apply: never construct OS commands with user input (use explicit functions like subprocess.run() with array arguments instead), parameterize LDAP queries, and create NoSQL queries with the query builders provided by your framework.

A04: Insecure Design

Insecure Design is a category newly added to the OWASP Top 10 in 2021. It describes vulnerabilities that arise not from flawed implementation but from missing or flawed security design.

Typical manifestations

Missing rate limiting: The password reset function has no rate limiting. An attacker can automatically try thousands of email addresses to identify valid accounts, or brute-force the reset code.

Missing business logic validation: An online shop checks the price of an item only in the frontend. An attacker sends a manipulated request with a price of 0 euros and receives the item for free.

Excessive trust in the client: The application relies on the frontend to perform certain validations (e.g., maximum file sizes). An attacker bypasses the frontend and sends requests directly to the API.

Prevention

Conduct threat modeling to identify design weaknesses before code is written. Validate all business rules server-side. Implement rate limiting on all sensitive endpoints (login, password reset, API calls). Never trust the client: every input, every permission, every price is verified server-side.

A05: Security Misconfiguration

Security misconfigurations are the easiest to avoid but most commonly occurring problems. They arise when systems are operated with insecure default settings, unnecessary features are enabled, or error messages disclose too much information.

Typical manifestations

Default passwords not changed (database, admin panel, network devices). Unnecessary services or ports open. Detailed error messages with stack traces in production. Directory listing enabled on the web server. Missing HTTP security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options).

Prevention

Create a hardening checklist for each technology you use. Automate configuration with infrastructure-as-code (Terraform, Ansible) so that the secure configuration is reproducible. Disable debug mode and detailed error messages in production. Set all relevant HTTP security headers. Regularly scan for misconfigurations (e.g., with Mozilla Observatory, securityheaders.com, or Nuclei).

A06: Vulnerable and Outdated Components

This category concerns the use of libraries, frameworks, and other software components with known vulnerabilities. In modern applications, a large portion of the code consists of third-party libraries, and each of these libraries can contain vulnerabilities.

Prevention

Maintain an inventory of all libraries used and their versions (Software Bill of Materials, SBOM). Use automated dependency scanning tools (Dependabot, Renovate, Snyk) in your CI/CD pipeline. Update libraries regularly, not only when a vulnerability becomes known. Remove libraries that are no longer needed. Prefer actively maintained libraries with an active community and timely security updates.

A07: Identification and Authentication Failures

Vulnerabilities in authentication and session management allow attackers to take over identities or impersonate other users.

Typical manifestations

Weak password requirements (no minimum length, no complexity requirements). No protection against credential stuffing or brute force. Session IDs in the URL. Missing session invalidation on logout or after password change. No multi-factor authentication for privileged accounts.

Prevention

Enforce strong passwords (at least 12 characters) and check against known password lists (Have I Been Pwned API). Implement rate limiting and account lockout against brute force. Use secure, random session IDs with sufficient entropy (at least 128 bits). Set session cookies with the attributes Secure, HttpOnly, and SameSite. Invalidate sessions on logout and after password change. Implement MFA for all users, or at a minimum for privileged accounts.

A08: Software and Data Integrity Failures

This category covers vulnerabilities where software or data is processed without integrity verification. This particularly affects CI/CD pipelines, auto-update mechanisms, and data deserialization.

Typical manifestations

Insecure deserialization: The application deserializes user input (e.g., Java objects, PHP unserialize, Python pickle) without validation. An attacker can inject manipulated objects that execute arbitrary code during deserialization.

Compromised CI/CD pipeline: An attacker gains access to the build pipeline and injects malicious code that is deployed to production (supply chain attack).

Prevention

Avoid deserializing user input. If necessary, use secure formats (JSON instead of Java serialization) and strictly validate the deserialized data. Sign software artifacts and verify signatures before deployment. Secure your CI/CD pipeline (access control, code signing, review requirements for pipeline changes). Use Subresource Integrity (SRI) for external JavaScript libraries loaded via CDNs.

A09: Security Logging and Monitoring Failures

Without adequate logging and monitoring, attacks go undetected. The average dwell time (time between compromise and detection) in 2024 was over 10 days. Better monitoring significantly reduces this time.

Prevention

Log security-relevant events: login attempts (successful and failed), access attempts to protected resources, changes to user permissions and configurations, errors and exceptions. Store logs centrally and protect them from tampering. Implement alerting for suspicious patterns (e.g., many failed login attempts from a single IP, access to admin functions by a regular user). Do not log sensitive data (passwords, credit card numbers, personal data) in plaintext.

A10: Server-Side Request Forgery (SSRF)

SSRF occurs when an application sends HTTP requests to a user-controlled URL without validating the URL. An attacker can cause the application to send requests to internal systems that are not accessible from the outside.

Typical manifestations

A function for importing images via URL: the user enters http://169.254.169.254/latest/meta-data/iam/security-credentials/ (the AWS metadata endpoint) and receives the server's IAM credentials.

Prevention

Validate and sanitize all URLs originating from users. Use an allowlist for permitted domains or IP ranges. Block requests to private IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x, 127.x.x.x, 169.254.x.x). Disable HTTP redirects or re-validate the target URL after each redirect. Use network segmentation to place the server in a segment from which it can only reach the necessary external targets.

OWASP Top 10 and automated detection

Not all OWASP Top 10 vulnerabilities can be detected equally well through automation. SAST tools (SonarQube, Semgrep, CodeQL) are effective at finding injection vulnerabilities (A03), cryptographic failures (A02, e.g., weak algorithms), and security misconfiguration (A05, e.g., debug mode enabled). DAST tools (OWASP ZAP, Burp Suite) are effective at detecting security misconfiguration (A05, e.g., missing HTTP headers), authentication failures (A07, e.g., missing rate-limiting headers), and SSRF (A10).

Difficult to detect automatically are Broken Access Control (A01, because authorization logic is application-specific), Insecure Design (A04, because it involves architectural decisions that no scanner can evaluate), and Software and Data Integrity Failures (A08, because supply chain attacks often leave no recognizable code patterns).

For these hard-to-detect categories, you need manual reviews: code reviews focused on authorization, threat modeling for design decisions, and penetration tests to validate the overall application.

The OWASP Top 10 in regulatory frameworks

The OWASP Top 10 are referenced in numerous regulatory frameworks and standards. PCI DSS (Payment Card Industry Data Security Standard) explicitly references the OWASP Top 10 as the basis for secure application development requirements. ISO 27001 Annex A, Control A.8.28 (Secure coding), requires that secure programming principles be applied. The OWASP Top 10 are the most widely adopted concretization of this requirement. NIS2 requires secure development practices, and the OWASP Top 10 are cited as guidance in the implementation recommendations.

If you need to demonstrate that you apply secure development practices, the OWASP Top 10 are the reference that auditors and assessors rely on. Document the measures you have taken against each of the ten categories, and you have solid evidence. In ISMS Lite, secure coding guidelines and OWASP Top 10 countermeasures can be linked to the corresponding controls and prepared for audits.

Training and awareness in the development team

The OWASP Top 10 are also an excellent training instrument. An initial training session of 4 to 8 hours, covering each category with practical examples and exercises, provides the entire team with a shared knowledge base.

Supplement the initial training with regular refreshers: a short presentation (15-30 minutes) per sprint or month on a specific vulnerability class or a recent security incident. Use real-world examples from bug bounty reports, HackerOne disclosures, or security advisories for libraries your team uses. This is far more effective than abstract theory.

Hands-on exercises increase the learning impact. Platforms such as OWASP WebGoat, HackTheBox, or PortSwigger Web Security Academy offer free practice environments where developers can exploit vulnerabilities and understand why certain coding patterns are dangerous.

From theory to practice

The OWASP Top 10 are not rocket science. Most vulnerabilities can be avoided through a few fundamental practices: validate every input, check access permissions server-side, use parameterized queries, use up-to-date libraries, apply secure default configurations, and log security-relevant events.

If you consistently implement these six points, you have already covered the majority of the OWASP Top 10. Automated tools (SAST, DAST, dependency scanning) find the rest. And for the logical vulnerabilities that no tool can find, there is threat modeling and code reviews.

Further reading

• Secure Development Lifecycle (SDL): Sicherheit in den Entwicklungsprozess einbauen
• API-Sicherheit: Authentifizierung, Rate Limiting und Input Validation
• Dependency Scanning: Schwachstellen in Drittbibliotheken finden
• Schwachstellenmanagement aufbauen: Vom Scan zur Behebung
• Secrets Management: Passwörter, API-Keys und Zertifikate sicher verwalten