The most important web security threats are the categories in the OWASP Top 10: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, authentication failures, integrity failures, logging gaps and server side request forgery. Broken access control leads the 2021 list, so check authorization first.
Which threats rank highest?
The OWASP Top 10 (2021 edition, the current published list at the time of writing) is built from data and community input. Its ten categories, in order, are:
- Broken Access Control
- Cryptographic Failures
- Injection
- Insecure Design
- Security Misconfiguration
- Vulnerable and Outdated Components
- Identification and Authentication Failures
- Software and Data Integrity Failures
- Security Logging and Monitoring Failures
- Server-Side Request Forgery
The list is awareness guidance, not a complete standard, so treat it as a minimum.
What does broken access control look like?
The server fails to enforce what a user may do. A user changes an identifier in a URL and sees someone else's invoice, or a normal user calls an admin endpoint because only the menu hides it. The fix is enforcement on the server for every request, with deny by default.
What about injection?
Untrusted data is sent to an interpreter as part of a command or query. SQL injection is the classic case. The durable fix is to keep data and commands separate with parameterized queries, and to validate input as defense in depth. Cross site scripting is grouped under injection in this edition, and output encoding in the correct context is the main defense.
Constructed example: a profile page
A site shows a profile at a URL with the user's numeric ID. The page loads, but the server never checks that the logged in user owns that ID (access control). The bio field is inserted into the page without encoding (injection, via script). The page also pulls an avatar from a user supplied URL on the server side, so an attacker can make the server request internal addresses (server side request forgery). One small page, three categories.
None of these need unusual skill to exploit. Each has a standard fix: check ownership, encode output, and allow only approved destinations for server side requests.
Why do components and misconfiguration matter?
Most applications are mostly third party code. A vulnerable library carries its flaws into your product, which is why the list includes vulnerable and outdated components. Keep an inventory, update regularly and know which flaws your code actually reaches. Misconfiguration covers default accounts, verbose error pages, open storage and missing security headers. These are fixed by a hardened, repeatable baseline rather than by hand.
Safeguard's dependency scanning and reachability analysis address the components category, and its static analysis covers code level flaws like injection patterns, so findings appear in the same place as your other work.
What is often forgotten?
Logging. Without logs of logins, access failures and sensitive actions, you cannot tell an attack from a quiet Tuesday. Log enough to investigate, protect the logs, and do not record secrets or full card numbers in them.
How to check or apply this
- Enforce authorization on the server for every route, deny by default, and test with two user accounts.
- Use parameterized queries and context aware output encoding everywhere.
- Store passwords with a slow, salted hash designed for passwords, and require multi factor authentication for sensitive accounts.
- Encrypt data in transit and at rest, and avoid homegrown cryptography.
- Keep dependencies updated and track known vulnerabilities in them.
- Use a hardened configuration baseline, and remove defaults and debug features in production.
- Allow server side requests only to approved destinations.
- Log security events, alert on anomalies and protect the logs.
Quick check
Is the OWASP Top 10 a complete list of web risks?
No. It is an awareness document covering the most critical categories. Use it as a starting point, not a ceiling.
What is the first thing to test in a web app?
Access control. Try accessing another user's data and admin functions with a normal account.
Sources
Last reviewed: 18 October 2026.
