OWASP Top 10 Security Checklist for Developers

This checklist turns the OWASP Top 10:2021 list of web application security risks into practical checks developers can run during code review and before release. It is for PHP and web developers, testers and students. Each section is one OWASP category with specific things to verify in your code and configuration. The list is based on the 2021 edition; check owasp.org for any newer edition and map these checks to it.

0 of 58 checked

A01:2021 Broken Access Control

Deny access by defaultEvery route and API endpoint should require an explicit permission check, except truly public pages.
Check authorisation on the server for every requestHiding a button in the interface is not access control.
Check object ownership, not just loginChanging ?invoice=1001 to 1002 must not show another user's invoice (an IDOR flaw).
Protect admin areas by roleTest admin URLs while logged in as a normal user and while logged out.
Restrict CORS to trusted originsNever reflect any origin with credentials allowed.
Disable directory listing and remove backup files from the web rootFiles such as .git/, .env and .bak copies must not be downloadable.
Invalidate sessions on logout and expire them on the serverLogging out should end the session, not just delete the cookie in the browser.

A02:2021 Cryptographic Failures

Use HTTPS everywhere and enable HSTSRedirect HTTP to HTTPS and add Strict-Transport-Security once HTTPS is stable.
Use TLS 1.2 or 1.3 onlyDisable SSL and TLS 1.0/1.1. Test your server with an online TLS checker.
Hash passwords with a slow, salted algorithmIn PHP use password_hash() (bcrypt or Argon2). Never MD5, SHA-1 or unsalted hashes.
Classify sensitive data and do not store what you do not needPersonal data, card details and tokens should be minimised, and encrypted at rest where stored.
Use proven libraries for encryptionIn PHP use the Sodium extension; never write your own crypto.
Keep keys and secrets out of source codeUse environment variables or a secrets manager and rotate keys if they leak.
Generate tokens with a secure random functionUse random_bytes() or random_int(), not rand() or mt_rand().

A03:2021 Injection

Use prepared statements with bound parameters for all SQLNever build queries by joining strings with user input. PDO and MySQLi both support this.
Escape output for its context to prevent XSSUse htmlspecialchars($value, ENT_QUOTES, 'UTF-8') for HTML, or your template engine's auto-escaping.
Validate input with allow-listsCheck type, length, format and range on the server, for example sort columns against a fixed list.
Avoid passing user input to shell commandsIf unavoidable, use escapeshellarg() and a fixed command; prefer a library function instead.
Add a Content Security PolicyA CSP limits where scripts can load from and reduces the damage of an XSS bug.
Watch for injection in other interpretersLDAP, XPath, NoSQL queries, email headers and template engines can all be injected.

A04:2021 Insecure Design

Threat-model new features before building themAsk what could go wrong, who might abuse it and how you would detect it.
Add rate limits to sensitive flowsLogin, password reset, OTP verification, coupon and contact forms need limits per user and per IP.
Design business logic with abuse in mindFor example, recheck prices and quantities on the server at checkout rather than trusting the browser.
Use secure design patterns and shared componentsReuse a tested authentication and authorisation module instead of rewriting it per feature.
Write abuse cases alongside user stories"As an attacker, I try to reset another user's password" becomes a test case.

A05:2021 Security Misconfiguration

Turn off debug mode and detailed errors in productionSet display_errors=Off and use your framework's production environment.
Remove default accounts, sample apps and unused featuresChange all default passwords and uninstall what you do not use.
Set security headersInclude Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy and frame-ancestors (or X-Frame-Options).
Harden cloud storage and servicesCheck storage buckets are not public unless intended and that admin consoles are not exposed.
Keep configuration the same across environmentsAutomate server set-up so staging and production do not drift apart.
Disable XML external entities if you parse XMLXXE was merged into this category in 2021.

A06:2021 Vulnerable and Outdated Components

Keep an inventory of all dependenciesInclude Composer and npm packages, CMS plugins, server software and their versions.
Check for known vulnerabilities regularlyRun composer audit and npm audit, or enable automated dependency alerts in your Git host.
Run supported versions onlyCheck the PHP, framework and database support schedules and plan upgrades before end of life.
Remove unused packages and pluginsEvery unused component is still attack surface.
Download components only from official sourcesVerify package names carefully to avoid typosquatted packages.

A07:2021 Identification and Authentication Failures

