The OWASP Top 10 is cited in security questionnaires, compliance frameworks, and penetration test reports worldwide — but most people only have a surface-level understanding of what the risks actually mean in practice. This is the plain-English guide to all 10.
The Open Worldwide Application Security Project (OWASP) has published its Top 10 list of critical web application security risks since 2003. It's the closest thing the industry has to a universal standard for what matters in application security. The current version was updated in 2021 and remains the definitive baseline for secure development in 2026.
Understanding these isn't just a compliance exercise. These are the vulnerabilities that appear in real breach reports, bug bounty findings, and penetration test results year after year. Let's break them down.
What it is: Access control enforces that users can only act within their intended permissions. When it's broken, users can access data or perform actions they shouldn't be allowed to — viewing other users' records, accessing admin functions, or modifying data they don't own.
Real example: Changing a URL parameter from ?user_id=1234 to ?user_id=1235 and seeing another user's account — this is called Insecure Direct Object Reference (IDOR) and it's one of the most common findings in bug bounty programs.
Fix: Enforce access controls server-side, not client-side. Deny by default. Log and alert on access control failures. Test all object references with an unprivileged account.
What it is: Sensitive data — passwords, credit cards, health records, session tokens — is transmitted or stored without adequate encryption, or with weak/outdated cryptography that can be broken.
Real example: User passwords stored as MD5 hashes (easily cracked) instead of bcrypt. HTTP instead of HTTPS for login pages. Encryption keys hardcoded in source code.
Fix: Use TLS 1.2+ for all data in transit. Use bcrypt, scrypt, or Argon2 for password hashing — never MD5 or SHA-1. Don't hardcode secrets. Encrypt sensitive data at rest.
What it is: Untrusted data is sent to an interpreter — a database, OS shell, LDAP server, or XML parser — as part of a command or query. The interpreter executes the attacker's data as instructions.
Real example: A login form where entering ' OR '1'='1 as a username bypasses authentication entirely — classic SQL injection. The same concept applies to NoSQL, LDAP, OS commands, and more.
Fix: Use parameterized queries and prepared statements. Never build queries by concatenating strings. Apply input validation and output encoding. Use an ORM with safe query construction.
Note for 2026: Prompt injection in AI/LLM integrations is now considered a form of injection vulnerability. If your app passes user input into AI model prompts, it belongs in this category.
What it is: Security flaws that exist because security wasn't considered during design — not just implementation bugs. Missing threat modeling, no security requirements, flawed business logic that attackers can exploit.
Real example: A password reset flow that uses a predictable token, or an e-commerce checkout that doesn't validate that quantities are positive integers (allowing negative quantities to reduce the total to zero).
Fix: Build security into design from the start. Conduct threat modeling before building. Define security acceptance criteria for new features. Review business logic flows for abuse cases.
What it is: The most common finding in security assessments. Default credentials, unnecessary services enabled, verbose error messages, missing security headers, cloud storage buckets left public, unpatched systems.
Real example: An S3 bucket left publicly readable containing customer records. Default admin/admin credentials on an internet-facing management portal. Stack traces exposed in error messages that reveal internal architecture.
Fix: Establish a hardened baseline configuration. Automate configuration review with tools like AWS Config, Security Hub, or Wiz. Remove unused features. Review security headers. Disable directory listing.
What it is: Using third-party libraries, frameworks, and dependencies that contain known vulnerabilities — and not updating them.
Real example: The 2021 Log4Shell vulnerability (CVE-2021-44228) affected tens of thousands of applications running an unpatched version of the Log4j logging library. Many organizations didn't even know they were using it.
Fix: Maintain a software bill of materials (SBOM). Use tools like Dependabot, Snyk, or OWASP Dependency-Check to monitor for vulnerable dependencies. Establish a patch management process with SLAs based on severity.
What it is: Weaknesses in how users are identified and authenticated — weak passwords, no multi-factor authentication, session tokens that don't expire, credential stuffing not prevented.
Real example: An application that allows unlimited login attempts, enabling an attacker to brute-force passwords. Sessions that remain valid after logout. Passwords that are never required to meet complexity requirements.
Fix: Enforce MFA on all administrative and privileged accounts. Implement account lockout or CAPTCHA after repeated failures. Invalidate sessions on logout. Use secure, random session tokens with appropriate expiration.
What it is: Code and infrastructure that doesn't verify integrity of software updates, critical data, or CI/CD pipelines — enabling attackers to insert malicious code into the software supply chain.
Real example: The 2020 SolarWinds attack, where malicious code was inserted into a legitimate software update and distributed to thousands of customers. Auto-update mechanisms without signature verification are a classic example.
Fix: Sign and verify all software updates and packages. Implement integrity checks in your CI/CD pipeline. Review third-party dependencies before adding them. Use code signing.
What it is: Insufficient logging, monitoring, and alerting means breaches go undetected for weeks or months. The average time to detect a breach is still measured in months for organizations without mature security monitoring.
Real example: An attacker exfiltrates customer data over 3 months through repeated API calls that were never rate-limited or flagged as anomalous — because no one was monitoring API access logs.
Fix: Log authentication events, access control failures, and input validation errors. Centralize logs in a SIEM. Set up alerts for anomalous patterns. Test your detection capability with red team exercises.
What it is: The application fetches a remote resource using a URL supplied by the user — and an attacker can redirect that request to internal services, cloud metadata endpoints, or other restricted targets the server can reach but the user cannot.
Real example: Many high-profile cloud environment compromises have started with SSRF targeting the AWS metadata endpoint at 169.254.169.254 — allowing attackers to retrieve IAM credentials and escalate to full account compromise.
Fix: Validate and sanitize all user-supplied URLs. Use allowlists for permitted destinations. Block requests to private IP ranges and cloud metadata endpoints. Disable HTTP redirects where possible.
The OWASP Top 10 isn't a checklist to tick off once a year — it's a mental model for thinking about application security across your entire SDLC. The most effective teams embed these considerations into design reviews, code reviews, and automated testing pipelines so that vulnerabilities are caught before they ever reach production.
Truva Solutions conducts OWASP-aligned application security assessments — combining automated scanning with manual expert review to find what scanners miss. We deliver clear findings with remediation guidance your developers can actually act on.
Request an AppSec Assessment