OWASP Top 10 Vulnerabilities 2025: What to Test Before You Launch

The OWASP Top 10 is a ranked list of the ten most critical web application risk categories. OWASP’s co-leads describe it as a data-driven awareness document that helps organisations prioritise, so it is not a specification you pass or fail.

The 2025 edition draws on more than 2.8 million tested applications and 589 weakness types, called CWEs (Common Weakness Enumeration entries), according to OWASP's introduction. Each category groups many CWEs under one name.

The OWASP Top 10 2025 list runs from A01 Broken Access Control to A10 Mishandling of Exceptional Conditions. The table below shows how each category moved since the previous edition.

OWASP chose two of the ten categories, A03 and A09, from its community survey rather than testing data. Our recommendation: a black-box test alone, run from outside with no view of your build pipeline or logs, does not verify them.

Test broken access control (A01) and security misconfiguration (A02) first, because they hold the top two places in the 2025 list. One needs a person who understands your user roles. The other needs every environment compared against a hardened baseline.

A01:2025 Broken Access Control

What to test: Create two ordinary accounts and one admin account. Change object identifiers in URLs and request bodies so account A asks for account B's record. Open admin URLs as a normal user. Call each endpoint with methods the interface never uses. Replay a request after logout. SSRF, where a server is tricked into fetching an internal address, now sits in this category.

What a finding looks like (illustrative): "High: any signed-in customer can download another customer's invoice by changing the invoice ID. Evidence: request and response for two accounts. Fix: check record ownership on the server for every request."

How to test it: Manual test. A scanner does not know which user should see which record. OWASP reports an average incidence rate of 3.74% across 40 CWEs.

A02:2025 Security Misconfiguration

What to test: Compare staging and production against one hardened baseline. Look for debug mode, default credentials, sample applications, directory listing, detailed stack traces, missing security headers and publicly readable storage. Check every environment, since a setting fixed in one is often left behind in another.

What a finding looks like (illustrative): "Medium: the production login page returns a full stack trace and framework version on a malformed request. Evidence: screenshot of the response. Fix: return a generic error and log the detail internally."

How to test it: Automated scan for exposed files, headers and banners. Needs config, code or design review for server and cloud settings a scan cannot see. OWASP reports an average incidence rate of 3.00% across 16 CWEs.

Injection (A05) means untrusted input reaches an interpreter that runs it as a command. In the 2025 list the category covers Structured Query Language (SQL) injection and cross-site scripting. Test every place user input enters your application, and confirm that data stays separate from commands.

What to test: Every form field, query parameter, header, cookie, file name and hidden field. Confirm that database queries are parameterised, meaning user data is passed separately from the query text, and that output is encoded for the page where it lands.

What a finding looks like (illustrative): "High: the search parameter is joined into a database query; a single quote returns a database error. Evidence: request, response and extracted table names. Fix: use parameterised queries."

How to test it: Automated scan for common patterns. Manual test for filtered or context-dependent cases. Needs config, code or design review to confirm parameterisation in code.

SQL Injection

SQL injection puts attacker-controlled text into a database query. Try search boxes, filters, sort fields and login forms with a single quote and true/false conditions, then compare errors and response times. A pass is a rejected or unchanged response. Object-relational mappers (ORMs) do not make you immune: the OWASP testing guide lists ORM injection as its own test case.

Cross-Site Scripting

Cross-site scripting (XSS) lets an attacker run script in another user's browser. OWASP files it under A05 Injection and treats it as frequent but usually lower impact per instance. Test stored values shown to other users (profiles, comments, support tickets) and reflected values (search terms, error messages). A pass is script displayed as text, never executed.

Before launch, confirm that sensitive data is encrypted in transit and at rest, that login and session handling resist guessing and reuse, and that critical flows were designed with abuse in mind. The first two can be tested. The third needs a design conversation.

A04:2025 Cryptographic Failures

What to test: Transport Layer Security (TLS), the protocol that encrypts web traffic, at version 1.2 or later on every endpoint, HTTP redirecting to HTTPS with no downgrade, passwords stored with a slow hash such as Argon2, scrypt or PBKDF2, no keys or secrets in code, repositories or responses, and no caching of sensitive responses.

What a finding looks like (illustrative): "Medium: the server still accepts TLS 1.0 connections. Evidence: protocol scan output. Fix: disable TLS 1.0 and 1.1."

How to test it: Automated scan for protocols, certificates and headers. Needs config, code or design review for password hashing and key storage. OWASP reports an average incidence rate of 3.80% across 32 CWEs.

A07:2025 Authentication Failures

What to test: Multi-factor authentication for admin accounts, lockout or rate limiting on login and password reset, no default credentials, new passwords checked against common-password lists, a fresh session ID after login, and sessions that end on logout and after inactivity, including single sign-on logout.

What a finding looks like (illustrative): "High: 500 login attempts in one minute produced no lockout. Evidence: request log. Fix: add rate limiting and lockout, and require multi-factor authentication for admins."

How to test it: Manual test. Lockout and session behaviour depend on how your application is built.

A06:2025 Insecure Design

What to test: List your critical flows: signup, password reset, payment, booking, coupons, limited stock. For each, write abuse cases: what if a user repeats, reorders or automates this step? Check that tenants are separated in every tier.

What a finding looks like (illustrative): "Medium: a discount code can be applied repeatedly by resending the request. Evidence: three orders with one code. Fix: enforce one use per order on the server."

How to test it: Needs config, code or design review, then manual test to confirm each abuse case. A penetration test comes too late in the lifecycle to fix design flaws, so threat modelling (listing who would attack a feature and how) or design review should happen earlier.

