OWASP Top 10 (2025): Developer Checklist and Fixes

The OWASP Top 10 is the industry's most referenced list of web application security risks. The 2025 edition reflects the current threat landscape, and by 2026 every development team should have concrete mitigations in place for each category. This article translates the OWASP list into a developer checklist with specific fixes, validation methods, and the mistakes that teams make most often.

It is written for developers, tech leads, and security engineers who build and maintain web applications. The security hub covers broader security resources, and the application security path provides a structured progression from threat modelling to enterprise defence.

A01: Broken Access Control

Access control failures remain the number one risk. Users accessing resources or functions they should not be able to reach.

Checklist

• Deny by default. Every endpoint should require authentication unless explicitly marked as public.
• Enforce server-side access checks on every request. Client-side checks are insufficient.
• Validate that the authenticated user owns or has permission to access the requested resource (object-level authorisation).
• Return 403 (Forbidden) for authorisation failures, not 404 (Not Found)—unless resource existence itself is sensitive.
• Log all access control failures for monitoring and incident response.

Common mistake

Relying on hidden UI elements instead of server-side checks. If a button is hidden but the API endpoint is unprotected, the control is bypassed with a single curl command.

A02: Cryptographic Failures

Sensitive data exposed through weak or missing encryption.

Checklist

• Classify data by sensitivity. Know what is PII, credentials, financial data, and health data.
• Encrypt data in transit (TLS 1.2+ on all connections; prefer TLS 1.3).
• Encrypt data at rest for sensitive categories (database encryption, encrypted backups).
• Use strong, current algorithms (AES-256, SHA-256 minimum; avoid MD5 and SHA-1).
• Store passwords with bcrypt, scrypt, or Argon2—never plaintext, never reversible encryption.
• Rotate encryption keys on a defined schedule.

Common mistake

Encrypting the database but storing database credentials in plaintext environment variables accessible to all team members.

A03: Injection

Untrusted data sent to an interpreter as part of a command or query.

Checklist

• Use parameterised queries for all database operations. Never concatenate user input into SQL strings.
• Use ORM/query builder methods that handle parameterisation automatically.
• Validate and sanitise all user input on the server side.
• Apply Content Security Policy headers to mitigate XSS.
• Escape output based on context (HTML, JavaScript, URL, CSS).

Common mistake

Sanitising input for SQL injection but not for the template engine, allowing server-side template injection.

A04: Insecure Design

Security flaws rooted in the design phase rather than implementation.

Checklist

• Include threat modelling in the design phase of new features.
• Define security requirements alongside functional requirements.
• Use abuse cases ("As an attacker, I want to...") in your design process.
• Review designs for privilege escalation paths, data exposure, and trust boundary violations.

Common mistake

Designing a password reset flow that confirms whether an email address exists in the system, enabling user enumeration.

A05: Security Misconfiguration

Default or incomplete configurations that leave the application vulnerable.

Checklist

• Remove default credentials and accounts from all environments.
• Disable directory listing, debug endpoints, and stack trace exposure in production.
• Set security headers: X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Content-Security-Policy.
• Review cloud infrastructure configuration (S3 bucket policies, IAM roles, network security groups).
• Automate configuration scanning with tools appropriate to your stack.

Common mistake

Leaving debug mode enabled in production because "we will turn it off later."

A06: Vulnerable and Outdated Components

Using libraries, frameworks, or platforms with known vulnerabilities.

Checklist

• Maintain an inventory of all dependencies (direct and transitive).
• Run automated vulnerability scanning in CI (npm audit, pip-audit, or similar).
• Set a policy for vulnerability response times: critical within 48 hours, high within one week.
• Remove unused dependencies. Every dependency is attack surface.

Common mistake

Ignoring transitive dependency vulnerabilities because "we do not use that function directly."

A07: Identification and Authentication Failures

Weak authentication that allows credential stuffing, brute force, or session hijacking.

Checklist

• Implement rate limiting on authentication endpoints.
• Enforce multi-factor authentication for privileged accounts.
• Use secure session management (HTTP-only cookies, secure flag, reasonable expiry).
• Invalidate sessions on password change and logout.
• Do not expose session IDs in URLs.

Common mistake

Implementing rate limiting per IP address but not per account, allowing distributed brute force attacks.

A08: Software and Data Integrity Failures

Assumptions about data integrity without verification.

Checklist

• Verify integrity of software updates, plugins, and dependencies (checksums, signatures).
• Protect CI/CD pipelines from unauthorised modification.
• Sign deployments and verify signatures before execution.
• Validate serialised data before deserialisation.

Common mistake

Auto-updating dependencies in production without integrity verification or testing.

A09: Security Logging and Monitoring Failures

Insufficient logging to detect, escalate, and respond to security incidents.

Checklist

• Log all authentication events (success and failure).
• Log all access control failures.
• Log all input validation failures.
• Ship logs to a centralised, tamper-resistant logging system.
• Set up alerts for anomalous patterns (login spikes, unusual API usage).
• Test your incident response process at least annually.

Common mistake

Logging sensitive data (passwords, tokens, PII) in security logs, creating a new attack surface.

A10: Server-Side Request Forgery (SSRF)

The application fetches resources from URLs supplied by users without validation.

Checklist

• Validate and sanitise all user-supplied URLs on the server side.
• Deny requests to private/internal network ranges (10.x, 172.16.x, 192.168.x, 169.254.x, localhost).
• Use allowlists for permitted destination domains where possible.
• Enforce network segmentation so the application server cannot reach sensitive internal services.

Common mistake

Blocking localhost but not 127.0.0.1, [::1], or DNS names that resolve to loopback addresses.

Validation strategy

After implementing fixes, validate with:

1. Automated SAST/DAST scanning in your CI pipeline.
2. Manual penetration testing at least annually.
3. Bug bounty programs for continuous external validation.
4. Tabletop exercises to test your incident response for each risk category.

Further reading on EBooks-Space

• Security topic hub — curated security reading lists
• Application Security learning path — structured progression from threat modelling to defence
• Counter-Hack Reloaded — hands-on network attack and defence methodology
• Linux topic hub — server-side security fundamentals