Security Blog

OWASP Top 10: A Developer's Practical Field Guide

The OWASP Top 10 isn't just a compliance checkbox. Here's what each vulnerability actually looks like in real code, and how to prevent it before it ships.

owaspweb securitydevelopersappsec

The OWASP Top 10 is the most cited list in application security. Most developers know it exists. Fewer know what each item actually looks like in their code, or how to detect it automatically. This is the practical version.

A01 – Broken Access Control

The #1 risk. A user can access resources they shouldn't — another user's data, admin endpoints, files outside their scope. Classic patterns: missing authorization checks on API endpoints, IDOR (Insecure Direct Object Reference) where you change an ID in the URL and get someone else's record, or privilege escalation through JWT manipulation.

Catch it: Code review for missing authorize() or middleware checks on routes. Dynamic testing by calling endpoints with a different user's session token.

A02 – Cryptographic Failures

Data transmitted or stored without encryption, or encrypted with weak algorithms. MD5 and SHA-1 for password hashing. HTTP instead of HTTPS for sensitive data. Database columns storing PII in plaintext. Hardcoded encryption keys in source code.

Catch it: Secrets scanning finds hardcoded keys. Static analysis finds MD5/SHA-1 usage. Dynamic testing checks TLS configuration and certificate validity.

A03 – Injection

SQL injection is the classic. But injection covers SQL, NoSQL, OS command, LDAP, XPath, and template injection. Anywhere user input reaches an interpreter without proper parameterization. A GraphQL query built from user-controlled strings is injection. An eval() on user input is injection.

Catch it: Data flow analysis tracing user input to database calls. Dynamic testing with payload fuzzing against identified input surfaces.

A04 – Insecure Design

Architecture-level failures that can't be fixed by implementation changes. No rate limiting on login endpoints. No account lockout. Business logic that allows ordering negative quantities. Features that work correctly but create risk by design. This one requires human judgment, but patterns like missing rate limiting on authentication endpoints are automatable.

A05 – Security Misconfiguration

Default credentials left enabled. Debug mode on in production. Unnecessary features enabled. Missing security headers (CSP, HSTS, X-Frame-Options). Verbose error messages exposing stack traces. S3 buckets set to public. This category is almost entirely automatable.

Catch it: Header analysis on live sites. Config file review in PRs. Infrastructure scanning.

A06 – Vulnerable and Outdated Components

A dependency with a known CVE. An unpinned version range that resolves to a vulnerable version. A framework with a critical vulnerability announced last week. The average application has hundreds of dependencies — manually tracking CVEs is impossible.

Catch it: Automated dependency scanning against OSV/NVD on every PR and scheduled basis.

A07 – Identification and Authentication Failures

Weak passwords allowed. No MFA. Session tokens that don't expire. Credentials transmitted over HTTP. Password reset flows that don't invalidate old sessions. Predictable session IDs.

Catch it: Code review for session handling logic. Dynamic testing against authentication endpoints.

A08 – Software and Data Integrity Failures

Deserializing data from untrusted sources without validation. CI/CD pipelines that pull dependencies from mutable sources without integrity checks. Auto-updating without signature verification. The SolarWinds attack was this category.

Catch it: Lockfile presence checks. Subresource integrity on CDN assets. Supply chain analysis.

A09 – Security Logging and Monitoring Failures

No audit log for authentication events. No alerting on repeated failed logins. Logs that contain PII or credentials. Logs that can be tampered with by users. Security events that go undetected for months.

Catch it: Code review for logging of security events. Check for centralized log management in infrastructure.

A10 – Server-Side Request Forgery (SSRF)

The application fetches a URL provided by the user and returns the content — or even just makes the request. An attacker provides http://169.254.169.254/latest/meta-data/ (AWS metadata endpoint) and gets cloud credentials. Or internal services on localhost that aren't exposed externally.

Catch it: Code review for any fetch(userInput) pattern. Dynamic testing by providing SSRF payloads to URL parameters.

Making this practical

The OWASP Top 10 isn't a checklist you run once a quarter. It's a set of vulnerability classes that need to be checked on every code change and every infrastructure deployment. Automation handles A02, A03, A05, A06, and A10 reliably. A01 and A04 need human review of the AI's findings. The rest fall in between.

The goal is to get everything automatable out of the human review loop so that your team's security attention goes to the things that actually require judgment.

Try BattleTest

Catch this class of bug before it ships.

BattleTest reviews every PR for injection flaws, leaked secrets, and CVEs — then battle-tests your live infrastructure the way an attacker would.

Start scanning your repositories free →

Free for public repos · Private repos from $20/mo · No credit card required