The OWASP Top 10 is a widely referenced list of the most significant categories of web application security risk, published by the Open Worldwide Application Security Project. Large enterprises use it to shape secure development programmes, but it is just as useful for small and mid-sized businesses that run a customer portal, an online shop, or a SaaS product. This guide translates the categories into plain questions an SME can ask of its own applications and suppliers.
What It Is
The Top 10 is an awareness document that helps teams focus on the most common web application risks. Each category groups related weaknesses. The current 2025 edition, which replaced the 2021 list, covers: broken access control (which now also includes server-side request forgery); security misconfiguration; software supply chain failures; cryptographic failures; injection; insecure design; authentication failures; software or data integrity failures; logging and alerting failures; and mishandling of exceptional conditions. Many questionnaires and contracts still refer to the 2021 edition, so confirm which version a customer or partner expects when you set requirements. For an SME, the value lies less in memorising the list and more in using it as a checklist of questions: who can see what, how passwords and sessions are handled, which components are out of date, and whether anyone would notice an attack in progress.
Who It Is For
This checklist is written for:
- SMEs that operate a customer-facing web application, portal, or online shop
- Founders and managers who commission development from an agency or freelancer and need to ask informed questions
- Small internal teams without a dedicated security role
- Businesses preparing for a customer security questionnaire that references OWASP
What It Helps Clarify
Working through the categories helps clarify:
- Whether users can only see and change the data their role allows
- Which third-party libraries, plugins, and frameworks are outdated or unmaintained
- Whether configuration, secrets, and error messages expose more than they should
- Whether logging would let you notice and investigate suspicious activity
What's Included
- Access control: test that a user cannot view or edit another customer's records by changing an ID in the URL or request, and restrict which internal or external addresses the application can be made to call
- Cryptography: confirm HTTPS everywhere, modern TLS, and that passwords are stored with a strong hashing algorithm
- Injection: check that inputs are validated and database queries are parameterised
- Design: document how sensitive workflows such as password reset, payments, and refunds should behave, including abuse cases
- Misconfiguration: remove default accounts, disable debug output, and review security headers
- Supply chain: keep an inventory of libraries, plugins, and build tools, patch on a defined schedule, and remove unmaintained components
- Authentication: offer multi-factor authentication for admins and limit repeated login attempts
- Integrity: protect build and deployment pipelines and verify updates come from trusted sources
- Logging and alerting: record logins, permission changes, and administrative actions, and make sure alerts reach someone who reviews them
- Exceptional conditions: make sure errors, timeouts, and unexpected inputs fail safely, without exposing stack traces or skipping security checks
What's Not Included
- A statement that addressing the Top 10 makes an application secure; it is a useful starting point for broader coverage
- Certification or formal compliance approval
- Step-by-step exploitation techniques
- Coverage of risks outside web applications, such as internal networks or physical security
When to Choose It
Use the checklist when you plan new features, when you onboard a development supplier, and before a launch or major release. If several answers are "we don't know", that is a signal to commission an independent review rather than rely on assumptions. If a customer or partner asks for evidence of OWASP-aligned testing, a documented application security review or penetration test will usually be more persuasive than a self-assessment.
Our Approach
Start with access control and authentication, because they are frequently where serious issues appear in business applications. Ask your developers or supplier to walk through how each role is enforced on the server, not just hidden in the interface. Then inventory components and agree an update routine. Make sure secrets are not stored in code repositories, and that error pages do not reveal stack traces. For an independent view, our Application Security Review examines agreed web applications and APIs against common application risks, including the OWASP categories, and delivers severity-graded findings with remediation guidance. If your concern is mainly a CMS-based website, website hardening may be the more proportionate step. Whatever you choose, build the checklist into your release process so each change is considered against it, rather than treating security as a one-off event before launch.
Frequently Asked Questions
Related Articles
Get Started
Want an independent view of your web application?
Tell us about the application, its user roles, and any upcoming launch or customer request. We will propose a scoped review.
Request a written scope