OWASP Top 10: A Developer's Guide to Finding and Fixing Each Category

Knowing what the OWASP Top 10 categories are is one thing. Knowing what they actually look like in a codebase — and what to do about them — is a different, more useful skill. This is a working guide for developers, organized around detection and remediation rather than definitions.

A01: Broken Access Control

What it looks like in code: An endpoint that fetches a resource by ID without checking whether the requesting user actually owns or is authorized to access that resource. GET /api/orders/{id} that returns any order for any authenticated user is the textbook case.

How to fix it: Enforce authorization checks server-side, on every request, not just in the UI. Default to denying access and explicitly grant it, rather than the reverse. Centralize authorization logic where possible rather than repeating ad hoc checks across every endpoint.

A02: Security Misconfiguration

What it looks like: Default credentials left in place, verbose error messages exposing stack traces in production, unnecessary services or ports left open, permissive CORS configuration, cloud storage buckets left publicly readable.

How to fix it: Harden configurations as part of your deployment pipeline, not as a manual afterthought. Disable debug modes and verbose errors in production. Regularly audit cloud resource permissions — this is a category where automated configuration scanning earns its keep.

A03: Software Supply Chain Failures

What it looks like: A dependency with a known CVE that hasn't been updated, a compromised package pulled from a public registry, or a CI/CD pipeline with excessive access to production secrets.

How to fix it: Run software composition analysis (SCA) continuously, not just at release time. Pin dependency versions deliberately rather than accepting silent upgrades. Restrict what build and CI systems can access — a compromised pipeline shouldn't have a direct path to production credentials.

A04: Cryptographic Failures

What it looks like: Sensitive data stored or transmitted without encryption, weak hashing algorithms for passwords, hardcoded encryption keys, or TLS configured with outdated protocols.

How to fix it: Use established, vetted cryptographic libraries rather than custom implementations. Hash passwords with a modern, purpose-built algorithm. Encrypt sensitive data at rest and in transit by default, and manage keys through a dedicated secrets manager rather than embedding them in code.

A05: Injection

What it looks like: String concatenation used to build a SQL query from user input, unsanitized input passed to a shell command, or user-controlled data reflected directly into HTML output.

How to fix it: Use parameterized queries or an ORM for all database access — never build queries via string concatenation. Avoid passing user input to system commands where possible; where unavoidable, use strict allow-lists. Apply context-aware output encoding to prevent reflected input from being interpreted as code.

A06: Insecure Design

What it looks like: A password reset flow that doesn't rate-limit attempts, a multi-step checkout that can be completed out of order, or a feature built without ever considering what a malicious user would do with it.

How to fix it: This is the category that testing alone can't fully solve — it needs to be addressed at the design stage, through threat modeling before code is written, not just vulnerability testing after.

A07: Authentication Failures

What it looks like: Weak password policies, missing multi-factor authentication on sensitive accounts, session tokens that don't expire, or predictable session identifiers.

How to fix it: Use established authentication frameworks rather than building auth from scratch. Enforce MFA for privileged accounts. Ensure session tokens are generated with sufficient entropy, expire appropriately and are invalidated on logout.

A08: Software or Data Integrity Failures

What it looks like: Auto-updating software or CI/CD pipelines that don't verify the integrity of what they're pulling in, or deserialization of untrusted data without validation.

How to fix it: Verify signatures and checksums for software updates and dependencies. Avoid deserializing untrusted data with formats that allow arbitrary code execution; validate and restrict what deserialization is allowed to construct.

A09: Security Logging & Alerting Failures

What it looks like: Authentication failures that aren't logged, no alerting on unusual access patterns, or logs that exist but nobody reviews.

How to fix it: Log security-relevant events — authentication attempts, access control failures, significant state changes — consistently. Set up alerting on patterns that indicate active exploitation, not just storage of logs for after-the-fact review.

A10: Mishandling of Exceptional Conditions

What it looks like: An application that fails open (grants access) rather than fails closed (denies access) when an error occurs, or error handling that leaks internal details useful to an attacker.

How to fix it: Design error handling to fail securely by default. Test how the application behaves under unexpected conditions, not just the happy path — this is a category that specifically requires deliberately breaking things to observe the failure behavior.

How does Averto fit in?

Going category by category manually, across a full application, doesn't scale — which is exactly why continuous testing matters more than a one-time review. Averto tests continuously across these categories, verifying which findings are actually exploitable in your specific configuration, so remediation effort goes toward what matters rather than a raw, unfiltered list.