OWASP Top 10: The Vulnerabilities Every Company Should Know

Why the OWASP Top 10 Matters for Your Business

The Open Web Application Security Project (OWASP) publishes its Top 10 list roughly every three to four years. It represents a broad consensus about the most critical security risks facing web applications. If you run a website or web application that handles any kind of user data, customer transactions, or internal business processes, this list is your baseline.

The OWASP Top 10 is not just an academic exercise. It is referenced by auditors, compliance frameworks (PCI DSS, for example, explicitly mentions it), and penetration testers worldwide. When a security professional performs an assessment, the OWASP Top 10 is almost always part of the checklist. If your application has vulnerabilities in any of these categories, they will be found. The question is whether they get found by your team or by an attacker.

We are going to walk through each category with real examples, explain why each vulnerability exists, and give you concrete steps to fix or prevent it. For a broader view of how to audit your site's security posture, see our website security audit checklist.

A01:2021 - Broken Access Control

Broken access control moved to the number one spot in the 2021 edition, up from fifth place. It refers to situations where users can act outside their intended permissions.

What It Looks Like

Consider a web application where viewing your own profile is at /api/users/1234/profile. What happens if you change that ID to /api/users/1235/profile? If you can see another user's data, that is broken access control. This specific pattern is called an Insecure Direct Object Reference (IDOR).

Other examples:

• A regular user accessing admin panels by navigating directly to /admin
• An API that does not check whether the authenticated user has permission to modify the requested resource
• Metadata manipulation, like tampering with a JWT token to elevate privileges
• CORS misconfiguration allowing unauthorized API access from malicious origins
• Accessing API endpoints by simply changing the HTTP method from POST to PUT

Real-World Impact

In 2019, a researcher discovered that a major US financial institution's API allowed any authenticated user to view any other customer's account details by changing the account number in the URL. Millions of customer records were exposed before the fix was deployed.

Mitigation

• Deny by default. Every endpoint should require explicit authorization. If a permission check is missing, the default behavior should be to deny access.
• Implement server-side access control checks. Never rely on hiding UI elements. Just because a button is not visible does not mean the API endpoint cannot be called directly.
• Use indirect object references. Instead of exposing database IDs in URLs, use random tokens or UUIDs that are mapped to the actual resource server-side.
• Log access control failures. Alert on repeated failures from the same user, which may indicate someone probing for IDOR vulnerabilities.
• Rate limit API access to minimize the damage from automated enumeration attacks.

A02:2021 - Cryptographic Failures

Previously called "Sensitive Data Exposure," this category was renamed to focus on the root cause: failures in cryptography that lead to data exposure.

What It Looks Like

• Storing passwords in plain text or using weak hashing algorithms (MD5, SHA-1 without salt)
• Transmitting sensitive data over HTTP instead of HTTPS
• Using outdated TLS versions (TLS 1.0, 1.1)
• Hardcoding encryption keys in source code
• Using deprecated or weak ciphers
• Not encrypting sensitive data at rest in databases

Real-World Impact

The 2013 Adobe breach exposed 153 million user records. The passwords were encrypted (not hashed) using 3DES in ECB mode with the same key for all records. Security researchers quickly discovered that the most common encrypted value corresponded to "123456" and could reverse-engineer millions of passwords. Proper password hashing (bcrypt, Argon2) would have made the stolen data far less useful to attackers.

Mitigation

• Use strong, modern hashing for passwords: bcrypt, scrypt, or Argon2id. Never MD5 or plain SHA.
• Enforce TLS 1.2 or higher for all connections. Disable TLS 1.0 and 1.1. See our security headers guide for HSTS configuration.
• Encrypt sensitive data at rest. Use AES-256 for symmetric encryption.
• Manage keys properly. Use a key management service (AWS KMS, HashiCorp Vault) rather than storing keys in your codebase.
• Classify your data. Know which data is sensitive (PII, financial data, health records) and apply appropriate protections to each class.

A03:2021 - Injection

