OWASP Top 10 Explained: Web Application Security Risks

The OWASP Top 10 is a list of the ten most critical categories of web application security risk, published by the OWASP Foundation (Open Worldwide Application Security Project). It is an awareness document rather than a complete standard, yet it has become the common language of developers, security teams and auditors, and many frameworks and contracts reference it.

It matters because most attacks on websites and online services start in these categories: broken access control, injection, misconfiguration and outdated libraries. This article has the OWASP Top 10 explained category by category for the 2021 edition, with an example and a mitigation for each, then compares SAST and DAST and shows where API security and web scanning fit.

What is the OWASP Top 10 and how is it built?

OWASP is an open, non-profit community focused on software security. The Top 10 is compiled from application testing data contributed by many organizations combined with a survey of security practitioners, and OWASP updates it periodically. The 2021 edition brought significant changes:

• Three new categories: Insecure Design (A04), Software and Data Integrity Failures (A08) and Server-Side Request Forgery (A10).
• Broken Access Control moved to first place.
• Cross-site scripting was merged into Injection, XXE moved under Security Misconfiguration, and "Sensitive Data Exposure" was renamed Cryptographic Failures to focus on the root cause.

Each category groups a set of CWE weaknesses rather than a single vulnerability. The full text and guidance for every category is on the official OWASP Top 10 site.

The OWASP Top 10 (2021) explained with examples

Code	Category	Example	Key mitigation
A01	Broken Access Control	Changing an ID in the URL shows another customer's invoice (IDOR)	Deny by default, check object ownership server-side
A02	Cryptographic Failures	Passwords stored as MD5, sensitive data sent over HTTP	Modern TLS, Argon2 or bcrypt for passwords, key management
A03	Injection	SQL injection in a search form, XSS in comments	Parameterized queries, input validation, output encoding
A04	Insecure Design	Password reset with guessable security questions, no rate limits	Threat modeling and secure design patterns from day one
A05	Security Misconfiguration	Default accounts, directory listing, verbose error messages	Hardening, removing unused features, automated config checks
A06	Vulnerable and Outdated Components	Running a vulnerable Log4j version (Log4Shell, CVE-2021-44228)	Dependency inventory, SCA and regular patching
A07	Identification and Authentication Failures	Credential stuffing succeeds because there is no MFA or lockout	MFA, login rate limiting, secure session management
A08	Software and Data Integrity Failures	Unsigned updates, insecure deserialization of user data	Digital signatures, integrity checks, secured CI/CD
A09	Security Logging and Monitoring Failures	Repeated failed logins are not logged or alerted on	Centralized logging, alerting, incident response
A10	Server-Side Request Forgery (SSRF)	The app fetches a user-supplied URL and reaches internal services	Destination allowlists, block internal ranges, segmentation

Notes on key categories

Broken Access Control (A01) is the most common problem partly because automated scanners struggle to understand "who may see what". Authorization must be enforced server-side on every request, never by hiding a button in the UI.

Injection (A03) is old but still dangerous. Parameterized queries or an ORM, and never building commands by string concatenation, eliminate most SQL injection.

Insecure Design (A04) cannot be fully found by any tool; the flaw is in the design itself and must be addressed with threat modeling and architecture review before code is written.

Vulnerable and Outdated Components (A06) is directly tied to patch management: libraries, frameworks and web servers need to be inventoried and updated just like operating systems.

Security Misconfiguration (A05) shrinks with system hardening and automated checks of web server settings, security headers and cloud services.

SAST vs DAST: two complementary views of web application security

Several testing approaches each reveal part of the picture:

• SAST (static testing): analyzes source code without running it. It finds issues early and points to the exact line, but it is language-specific and can be noisy.
• DAST (dynamic testing): tests the running application from the outside, like an attacker. It needs no source code and also catches configuration and runtime issues, but it cannot point to the exact line of code.
• SCA (software composition analysis): identifies open-source libraries and dependencies and matches them against known CVEs; essential for A06.
• Manual testing and penetration testing: for logic, access control and design flaws that tools miss.

The best results come from combining them across the development lifecycle: SAST and SCA in the CI/CD pipeline, DAST against staging and production, and periodic penetration testing for sensitive applications.

API security

Much of today's software, from mobile apps to banking platforms, runs on APIs. Many OWASP Top 10 categories apply to APIs too, but APIs have their own risks, which is why OWASP also runs a separate API Security Top 10 project. The essentials:

1. Object-level authorization: every request must check that the user owns the requested object; Broken Object Level Authorization (BOLA) is the most common API flaw.
2. Strong authentication: use standards such as OAuth 2.0 and validate tokens fully.
3. Rate and resource limits: prevent abuse and credential stuffing.
4. No excessive data: return only the fields the client needs.
5. Complete API inventory: find and retire old versions and undocumented "shadow" APIs.

Where web scanning fits in web application security

A web application scanner (DAST) crawls the site, maps forms, parameters and entry points, and sends controlled attack patterns to each. To get value from it:

• Scan authenticated: most of an application sits behind a login, so give the scanner a test account.
• Provide API definitions: supply an OpenAPI file or request collection to cover APIs.
• Choose the right environment: run active scans against staging first and use safe profiles in production.
• Scan regularly: after every major release and on a schedule.
• Know the limits: scanners are strong on injection, misconfiguration and outdated components, but design and business-logic flaws need review and manual testing.

For more on scanner types, read what is a vulnerability scanner.

How NetGuard helps

NetGuard scans web applications and APIs against the OWASP Top 10 categories and also assesses the servers, web servers and databases behind them for vulnerabilities and CIS Benchmark configuration issues. External attack surface discovery finds internet-facing domains, subdomains, open ports and TLS certificates so no web application is missed. Findings are risk-prioritized, delivered in Persian and English reports, and verified with rescans after fixes. See the vulnerability scanner page for details.

Frequently asked questions

What is the OWASP Top 10?

The OWASP Top 10 is a list of the ten most critical web application security risk categories, published by the non-profit OWASP Foundation based on application testing data and practitioner input and updated periodically. It is an awareness document and has become the usual starting point for developer training, security test planning and reporting web scan results.

What is the number one risk in the OWASP Top 10?

In the 2021 edition, Broken Access Control is ranked first. It covers cases where users can reach data or functions beyond their permissions, for example viewing another user's records by changing an ID in the URL. The main defense is enforcing authorization server-side on every request and denying access by default.

What is the difference between SAST and DAST?

SAST analyzes source code without running the application and pinpoints problems early, down to the line of code. DAST tests the running application from the outside like an attacker, needs no source code and also finds configuration and runtime issues. They complement each other, and mature teams use both within the development lifecycle.

Can a web scanner find every OWASP Top 10 issue?

No. Web scanners are strong at finding injection, misconfiguration, weak transport encryption and outdated components, but categories such as Insecure Design and much of Broken Access Control require understanding business logic. For full coverage, combine automated scanning with code review, threat modeling and manual penetration testing.

Where should I start with web application security?

Start with a complete inventory of internet-facing websites, subdomains and APIs. Then run authenticated web scans and scans of the hosting servers, and fix the findings by risk. Alongside that, harden and update web servers and frameworks, enable MFA on admin panels and set up proper logging and alerting so attacks do not go unnoticed.