OWASP Top 10 web application security is the reference every development and security team is expected to know, yet the list only becomes useful when you see how the flaws actually behave in a running application. A category name like broken access control means little until you watch a tester change one number in a request and read another customer's data. This is the OWASP Top 10 in practice, written for Australian teams who build and defend web applications and APIs.
The Open Worldwide Application Security Project maintains the list from real-world data, and it also publishes a separate API Security Top 10 because APIs carry their own distinct risks. This article covers both, with real-world framing and a clear view of how web and API penetration testing catches each issue.
Broken Access Control: The Number One Risk
Broken access control sits at the top of the current OWASP Top 10, and for good reason. It is the risk that users can act outside their intended permissions, and it turns up in almost every application we test.
The most common form is insecure direct object reference, or IDOR. An application uses a value such as a record identifier in a request, but never checks that the person making the request is allowed to access that record. Change the identifier, and you see someone else's data. Variations let attackers escalate their own privileges, access administrative functions, or move between tenant boundaries in multi-tenant platforms.
These flaws are dangerous because they need no special tools. A browser and a little curiosity are often enough. They are also invisible to many automated scanners, because a scanner cannot know that record 1042 belongs to a different customer. Finding them reliably requires a human who understands how the application is meant to work.
Broken access control is also stubborn because it is a design problem, not a coding slip. Adding a check to one endpoint does not help if the next feature reintroduces the same gap. The organisations that keep it under control enforce authorisation centrally, in a single place every request must pass through, rather than scattering checks across the codebase where one is always forgotten.
Injection: Old Risk, Still Effective
Injection covers a family of attacks where untrusted input is interpreted as a command, and it remains firmly on the list despite being one of the oldest categories.
- SQL injection manipulates database queries to read, modify or destroy data, and in the worst cases to take control of the underlying server.
- Command injection runs operating system commands through a vulnerable input.
- Cross-site scripting injects code that runs in other users' browsers, enabling session theft and account takeover.
Modern frameworks have reduced injection where developers use them correctly, but the risk persists wherever input is concatenated into a query or command by hand, or where older code has not been updated. Parameterised queries, strict input validation and output encoding remain the reliable defences.
Server-Side Request Forgery
Server-side request forgery, or SSRF, earned its own place on the OWASP Top 10 as applications increasingly fetch remote resources on the user's behalf. In an SSRF attack, the attacker causes the server to make requests to destinations they choose.
The impact is amplified in the cloud. A successful SSRF attack can reach internal services that are not meant to be exposed, and it can target the cloud metadata endpoint to retrieve temporary credentials for the workload. That single step has driven some of the largest breaches on record. Defences include validating and restricting outbound requests, segmenting networks so internal services are not reachable, and hardening the cloud metadata service.
Authentication and Session Flaws
Identification and authentication failures cover the many ways login and session handling go wrong. In practice we see:
- Weak or missing protection against credential stuffing and brute force, allowing attackers to test stolen passwords at scale.
- Missing or poorly enforced multi-factor authentication on sensitive accounts.
- Session tokens that do not expire, can be predicted, or are exposed in ways that allow hijacking.
- Password reset flows that leak information or can be abused to take over accounts.
Authentication is where an attacker most wants to succeed, because a valid session bypasses many other controls entirely. Testing these flows carefully, including the edge cases developers rarely consider, is essential.
Security Misconfiguration and Vulnerable Components
Two closely related categories account for a large share of real findings.
Security misconfiguration covers insecure defaults, unnecessary features left enabled, verbose error messages that leak internal detail, missing security headers and overly permissive settings. Applications are complex, and every layer from the framework to the web server to the cloud platform can be misconfigured.
Vulnerable and outdated components covers the third-party libraries and dependencies that make up most modern applications. A single outdated component with a known vulnerability can compromise the whole application, which is why maintaining an accurate inventory and patching promptly matters as much as securing your own code.
The API-Specific Risks
APIs share many risks with traditional web applications, but they add their own, which is why OWASP maintains a separate API Security Top 10. APIs expose object-level and function-level operations directly, often to many clients, and they are built for automation, so flaws can be exploited at scale in seconds.
| API risk | What it means |
|---|---|
| Broken object-level authorisation | The API-level cousin of IDOR: missing checks on who can access which object |
| Broken authentication | Weak or flawed token handling and login mechanisms |
| Broken function-level authorisation | Ordinary users reaching privileged or administrative operations |
| Excessive data exposure | Endpoints returning far more data than the client needs |
| Unrestricted resource consumption | Missing rate limits allowing abuse and denial of service |
Broken object-level authorisation is consistently the most damaging, because it is easy to introduce and easy to exploit. Since APIs power mobile apps, integrations and modern web front ends, an authorisation flaw in one endpoint can expose enormous volumes of data.
How Web and API Penetration Testing Catches Them
Automated scanners are valuable for breadth, catching some injection flaws, missing headers and known vulnerable components at scale. But the most damaging risks, broken access control, business logic flaws and API authorisation issues, require human judgement, because they depend on understanding how the application is meant to work.
Effective web and API penetration testing combines both. Expert operators map the application, understand its intended logic, then probe every trust boundary the way a real attacker would: changing identifiers, replaying tokens, chaining an SSRF flaw into credential theft, and testing whether an ordinary user can reach an administrative function. For a broader inventory of weaknesses across your estate first, vulnerability assessments provide the wider view, and where you want to test detection and response as well as the application, red teaming simulates a determined adversary end to end. Our AI offensive security work also models how attackers are using automation to find these flaws faster in 2026.
Because applications change far more often than infrastructure, testing works best when it is repeated after significant releases and paired with security checks in the development pipeline.
Turning the List Into Real Assurance
The OWASP Top 10 is a prioritised starting point, not a finish line. Its real value comes from seeing how each risk behaves in your own applications and APIs, and then proving whether your controls actually stop it.
If you want your web applications and APIs tested against the OWASP Top 10 and the API Security Top 10 by people who exploit these flaws for a living, our team of expert operators can help. Explore our penetration testing services or get in touch for a scoping conversation. You can also call StrikeCyber on 1300 654 898.
Frequently asked questions
What is the OWASP Top 10?
The OWASP Top 10 is a widely used awareness document that lists the most critical security risks to web applications, published by the Open Worldwide Application Security Project. It is compiled from real-world data and expert consensus, and it is refreshed periodically to reflect how attacks evolve. The current list is led by broken access control, followed by risks such as cryptographic failures, injection, insecure design and security misconfiguration. It is best treated as a prioritised starting point for building secure applications and for scoping testing, rather than an exhaustive checklist.
What is broken access control and IDOR?
Broken access control is the risk that users can act outside their intended permissions, and it currently sits at the top of the OWASP Top 10. A common form is insecure direct object reference, or IDOR, where an application uses a value such as a record identifier in a request and fails to check that the requesting user is actually allowed to access that record. By simply changing the identifier, an attacker can view or modify other users' data. These flaws are extremely common in both web applications and APIs, and they are a primary focus during testing.
How is API security different from web application security?
APIs share many risks with traditional web applications but add their own. OWASP maintains a separate API Security Top 10 precisely because APIs expose object-level and function-level operations directly, often to many clients, and frequently handle authorisation in ways that are easy to get wrong. Broken object-level authorisation, broken authentication and excessive data exposure are among the most damaging API-specific issues. Because APIs are designed for automation, flaws can also be exploited at scale very quickly, which makes dedicated API testing essential rather than optional.
What is SSRF and why is it on the OWASP Top 10?
Server-side request forgery, or SSRF, is where an attacker causes a server to make requests to destinations the attacker chooses. It earned its place on the OWASP Top 10 because modern applications frequently fetch remote resources, and cloud environments make the impact severe. A successful SSRF attack can reach internal services, cloud metadata endpoints and other systems that are not meant to be exposed. Defences include validating and restricting outbound requests, segmenting networks, and hardening the cloud metadata service so stolen requests cannot retrieve credentials.
Can automated scanners find OWASP Top 10 issues?
Automated scanners are useful for finding certain well-defined issues at scale, such as some injection flaws, missing security headers and known vulnerable components. However, many of the most damaging risks, especially broken access control, business logic flaws and API authorisation issues, require human judgement to identify because they depend on understanding how the application is meant to work. The most effective approach combines automated scanning for breadth with skilled manual penetration testing for the depth that scanners cannot reach.
How often should web applications and APIs be tested?
Web applications and APIs should be tested at least annually and after any significant change, such as a major feature release, a new integration or an architectural update. Because applications change far more often than infrastructure, many organisations pair periodic in-depth penetration testing with security checks built into the development pipeline. High-value applications that handle sensitive data or payments warrant more frequent testing. The goal is to catch new flaws close to when they are introduced, rather than discovering them long after they ship.