Injection was the number one risk for years and remains critically important even though it dropped to third place. It occurs when untrusted data is sent to an interpreter as part of a command or query.

What It Looks Like

The most well-known form is SQL injection. Consider this code:

const query = "SELECT * FROM users WHERE username = '" + userInput + "'";

If userInput is admin' OR '1'='1, the query becomes:

SELECT * FROM users WHERE username = 'admin' OR '1'='1'

This returns all users. An attacker could also use '; DROP TABLE users; -- to delete the entire table.

But injection is not limited to SQL:

• NoSQL injection - MongoDB queries using user-supplied JSON objects
• LDAP injection - Manipulating LDAP queries used for authentication
• OS command injection - When user input is passed to shell commands
• Expression Language injection - In Java EE applications
• ORM injection - Even ORMs can be vulnerable if raw queries are used

Real-World Impact

SQL injection was the attack vector for some of the largest data breaches in history, including the 2008 Heartland Payment Systems breach (130 million credit card numbers) and the 2011 Sony PlayStation Network breach (77 million accounts).

Mitigation

• Use parameterized queries (prepared statements). This is the primary defense. The database treats user input as data, never as code.
• Use an ORM like Prisma, Sequelize, or TypeORM. They use parameterized queries by default for standard operations.
• Validate and sanitize input. Whitelist expected characters and reject everything else.
• Apply least privilege. The database user your application uses should have only the permissions it needs. A read-only API should not connect with a database user that can DELETE or DROP.
• Use stored procedures where appropriate, as they provide an additional layer of abstraction.

A04:2021 - Insecure Design

This is a new category in the 2021 edition. It calls out fundamental design flaws that cannot be fixed by better implementation. A secure implementation of an insecure design is still insecure.

What It Looks Like

• A password recovery flow that asks security questions with answers that are publicly available on social media
• An e-commerce site that does not limit the number of items in a cart, allowing negative quantities for a refund
• A booking system that does not implement a time limit on holding reservations, enabling denial of inventory attacks
• An API that returns full database records when the client only needs two fields

Mitigation

• Threat modeling. Before writing code, identify what could go wrong. Use frameworks like STRIDE to systematically think through threats.
• Establish secure design patterns. Create a library of vetted, secure design patterns that developers can use.
• Write abuse cases alongside use cases. For every feature, ask "how could someone misuse this?"
• Limit resource consumption at the design level. Set maximum quantities, time limits, and rate limits for every user-facing operation.

A05:2021 - Security Misconfiguration

This is the most commonly seen issue in the wild. It covers everything from default credentials to unnecessary features left enabled, missing security headers, overly permissive CORS, and verbose error messages.

What It Looks Like

• Default admin credentials left unchanged on a CMS installation
• Directory listing enabled on the web server, exposing file structures
• Stack traces displayed to users in production error pages
• Unnecessary HTTP methods enabled (PUT, DELETE on endpoints that should only accept GET)
• Missing security headers (X-Frame-Options, Content-Security-Policy, etc.)
• S3 buckets or cloud storage with public access enabled
• Default sample applications still deployed on the server

Real-World Impact

In 2017, a misconfigured AWS S3 bucket at a US defense contractor exposed 60,000 files including passwords, security credentials, and internal project details. The bucket was set to public access, which is the default for some configurations. This pattern of S3 misconfiguration has affected companies of all sizes.

Mitigation

• Implement a hardening process. Create a checklist for every deployment that covers removing defaults, disabling unused features, and verifying configurations.
• Use infrastructure as code. Tools like Terraform, CloudFormation, or Ansible ensure that configurations are consistent, version-controlled, and reviewable.
• Set up automated scanning. Tools like ScoutSuite, Prowler, or cloud-provider security tools can detect misconfigurations automatically.
• Implement proper security headers. Our security headers guide covers this in detail.
• Segment your environments. Development, staging, and production should have different configurations and credentials.

A06:2021 - Vulnerable and Outdated Components

Modern web applications depend on dozens or hundreds of third-party libraries and frameworks. If any of those components have known vulnerabilities, your application inherits them.

