OWASP Top 10: 10 Web Application Risks and Practical Business Checks

The OWASP Top 10 groups major web app security risks so teams can discuss them in a common language. It helps a business ask better questions about a customer portal, online service, or internal CRM. However, it serves as an awareness starting point, rather than a complete test plan or a security certificate.

This article explains the ten categories in the 2025 edition, which remains the current released web app list at the time of writing. Each section connects a risk with a practical business example and a check you can request. The final sections show how to turn that discussion into owned work.

How to use the OWASP Top 10

The official OWASP Top 10:2025 names ten broad risk categories. The categories cover more than single coding mistakes. They also address design choices, settings, dependencies, and the way an app responds when something goes wrong.

Use the list to organize conversations around your own workflows. For instance, ask how the system protects customer records, verifies staff actions, and responds to a failed payment service. Then request evidence of the right controls.

The phrase “OWASP top 10 vulnerabilities” is common in searches, but each category can include many specific weaknesses. Therefore, a provider should explain the tests it performs, rather than simply promise an “OWASP scan.”

1. Broken Access Control

Access control decides who may view or change a resource. A login proves an identity, but it does not on its own grant permission to every record. This distinction matters in any app with customers, branches, or staff roles.

For example, a customer should see their own service report without seeing another customer’s report. The server needs to enforce that boundary even if someone requests a record directly. Hiding a menu item alone does not show permission.

Ask for a role and record matrix. Test both the allowed and denied action for each key workflow. Also include changes in status, such as a staff member moving to another branch or a customer account closing.

2. Security Misconfiguration

Apps depend on settings across servers, frameworks, storage, and cloud services. A poorly chosen setting can expose data or make a feature easier to misuse. These problems can arise even when the app code follows sound practices.

For instance, a document store may allow wider access than the portal intends. A live error page may also reveal internal details. Therefore, review the deployed setup, rather than assume a successful staging test covers every live setting.

Ask who owns setup, how changes receive review, and how the team checks differences across environments. Keep development tools and test accounts out of routine live access. Then review settings again when infrastructure changes.

3. Software Supply Chain Failures

Modern software relies on packages, build tools, services, and update channels. Supply chain risk concerns how those components enter and move through your delivery process. It extends beyond checking whether one library has a known flaw.

A compromised build process could affect software even when your own source code has not changed. Similarly, an unreviewed dependency update can introduce new behavior. As a result, the team needs visibility into inputs and control over releases.

Request an inventory of key dependencies and a clear update process. Check who can change build settings and publish releases. Also ask how the team verifies that the deployed artifact came from the reviewed source and approved build.

4. Cryptographic Failures

Cryptography protects details through methods such as encryption and secure password handling. Failures can come from poor choices, weak key management, or leaving sensitive data outside the intended protection. Simply saying “we use encryption” leaves many questions open.

For example, a business might protect web traffic but place an unprotected export in a shared folder. Another system might encrypt stored records while giving too many staff access to the keys. The actual data path matters.

Map where sensitive details travels and rests. Then ask how the team protects each location and controls key access. Avoid designing custom cryptographic schemes when proven, supported approaches fit the need.

5. Injection

Injection happens when an app treats untrusted input as instructions in an unintended way. It can affect database queries, commands, or other interpreters. The specific weakness depends on how the app builds and handles those operations.

A search form, report filter, or uploaded file can introduce untrusted content. Therefore, developers need safe interfaces and clear handling of that input. A check in the browser alone does not protect the server.

Ask the development team to explain its safe query and input-handling patterns. Then request code review and focused tests for the key entry points. The goal is to remove dangerous interpretation, rather than rely on a short list of blocked characters.

6. Insecure Design

Insecure design concerns the way a system works, rather than only a mistake in its setup. A feature can follow its written rules precisely while those rules create unacceptable risk. This makes early planning essential.

Imagine a refund workflow that lets one user create and approve any refund. The code might work as designed, yet the business may need a separate approver for large amounts. No generic scan can choose that policy for you.

Discuss misuse cases before building the feature. Ask what a dishonest user or a compromised account could do with valid access. Next, define limits, approvals, and evidence that fit the actual business process.

7. Authentication Failures

Authentication checks who a user is. It includes sign-in, session handling, recovery, and other identity-related flows. A strong first login does not fix a weak password reset or a session that remains active after account removal.

