OWASP Top 10

Status: Complete
Category: Security
Default enforcement: Hard
Author: PushBackLog team

Tags

• Topic: security, quality
• Skillset: any
• Technology: generic
• Stage: execution, review, deployment

Summary

The OWASP Top 10 is the authoritative list of the most critical security risks in web applications. Published by the Open Web Application Security Project and upheld by the industry as a baseline standard, the 2025 edition reflects the latest data on attack patterns and vulnerabilities. Every team shipping web software should treat this list as a minimum security checklist.

Rationale

The cost of security debt

Security vulnerabilities discovered in production are categorically more expensive than those caught during development. The cost of a data breach includes regulatory fines, legal liability, customer notification, remediation across deployed infrastructure, and reputational damage. The cost of reviewing a PR for injection risks is one review comment. The OWASP Top 10 exists because the most common, most exploitable vulnerabilities are also the most preventable — if developers know to watch for them.

Why “top 10” and not “every risk”

OWASP distils years of breach data, CVE reports, and security research into the patterns that appear most frequently in real-world exploits. The Top 10 is not a comprehensive taxonomy; it is a prioritised starting point. A team that eliminates all Top 10 exposures has removed the majority of the attack surface that criminal actors actually exploit.

The 2025 update

The 2025 edition reflects significant changes from 2021. Software Supply Chain Failures enters at A03, reflecting the explosion of attacks via third-party dependencies (SolarWinds, Log4Shell, XZ backdoor). Injection drops to A05. Mishandling of Exceptional Conditions is new at A10, covering scenarios where applications behave unpredictably when errors occur.

Guidance

The OWASP Top 10:2025

Applying the Top 10 in a sprint

The Top 10 is most effective as part of the Definition of Done or as a code review checklist for high-risk tickets. Not every ticket introduces security risk, but these delivery events warrant a Top 10 review:

• Any ticket touching authentication, session management, or access control
• New API endpoints or data ingestion paths
• Dependency version updates
• Changes to encryption, key storage, or credential handling
• New integrations with external services

Examples

A01: Broken Access Control — IDOR

// Vulnerable: uses user-supplied ID, no ownership check
app.get('/api/invoices/:id', async (req, res) => {
  const invoice = await db.findInvoice(req.params.id);
  res.json(invoice); // Returns any user's invoice to any authenticated user
});

// Fixed: verify the requesting user owns the resource
app.get('/api/invoices/:id', async (req, res) => {
  const invoice = await db.findInvoice(req.params.id);
  if (!invoice || invoice.ownerId !== req.user.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  res.json(invoice);
});

A05: Injection — SQL

// Vulnerable: user input in raw SQL
const query = `SELECT * FROM users WHERE email = '${email}'`;

// Fixed: parameterised query
const result = await db.query('SELECT * FROM users WHERE email = $1', [email]);

A03: Supply Chain

# Lock your dependency tree and audit regularly
npm ci            # Uses package-lock.json exactly
npm audit         # Reports known vulnerabilities
npm audit fix     # Fixes safe to auto-upgrade

Anti-patterns

1. Security review only at the end of the sprint

Security issues found after implementation cost 10× more to fix. Security review belongs in refinement (for design) and code review (for implementation), not as a post-hoc gate.

2. “We’ll add authentication later”

A01 (Broken Access Control) and A07 (Authentication Failures) consistently top the list precisely because they are deferred to “later”. Authentication and authorisation must be designed in, not added on.

3. Trusting client-supplied data

Any data that arrives from a browser, mobile app, or API client is untrusted. Server-side validation and sanitisation are non-negotiable regardless of what the frontend validates.

4. Ignoring npm audit / pip audit output

Dependency vulnerability warnings are A03 in actionable form. Teams that silence or ignore these reports accumulate supply chain debt.

5. Stack traces in production error responses

A02 (Security Misconfiguration) commonly manifests as development-mode error responses shipped to production. Stack traces expose file paths, library versions, and internal structure useful to attackers.

Related practices

• Input Validation
• Secrets Management
• Principle of Least Privilege

Part of the PushBackLog Best Practices Library. Suggest improvements →