What It Looks Like

• Running an old version of a web framework with known CVEs
• Using npm packages that have been abandoned or have unpatched vulnerabilities
• Operating systems or server software not updated with security patches
• Using libraries where the maintainer has flagged security issues but your team has not updated

Real-World Impact

The Equifax breach of 2017, which exposed 147 million records, was caused by an unpatched Apache Struts vulnerability (CVE-2017-5638). The patch had been available for two months before the breach occurred. Equifax simply did not apply it in time.

Mitigation

• Maintain an inventory of all components and their versions. You cannot secure what you do not know about.
• Use automated dependency scanning. GitHub Dependabot, Snyk, or npm audit can flag vulnerable packages automatically.
• Subscribe to security advisories for your critical dependencies.
• Remove unused dependencies. Every dependency is attack surface. If you are not using it, remove it.
• Have a patch management process. Critical security patches should be applied within days, not months.

A07:2021 - Identification and Authentication Failures

Previously called "Broken Authentication," this covers weaknesses in how applications verify identity and manage sessions.

What It Looks Like

• No rate limiting on login attempts, enabling brute force attacks
• Accepting weak passwords (short, common, no complexity requirements)
• Credential stuffing (attackers try username/password pairs leaked from other breaches)
• Session IDs in URLs
• Session tokens that do not expire or are not invalidated on logout
• Missing or poorly implemented multi-factor authentication
• Password recovery flows that reveal whether an account exists

Real-World Impact

Credential stuffing attacks are now one of the most common attack vectors. After a major breach leaks millions of email/password combinations, attackers automatically try those same credentials on hundreds of other sites. Because people reuse passwords, a significant percentage of attempts succeed.

Mitigation

• Implement multi-factor authentication (MFA). This is the single most effective defense against authentication attacks.
• Enforce strong password policies. Minimum 12 characters. Check against lists of commonly breached passwords. Do not require arbitrary complexity rules that lead to predictable patterns.
• Rate limit login attempts. After 5-10 failed attempts, introduce progressive delays or temporary lockouts.
• Use secure session management. Generate long, random session tokens. Set appropriate expiration. Invalidate sessions on logout. Use HttpOnly and Secure cookie flags.
• Implement account lockout carefully. Aggressive lockout can be exploited for denial-of-service. Use CAPTCHA after a few failures rather than locking the account entirely.

A08:2021 - Software and Data Integrity Failures

This new category covers situations where code and infrastructure does not protect against integrity violations. This includes insecure CI/CD pipelines, auto-update mechanisms without integrity verification, and insecure deserialization (which was a separate category in the 2017 edition).

What It Looks Like

• An application that deserializes untrusted data without validation, allowing remote code execution
• CI/CD pipelines where a compromised dependency can inject malicious code into your build
• Software updates delivered without digital signatures or integrity checks
• Using CDN-hosted JavaScript libraries without Subresource Integrity (SRI) hashes

Real-World Impact

The SolarWinds attack in 2020 was a textbook example. Attackers compromised the build system for SolarWinds' Orion software, injecting a backdoor that was distributed to approximately 18,000 organizations through a routine software update. Because the update came through the official channel, most organizations installed it without question.

Mitigation

• Use digital signatures to verify the integrity of software and updates.
• Implement Subresource Integrity (SRI) for any third-party scripts loaded from CDNs.
• Secure your CI/CD pipeline. Review access controls, use signed commits, and verify dependency integrity.
• Avoid deserializing data from untrusted sources. If you must, use allowlists for permitted classes and validate thoroughly.
• Use lock files (package-lock.json, yarn.lock) and verify checksums of dependencies.

A09:2021 - Security Logging and Monitoring Failures

If you cannot see what is happening in your application, you cannot detect attacks in progress. This category covers insufficient logging, ineffective monitoring, and lack of incident response capability.

What It Looks Like