Offer or require multi-factor authenticationPrioritise MFA for admin and high-value accounts.
Block weak and breached passwordsRequire a sensible minimum length and check against common and known-breached password lists rather than forcing complex rules.
Limit and slow down failed login attemptsLock out or add delays after repeated failures, and alert on unusual patterns.
Regenerate the session ID on loginIn PHP call session_regenerate_id(true) after successful authentication to prevent session fixation.
Use generic login error messages"Invalid email or password" avoids revealing which accounts exist.
Make password reset tokens single-use and short-livedSend them only to the registered email and expire them after use.

A08:2021 Software and Data Integrity Failures

Do not unserialise untrusted dataAvoid unserialize() on user input; use json_decode() instead.
Use Subresource Integrity for third-party scriptsAdd an integrity attribute to scripts and styles loaded from CDNs.
Commit and verify dependency lock filesKeep composer.lock and package-lock.json in version control.
Protect your CI/CD pipelineRestrict who can change build scripts and deploy, and keep pipeline secrets out of logs.
Verify signatures on updates and downloads where availableDo not auto-update from unverified sources.

A09:2021 Security Logging and Monitoring Failures

Log logins, failed logins, access denials and admin actionsInclude time, user, IP address and action.
Never log passwords, tokens or full card numbersMask sensitive values before writing them to logs.
Protect logs from tampering and injectionStore them away from the web root, encode user input in log entries and back them up.
Set alerts for suspicious activityFor example many failed logins, a new admin account or a spike in errors.
Keep logs long enough to investigateAgree a retention period that meets legal requirements; in India, CERT-In directions require some organisations to keep logs for 180 days.
Have an incident response planKnow who to call, how to contain an incident and how to report it.

A10:2021 Server-Side Request Forgery (SSRF)

Validate any URL the server fetches for a userUse an allow-list of permitted hosts and schemes (usually only https).
Block requests to internal and metadata addressesReject private ranges, localhost, 169.254.169.254 and similar, after resolving DNS.
Do not follow redirects blindlyA permitted URL can redirect to an internal address; disable redirects or re-check each hop.
Do not return raw responses to the userSend back only the data you expect, not the full fetched content or error details.
Segment the networkServers that fetch remote URLs should have limited access to internal systems.

Frequently asked questions

What is the OWASP Top 10?

It is an awareness document from the Open Worldwide Application Security Project that lists the most critical web application security risks. It is a starting point, not a complete security standard.

Is this checklist based on the latest OWASP Top 10?

It is organised by the 2021 categories. Check owasp.org for the current edition; most of these checks remain relevant because the underlying risks change slowly.

Is following the OWASP Top 10 enough to be secure?

No. For a fuller list of requirements use the OWASP Application Security Verification Standard (ASVS), and combine it with code review and testing.

Which item should a PHP developer fix first?

Start with prepared statements for SQL, output escaping, server-side access checks and password hashing, because these block the most common serious attacks.

OWASP Top 10 Security Checklist

How to use this checklist

A01:2021 Broken Access Control

A02:2021 Cryptographic Failures

A03:2021 Injection

A04:2021 Insecure Design

A05:2021 Security Misconfiguration

A06:2021 Vulnerable and Outdated Components

A07:2021 Identification and Authentication Failures

A08:2021 Software and Data Integrity Failures

A09:2021 Security Logging and Monitoring Failures

A10:2021 Server-Side Request Forgery (SSRF)

Frequently asked questions

What is the OWASP Top 10?

Is this checklist based on the latest OWASP Top 10?

Is following the OWASP Top 10 enough to be secure?

Which item should a PHP developer fix first?

Want to Learn This Properly?

How to use this checklist

A01:2021 Broken Access Control

A02:2021 Cryptographic Failures

A03:2021 Injection

A04:2021 Insecure Design

A05:2021 Security Misconfiguration

A06:2021 Vulnerable and Outdated Components

A07:2021 Identification and Authentication Failures

A08:2021 Software and Data Integrity Failures

A09:2021 Security Logging and Monitoring Failures

A10:2021 Server-Side Request Forgery (SSRF)

Frequently asked questions

What is the OWASP Top 10?

Is this checklist based on the latest OWASP Top 10?

Is following the OWASP Top 10 enough to be secure?

Which item should a PHP developer fix first?

More free templates

Want to Learn This Properly?