NVISO notes that supply chain pipeline work typically falls outside a penetration test, and that exceptional conditions are often found almost by accident. That is why each of the four below needs an owner before launch, not only a test.

A03:2025 Software Supply Chain Failures

What to test: Produce a software bill of materials (SBOM), a list of every library and version you ship. Scan it against known-vulnerability databases, pin versions in lockfiles, install packages only from official registries, and review who can change your build pipeline and developer tools.

What a finding looks like (illustrative): "High: the application ships a library version with a published remote code execution flaw. Evidence: SBOM entry and advisory ID. Fix: upgrade, and add a dependency scan to the build."

How to test it: Automated scan for known-vulnerable components. Needs config, code or design review for the pipeline.

A08:2025 Software or Data Integrity Failures

What to test: Confirm that updates, third-party scripts and build artefacts are verified by signature or checksum, that CI/CD (continuous integration and delivery) access is segregated, and that the application rejects serialised data (objects converted to bytes for storage or transfer) from untrusted sources.

What a finding looks like (illustrative): "Medium: a third-party script loads with no integrity check. If that host were compromised, the script would run in every customer's browser. Fix: add a hash the browser verifies, or host the script yourself."

How to test it: Manual test for deserialisation endpoints. Needs config, code or design review for signing and pipeline controls.

A09:2025 Security Logging and Alerting Failures

What to test: Trigger failed logins, denied access requests and rejected input. Check that each produces a log entry with user context, that logs resist tampering, and that a named person receives an alert.

What a finding looks like (illustrative): "Medium: 200 failed logins in ten minutes produced no log entry naming the account and no alert. Evidence: log extract. Fix: log the events and alert above a threshold."

How to test it: Manual test: cause the events, then read the logs. Needs config, code or design review for alert rules.

A10:2025 Mishandling of Exceptional Conditions

What to test: Send missing parameters, wrong data types, oversized bodies, interrupted uploads and timeouts. Confirm the application fails closed (denies the action and rolls back the transaction), shows users a generic message, logs detail internally and releases resources. OWASP maps 24 CWEs to this category.

What a finding looks like (illustrative): "Medium: aborting a file upload leaves the connection and temporary file open; repeated, the server runs out of resources. Fix: release resources in every error path."

How to test it: Manual test, using deliberate faults. Scanners catch only verbose error pages.

Use this table as the release gate: ten rows, each with a test, the evidence that proves it passed, and the right method. A row passes only when you can attach the evidence, not when someone says it was checked.

Legend: Automated scan means a tool can do most of the work. Manual test means a person must try it. Needs config, code or design review means someone reads the settings, code or design documents.

The Top 10 does not cover business logic flaws specific to your application, the full range of application programming interface (API) risks, or cloud configuration beyond what a web test reaches. Treat it as minimum coverage, and decide early what else your launch needs.

Why a Checklist Is Not a Penetration Test

A test that only walks through the ten headings misses flaws specific to your application. A real test follows how your application works: its roles, its pricing rules, its approval steps.

NVISO goes further and calls it ill-advised to commission a test purely against the Top 10, because the list leaves out many ways to attack an application. Brief your tester on your roles and workflows instead. The FAQ below answers the question directly.

According to the IBM Cost of a Data Breach Report 2026, offensive security testing, such as red teaming and penetration testing, was the largest cost-reducing factor in India, saving organisations an average of INR 2.47 crore.

Business Logic Flaws

Business logic flaws are faults in your own rules, such as a coupon that can be reused or a booking system that lets one user reserve hundreds of seats at once. No list can name them in advance because they belong to your application. A06 Insecure Design is the nearest category, but finding these flaws takes a tester who learns your workflows and tries to misuse them.

APIs and Cloud

API risks sit in a separate OWASP list, the OWASP API Security Top 10. If your launch is API-heavy, plan for API testing alongside this table. Cloud settings such as storage permissions and identity roles can fall under A02, but a web application test sees only some of them. We also offer cloud infrastructure VAPT, so ask for a Cloud Security Assessment when your launch depends on cloud configuration.

Where the Top 10 Stops: ASVS and the Web Security Testing Guide

OWASP’s Application Security Verification Standard (ASVS) is the more testable standard: OWASP’s testing guide describes it as the baseline for what to test, and NVISO says it bases its own application assessments on ASVS.

The OWASP Web Security Testing Guide (WSTG) goes deeper on how to test. It is a community-maintained framework covering authentication, session management, input validation, error handling, cryptography and business logic, and it describes itself as neither a rigid checklist nor a compliance standard. Use it to turn each table row into detailed test cases.

Our web application VAPT at GS2 combines automated scanning with manual testing by our security experts, and ends in a report listing vulnerabilities, their risks, impact, evidence and recommended fixes. VAPT stands for Vulnerability Assessment and Penetration Testing. Our process has five steps:

Rows marked “Needs config, code or design review” in the table above are the ones to raise when you speak to us. Our contact form also lists secure code review and software composition analysis (SCA) as separate service options, so mention them if your launch depends on code or dependency checks.

For testing after launch, see our PTaaS (Penetration Testing as a Service) page.

To have your application tested before release, book a consultation and choose Web Application VAPT in the form. You can also call +91-9838391333 or email info@gs2cybersec.com. Tell us your stack, your user roles and whether the launch is API-heavy, and bring the checklist table above. Ask us about scope and pricing during the consultation. The service itself is described on the Web Application VAPT service page.