• Login failures not being logged
• Logs stored only locally on the server (an attacker who compromises the server deletes the logs)
• No alerting on suspicious patterns (repeated failed logins, unusual API usage patterns)
• Logs that do not include enough context to investigate an incident (missing timestamps, IP addresses, user identifiers)
• No incident response plan

Real-World Impact

The average time to detect a data breach is over 200 days according to IBM's Cost of a Data Breach Report. Organizations with good logging and monitoring detect breaches in under 100 days and spend significantly less on remediation.

Mitigation

• Log all authentication events (successful and failed), access control failures, and server-side input validation failures.
• Centralize your logs. Send them to a separate logging service (ELK Stack, Datadog, Splunk) that an attacker cannot easily tamper with.
• Set up alerts for patterns that indicate attack: brute force attempts, unusual data access patterns, privilege escalation attempts.
• Include the right context in logs: timestamp, source IP, user ID, action attempted, resource accessed, success/failure.
• Do NOT log sensitive data. Passwords, credit card numbers, and personal data should never appear in logs.
• Create an incident response plan and practice it.

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

SSRF is new to the Top 10 in 2021. It occurs when a web application fetches a remote resource without validating the user-supplied URL. This allows an attacker to make the server send requests to unintended destinations.

What It Looks Like

Imagine a feature where users can provide a URL and your server fetches a preview (like link previews in chat applications). An attacker provides:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

On AWS, this is the metadata endpoint. If your server fetches this URL, the attacker gets your AWS IAM credentials. From there, they can access your S3 buckets, databases, and other AWS resources.

Real-World Impact

The 2019 Capital One breach, which exposed 100 million customer records, involved SSRF as a key component. The attacker exploited a misconfigured WAF to perform SSRF against the AWS metadata service, obtaining temporary credentials that gave access to S3 buckets containing customer data.

Mitigation

• Validate and sanitize all client-supplied URLs. Block requests to private IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x) and cloud metadata endpoints.
• Use allowlists. If your feature only needs to fetch from specific domains, only allow those domains.
• Disable unnecessary URL schemes. Only allow http:// and https://, block file://, ftp://, gopher://, etc.
• Use network segmentation. Your web server should not have network access to internal services it does not need to reach.
• On cloud platforms, use IMDSv2 (on AWS) which requires a session token for metadata access, making SSRF exploitation much harder.

Putting It All Together: A Practical Security Roadmap

Going through the OWASP Top 10 can feel overwhelming. Here is a prioritized approach:

Phase 1: Quick Wins (This Week)

1. Implement security headers (CSP, HSTS, X-Frame-Options, etc.)
2. Enable HTTPS everywhere and disable old TLS versions
3. Update all dependencies to their latest stable versions
4. Set up automated dependency scanning (npm audit, Dependabot)
5. Remove any default credentials or sample applications

Phase 2: Core Fixes (This Month)

1. Audit all database queries for injection vulnerabilities
2. Review access control logic across all endpoints
3. Implement rate limiting on authentication endpoints
4. Set up centralized logging with alerts for security events
5. Add MFA to admin accounts at minimum

Phase 3: Deeper Security (This Quarter)

1. Conduct a thorough code review focusing on the OWASP Top 10
2. Implement a security testing process (SAST, DAST) in your CI/CD pipeline
3. Create and practice an incident response plan
4. Perform a penetration test or security assessment
5. Document your security architecture and train your development team

The OWASP Top 10 Is the Floor, Not the Ceiling

These ten categories represent the most common and impactful risks, but they are far from a complete picture of application security. They are the minimum baseline. Additional threats like business logic vulnerabilities, race conditions, supply chain attacks, and social engineering require attention beyond the Top 10.

The OWASP project also maintains other valuable resources: the OWASP Testing Guide, the OWASP Application Security Verification Standard (ASVS), and the OWASP Cheat Sheet Series. These go much deeper than the Top 10 alone.

If you are unsure where your application stands against these vulnerabilities, a professional security audit can give you a clear picture. At Envestis, we help businesses in Lugano and throughout Switzerland identify and fix these vulnerabilities before attackers find them. Reach out to our team to discuss your security needs.