If you commission a website, customer portal or online store, someone has probably mentioned "OWASP" in a proposal or a security questionnaire. It sounds technical, but the ideas behind it are straightforward and directly affect your business risk. This article gives you the OWASP Top 10 explained in plain language: what each risk means, how it shows up in real business platforms, and the questions you can ask your developers to make sure it is being handled. You do not need to write code to use this; you need to know what good looks like.
What the OWASP Top 10 is (and is not)
The OWASP Top 10 is a list of the most critical categories of web application security risk, maintained by the Open Worldwide Application Security Project. It is refreshed every few years using data from real applications and input from security practitioners. The most recent edition is the 2025 list, which updated the 2021 version; most categories carried over, with some renamed, merged or added.
Think of it as a map of where things most often go wrong, not a complete security standard. It is useful for:
- Briefing non-technical stakeholders on application risk.
- Setting expectations in development contracts.
- Prioritizing code reviews and testing.
- Answering client and partner security questionnaires.
Key takeaway: You do not need to memorize the list. You need a development partner who can explain, for each item, how your platform is protected and how they know.
The OWASP Top 10 explained, one risk at a time
The numbering below follows the 2025 edition. For each one, we describe the risk in business terms, an example, and what you should ask.
1. Broken access control
What it means: Users can see or do things they should not. A customer views another customer's invoice by changing a number in the address bar, or a staff member reaches admin functions they were never given.
Why it matters: This has topped the list for years because it is easy to get wrong in custom features and hard to catch with automated scanners.
Ask: "Is every request checked on the server against the logged-in user's permissions? How do you test that one user cannot access another's data?"
2. Security misconfiguration
What it means: The software is fine, but it is set up unsafely: debug mode left on in production, default passwords, directory listings, overly permissive cloud storage or missing security headers.
Ask: "How do you make sure production settings differ from development? Do you have a hardening checklist for servers and the application?"
3. Software supply chain failures
What it means: Modern platforms are assembled from many third-party packages, plugins and build tools. A vulnerable or compromised component becomes your vulnerability.
Ask: "How do you track the libraries and plugins we depend on? Are dependencies scanned automatically, and how quickly are security updates applied?"
4. Cryptographic failures
What it means: Sensitive data is not properly protected in transit or at rest. Examples include pages without HTTPS, passwords stored with weak hashing, or personal data sitting unencrypted in backups.
Ask: "Which data is encrypted, where are the keys kept, and how are passwords stored?"
5. Injection
What it means: Attackers send input that the system mistakenly treats as commands, for example SQL injection into a search box or script injection (cross-site scripting) into a comment field.
Ask: "Do you use parameterized queries or an ORM everywhere? Is output escaped by default in templates?"
6. Insecure design
What it means: The flaw is in the logic, not the code. A password reset that can be guessed, a discount that can be applied unlimited times, or a booking flow that lets someone reserve every slot without paying.
Ask: "Do you think through abuse cases during design, not only the happy path? Are there limits on sensitive actions?"
7. Authentication failures
What it means: Weaknesses in login and session handling: no protection against password guessing, sessions that never expire, or no two-factor option for administrators.
Ask: "Is there rate limiting on login and password reset? Is two-factor authentication available, and enforced for admins?" Our guide to adding two-factor authentication covers the options.
8. Software or data integrity failures
What it means: The system trusts code or data it should verify, such as updates downloaded without integrity checks, scripts loaded from third-party servers that could be altered, or serialized data accepted from users.
Ask: "How do you verify the integrity of deployments and updates? Which external scripts load on our pages, and who controls them?"
9. Security logging and alerting failures
What it means: An attack happens and nobody notices, or there are no records to investigate afterwards.
Ask: "What security events are logged? Who receives alerts, and how quickly would we know about a suspicious admin login?"
10. Mishandling of exceptional conditions
What it means: The application behaves unsafely when something unexpected happens: an error reveals internal details, a failed payment callback still marks an order as paid, or a timeout leaves a process half-completed in an exploitable state.
Ask: "How does the system fail? Do errors fail safely, and are detailed error messages hidden from users?"
A quick reference table
| Risk | Business example | Primary control |
|---|---|---|
| Broken access control | Customer sees another's orders | Server-side permission checks, tests |
| Security misconfiguration | Debug page exposes credentials | Hardened, reviewed configuration |
| Supply chain failures | Vulnerable plugin exploited | Dependency inventory and updates |
| Cryptographic failures | Unencrypted backup leaked | HTTPS, encryption, strong hashing |
| Injection | Database dumped via search box | Parameterized queries, escaping |
| Insecure design | Unlimited coupon reuse | Threat modelling, business limits |
| Authentication failures | Admin account brute-forced | Rate limits, 2FA, session rules |
| Integrity failures | Tampered third-party script | Signed updates, script control |
| Logging and alerting failures | Breach unnoticed for months | Centralized logs, alerts |
| Exceptional conditions | Failed payment marked as paid | Fail-safe error handling |
How to use the list in your projects
- Put it in the contract. Require that the platform is developed and tested with the OWASP Top 10 in mind, and ask for a short security summary at handover.
- Ask for evidence, not promises. Code review practices, automated dependency scanning and test results are more meaningful than a statement that "the site is secure."
- Choose mature frameworks. Frameworks such as Laravel provide built-in protections for injection, CSRF and password hashing, which reduces the room for mistakes. Our article on why Laravel suits business platforms explains more.
- Test periodically. For platforms that handle payments, health data or significant personal information, schedule independent testing. See penetration testing explained.
- Maintain it. New vulnerabilities appear in dependencies constantly; security decays without maintenance.
Where the Top 10 fits with privacy law
Privacy laws such as PIPEDA, BC PIPA, the UAE PDPL and the GDPR require reasonable or appropriate security safeguards without listing specific technical controls. Aligning your platform with the OWASP Top 10 is a practical, widely recognized way to demonstrate that you took those safeguards seriously. For legal interpretation, consult a privacy professional.
Next steps
Pick the three risks that feel most relevant to your platform, usually access control, authentication and supply chain, and ask your team the questions above. Their answers will tell you a lot about your real security posture.
At DigiVort, these risks are built into how we design and review custom web applications and SaaS platforms. If you want an independent look at an existing system, our security and compliance service can review it against the Top 10 and fix what we find.
