Web application security checklist based on the OWASP Top 10

This OWASP Top 10 checklist follows the OWASP Top 10:2025, the edition that replaced the 2021 list. For each of the ten risks you get a short explanation, how it typically shows up in Node, Next.js and PHP applications, and a checklist you can test against your own code before a release.

This article is general information, not legal advice. It supports your own security review, but it doesn't replace a penetration test.

If you're scoping a new build, our custom software development guide covers process, cost and choosing a partner. The Essential Eight is a useful companion: it covers baseline mitigations across the organisation, while this list covers how the application itself is built and run.

How to use this OWASP Top 10 checklist#

OWASP revises the list irregularly, based on vulnerability data and a community survey. The 2025 edition adds two categories, Software Supply Chain Failures and Mishandling of Exceptional Conditions, folds Server-Side Request Forgery (SSRF) into Broken Access Control, and moves Security Misconfiguration from #5 to #2. The sections below use the 2025 order and names. Treat every unticked item as a ticket, not a note.

A01:2025 — Broken Access Control#

Broken Access Control is still #1. It means users can reach data or actions they shouldn't: someone else's record, an admin function or an internal endpoint. OWASP found some form of it in 100% of the applications tested, and SSRF now sits in this category too.

How this shows up in a typical Node/Next.js/PHP app#

• A Next.js page hides the "Admin" link, but the API route behind it has no server-side role check.
• /api/orders/123 returns any order with that ID without checking it belongs to the logged-in user (an insecure direct object reference, or IDOR).

Checklist#

• Every route checks permissions server-side, never only in the frontend.
• Object-level checks confirm the user can access that specific record.
• New routes are closed by default.
• Logout invalidates the session or token on the server.

A02:2025 — Security Misconfiguration#

Security Misconfiguration rose from #5 to #2, and OWASP found some form of misconfiguration in 100% of the applications tested. It covers unnecessary features left on, default accounts still active, overly detailed error messages and missing security headers.

How this shows up in a typical Node/Next.js/PHP app#

• A staging PHP site or its phpMyAdmin still has default credentials, or the server shows PHP errors to visitors because display_errors is on.
• An Express API reflects any origin with credentials allowed, for example cors({ origin: true, credentials: true }), or a .env file is reachable over HTTP.

Checklist#

• No default credentials remain anywhere, including staging and internal tools.
• Production runs with NODE_ENV=production and PHP display_errors=Off, behind a generic error page.
• CORS allows only named origins, and never reflects arbitrary origins when credentials are allowed.
• A direct request confirms .env, .git and backup files aren't reachable, and CSP and HSTS headers are set deliberately.

A03:2025 — Software Supply Chain Failures#

Software Supply Chain Failures is new in 2025. It grew out of 2013's "Using Components with Known Vulnerabilities" to cover the whole chain from source code to running application: dependencies, build tools and CI/CD. OWASP's examples include the 2019 SolarWinds compromise and Shai-Hulud, a self-propagating npm worm that reached over 500 package versions in 2025.

How this shows up in a typical Node/Next.js/PHP app#

• The lockfile isn't committed, or CI runs npm install instead of installing from it, so builds pull unreviewed versions.
• A GitHub Actions workflow uses a third-party action by a mutable tag (@v2) rather than a pinned commit SHA.

Checklist#

• Lockfiles are committed, and CI installs from them (npm ci, or composer install with the lock present).
• Dependency upgrades go through a pull request and CI.
• npm audit or composer audit runs in CI and blocks known-critical issues.
• Third-party CI actions are pinned to a commit SHA.

A04:2025 — Cryptographic Failures#

Cryptographic Failures covers sensitive data, such as passwords, tokens and personal or payment details, that isn't properly protected in transit or at rest: weak algorithms, fast hashes for passwords, plain HTTP and leaked secrets. It sits at #4, down two places from #2 in 2021.

How this shows up in a typical Node/Next.js/PHP app#