For a staff portal, review how users join, change roles, and leave. Also check sensitive actions that may need a fresh identity check. These transitions often reveal gaps that ordinary sign-in tests miss.

Ask for tests around expired sessions, recovery requests, and account suspension. In addition, review administrator access and the controls that protect it. Use supported identity systems where they meet the needs, with careful integration and setup.

8. Software or Data Integrity Failures

Integrity concerns whether the system can trust software and data that influence its behavior. Failures can arise when an app accepts updates, messages, or other key inputs without sound checks. The issue is trust in the source and content.

For example, a portal may receive a payment notification from an external service. It should verify the message through the provider’s supported mechanism and relate it to the correct business record. An unverified message should not mark an invoice as paid.

List the external inputs that trigger key actions. Then document how the system verifies them and handles unexpected values. Also test repeated and out-of-order events, since integrity includes keeping valid business state through those conditions.

9. Security Logging and Alerting Failures

A system needs useful records of key security events and a process to respond to them. Logs that nobody reviews may provide little help during an incident. In contrast, noisy alerts can make real concerns harder to spot.

Decide which actions deserve attention, such as repeated failed access, changes to privileged users, and unusual exports. Keep enough context to inspect without copying secrets or needless personal data into logs.

Ask who receives alerts, when they review them, and what they do next. Then run a controlled test of the response. A log entry in a file does not prove that an named person will notice a serious event.

10. Mishandling of Exceptional Conditions

Apps need safe behavior when inputs, services, or internal operations fail. An exceptional condition might involve a timeout, missing value, or unexpected resource limit. The system must not accidentally grant access or corrupt records while handling it.

Consider an approval check that relies on another service. If that service fails, the app needs an explicit response. Silently allowing the action may create a risk that normal successful tests never reveal.

Test failures with care in a controlled environment. Include interrupted requests, not available services, and incomplete data. Confirm that the system keeps a clear state, gives users useful feedback, and supports recovery without duplicating key actions.

Turn the categories into an app plan

Start with a map of your key workflows and data. For each workflow, find right risks and choose evidence that would show the expected control. This is more useful than assigning one generic test to each category.

The OWASP App Security Verification Standard provides detailed needs that teams can use when designing and checking controls. Select the right needs and record the version. The Top 10 supplies awareness, while a verification plan needs greater precision.

Our guide to security testing in software testing explains how to connect scope, findings, and release evidence. Use an owner and a next action for each confirmed issue. Then track the change through retesting.

Also combine methods. Code analysis, dependency review, setup checks, and authorized software penetration testing each inspect different aspects of risk. State what remains outside coverage so the business can decide what to do next.

What to ask before accepting a security claim

If a provider says an app is “OWASP compliant,” ask exactly what that means. Which edition, needs, methods, roles, and app version did the team use? Request a report that supports the claim with evidence.

For a custom CRM, discuss these expectations during custom crm development planning. Security decisions affect user roles, records, integrations, and support. Leaving them until the end can make changes harder and more costly.

Finally, define how the process continues after launch. New features, staff changes, and dependency updates can alter exposure. A clear maintenance plan helps the business keep useful controls as the app grows.

A simple evidence pack for a customer portal

To make the categories actionable, choose one customer workflow and collect a small evidence pack. Start with the role rules and the data it touches. For a service-report download, list the customer, staff, and administrator permissions, including access after an account closes.

Next, record the right checks and their method. A code review may examine the permission helper. An app test may compare two customer accounts. A deployment review may inspect file storage access. Each method should answer a specific question rather than claim universal coverage.

Then attach results to the tested version. Include confirmed issues, their owners, and the evidence from retesting. If a control depends on an external identity or storage service, note that dependency and the setup the team reviewed.

Finally, keep unresolved questions separate from passing results. Perhaps the test covered normal users but not a partner API. That gap needs a next action and an owner. This pack gives a business reviewer a clear view of what the team checked and why it matters. It also creates a useful reference when a later feature changes the same workflow or introduces a new user role.

Use a shared language to drive clear action

The OWASP Top 10 helps teams discuss risk, but the useful work happens in specific controls and tests. Start with your key workflows, choose the right evidence, and assign follow-up. Then review that evidence whenever the app changes materially.