Overview
Use the OWASP Top 10 as the risk taxonomy behind every page in this category, not as a checklist to run once before launch. The Top 10 is OWASP’s ranked list of the most critical web application security risks, built from testing and incident data submitted by security vendors and practitioners. The 2025 edition (final release January 2026) is the eighth installment and the current version as of this writing; it adds two new categories (Software Supply Chain Failures, Mishandling of Exceptional Conditions) and reorders the rest against the 2021 list. Each entry below links to the page on this site with the concrete implementation guidance.
A01: Broken Access Control stays the top risk; enforce it in the database, not just the UI
Broken access control means a user reaches data or actions outside their permission scope: another tenant’s rows, an admin endpoint with no role check, an object ID that works for any authenticated user. Enforce authorization at the data layer so a missed check in application code cannot leak rows. See supabase-rls for Postgres Row Level Security policies and auth-sessions for session-level authorization.
A02: Security Misconfiguration jumped from #5 to #2; default-deny every surface
Security Misconfiguration covers default credentials, verbose error pages, unnecessary open ports, permissive CORS, and missing security headers. Deny by default and enable only what a feature needs. See cloudflare-security-headers for the header baseline and pre-launch-checklist for the punch list to clear before traffic arrives.
A03: Software Supply Chain Failures is new; audit what you did not write
This category widens the old “vulnerable and outdated components” risk to the whole software lifecycle: dependencies, build systems, CI/CD pipelines, and third-party platforms. Pin dependency versions, run automated vulnerability scans in CI, and verify package provenance before adding a new dependency. See python-security for dependency auditing in Python projects.
A04: Cryptographic Failures means data exposed in transit or at rest, not “used the wrong algorithm”
Cryptographic Failures covers plaintext transmission, weak or homegrown algorithms, hardcoded keys, and secrets stored unencrypted. Force HTTPS everywhere, never write your own crypto primitive, and keep keys out of source control. See secrets-and-env for secret storage and rotation.
A05: Injection is still SQL, command, and template injection; parameterize everything
Injection happens when untrusted input reaches an interpreter (SQL, shell, template engine, ORM query builder) as code instead of data. Use parameterized queries and an ORM’s query builder, never string-concatenated SQL. See python-security for parameterized queries and pickle avoidance, and prompt-injection-defense for the LLM-specific analog, which OWASP tracks separately (see owasp-llm-top-10).
A06: Insecure Design means the flaw is in the architecture, not a single line of code
Insecure Design is what remains after you fix every implementation bug: a password reset flow with no rate limit, a checkout that trusts a client-supplied price, a multi-tenant schema with no tenant column. Threat-model the design before writing code, and require server-side enforcement for anything money- or access-related. See payments-stripe for server-side pricing and fulfillment.
A07: Authentication Failures covers session handling and credential storage together
Authentication Failures merges what used to be split across “broken authentication” and “identification failures”: weak session tokens, missing MFA, credential stuffing with no rate limit, and session fixation. See auth-sessions for cookie flags, session rotation, and refresh-token reuse detection.
A08: Software or Data Integrity Failures means you trusted an update or payload without verifying it
This category covers unsigned software updates, CI/CD pipelines that pull unpinned dependencies, and deserializing untrusted data without integrity checks. Verify signatures on anything auto-updating, and treat webhook payloads as untrusted until their HMAC signature checks out. See webhooks for signature verification.
A09: Security Logging and Alerting Failures means an attacker’s first request looks identical to their thousandth
Without logging and alerting, a breach runs for months before anyone notices. Log authentication events, access-control failures, and input-validation failures, and alert on anomalous volume. Build this into the launch checklist, not as a post-incident retrofit. See pre-launch-checklist for the observability items to clear before launch.
A10: Mishandling of Exceptional Conditions is new; error paths need the same rigor as happy paths
This new category covers improper error handling, logic errors on failure, and systems that fail open instead of closed. A payment webhook that silently succeeds on a malformed payload, or an auth check that defaults to “allowed” on an exception, both belong here. Fail closed: any unhandled exception in an authorization or payment path should deny the action, not permit it.