• Passwords are hashed with MD5 or SHA-1 rather than bcrypt or Argon2 (PHP's password_hash() uses bcrypt by default).
• An API key sits in Git history, or a secret gets a NEXT_PUBLIC_ prefix so Next.js ships it to every browser.

Checklist#

• Passwords are hashed with bcrypt or Argon2.
• Secrets live in environment variables or a secrets manager, never in the repository or its history.
• Login, admin and payment pages are HTTPS-only.
• Client-exposed environment variables contain no secrets.

A05:2025 — Injection#

Injection happens when untrusted input reaches an interpreter, such as a database, a shell or a template, and runs as code. OWASP's category includes both SQL injection and cross-site scripting (XSS). It moved from #3 to #5, but it stays serious wherever a raw query or unescaped output slips through.

How this shows up in a typical Node/Next.js/PHP app#

• PHP concatenates $_GET['id'] into a SQL string instead of using a prepared statement.
• A Node script passes user input to child_process.exec(), which runs it through a shell.

Checklist#

• Every query is parameterised or built with an ORM's safe query builder.
• User input never reaches a shell; where a command is unavoidable, use execFile() with an argument list.
• Output is encoded for its context (HTML, attribute, URL).
• Every "raw" or "unsafe" escape hatch is reviewed individually.

A06:2025 — Insecure Design#

Insecure Design covers flaws in the design rather than the code, which is why code review misses them: the code does exactly what the design asked. Missing threat modelling and business logic that assumes honest users both belong here. It sits at #6, down from #4 in 2021.

How this shows up in a typical Node/Next.js/PHP app#

• A password-reset endpoint with no rate limit can be brute-forced or used to discover registered email addresses.
• A checkout API trusts a price or quantity sent by the browser.

Checklist#

• Login, password reset, checkout and contact forms are rate-limited.
• Prices and totals are recalculated server-side.
• Multi-step flows check on the server that earlier steps really happened.
• New features get a "how could this be misused?" review before they're built.

A07:2025 — Authentication Failures#

Authentication Failures, a slight rename of 2021's "Identification and Authentication Failures", covers weaknesses that let an attacker pass as a real user: credential stuffing, password spraying, missing multi-factor authentication and sessions that never expire. Without defences against automated attacks, OWASP warns, an application "can be used as a password oracle".

How this shows up in a typical Node/Next.js/PHP app#

• A login endpoint has no rate limit or lockout.
• An Express or Laravel session cookie lacks HttpOnly, Secure or a suitable SameSite setting, or a long-lived JWT has no way to be revoked.

Checklist#

• Login attempts are rate-limited, with a lockout or delay after repeated failures.
• Session cookies set HttpOnly, Secure and SameSite.
• Logout and password changes invalidate existing sessions and tokens.
• Admin accounts use multi-factor authentication.

A08:2025 — Software or Data Integrity Failures#

This category covers code or data trusted without checking that it hasn't been tampered with. Where A03 covers your whole supply chain, this one is about specific integrity checks: does a deploy verify what it ships, and does a webhook really come from who it claims? OWASP also places insecure deserialisation here.

How this shows up in a typical Node/Next.js/PHP app#

• A Stripe, GitHub or payment-gateway webhook handler acts on the payload without verifying its signature.
• PHP calls unserialize() on a cookie or request parameter.

Checklist#

• Every webhook verifies the provider's signature before acting.
• Deploys and auto-updates verify a signature or checksum.
• External data is parsed as JSON and validated, never deserialised into objects.
• CI/CD steps with deploy access are pinned and reviewed.

A09:2025 — Security Logging & Alerting Failures#

This category was renamed from "Security Logging and Monitoring Failures" to stress alerting: logs don't help if nobody is told when something suspicious happens. One of OWASP's example scenarios is a breach that went undetected for more than seven years.

How this shows up in a typical Node/Next.js/PHP app#

• Each server writes logs to a local file that nobody reads.
• Repeated failed logins or a spike in 500 errors triggers no alert.

Checklist#

• Logs are centralised where someone will actually read them.
• Failed logins, privilege changes and admin actions are logged with user, IP address, time and request ID.
• Alerts fire on patterns such as repeated failed logins, not only on downtime.
• Logs are protected from tampering and never capture passwords or card numbers.

If a breach happens anyway, a plan agreed in advance beats improvising: see our data breach response plan.

A10:2025 — Mishandling of Exceptional Conditions#

Mishandling of Exceptional Conditions is new in 2025. It covers what happens when something unexpected occurs, such as a timeout, a null value or a failed third-party call, and the application doesn't notice or responds badly. OWASP's guidance is to catch errors where they occur and, part way through a transaction, to roll back every part of it: fail closed, not open.

How this shows up in a typical Node/Next.js/PHP app#

• An API route awaits a third-party service with no error handling, so a timeout can crash the Node process or leak the raw error to the client.
• A PHP payment handler hits an error halfway through and carries on instead of rolling back.

Checklist#

• A global error handler returns a generic message and logs full detail internally.
• Error paths fail closed unless there's a documented reason not to.
• Multi-step operations roll back cleanly on failure.
• Calls to external services have timeouts and explicit failure handling.

OWASP Top 10:2025 checklist summary#

What to do next#

Work through the checklists against your own codebase, or share the relevant sections with whoever owns it. If you'd rather have hardening, monitoring, patching and incident response handled together as part of running your infrastructure, that's what our security and DevSecOps service covers.