OWASP Top 10 Testing

The top category for a reason, and where we find the most serious issues. We test every authenticated action against every role, looking for insecure direct object references, functions reachable above a user’s privilege level, and multi-tenant apps where one customer can touch another’s data. Changing an ID in a request and getting back someone else’s record is the classic finding here.

We look at how sensitive data is protected in transit and at rest: weak or missing TLS configuration, secrets sent in URLs or logs, tokens and passwords stored or transmitted without proper protection, and reliance on outdated algorithms. The failure is rarely the maths; it is usually data that was never encrypted where it should have been.

SQL injection, command injection, and cross-site scripting all live here. We test every input that reaches a query, a shell, or the page: search boxes, filters, URL parameters, headers and API fields. Injection is less ubiquitous than a decade ago but still turns up in older reporting features and hand-built queries, and its impact is high when it lands.

This category is about flaws baked into how the application was designed rather than how it was coded. We examine trust boundaries, workflow logic and the assumptions your app makes about what a user can and cannot do. A password reset that trusts a value the user controls is not a coding bug; it is a design that never should have shipped.

Default credentials, verbose error messages, unnecessary features left enabled, missing security headers, and exposed admin interfaces. Misconfiguration is common, cheap for an attacker to find, and often the quickest route in. We audit the app’s configuration and the platform underneath it.

The framework two versions behind, the JavaScript library with a public advisory, the plugin nobody has updated since launch. We identify the components your app depends on and check them against known vulnerabilities, then confirm by hand whether an exposed component is actually reachable and exploitable rather than just old.

Weak password policies, missing rate limiting on login, session tokens that never expire, and multi-factor prompts that can be bypassed by requesting the post-login endpoint directly. We test the full authentication lifecycle, because account takeover usually comes from a chain of small weaknesses rather than one big flaw.

Insecure deserialization, update mechanisms that do not verify what they install, and trust placed in data from sources that can be tampered with. Where your app deserializes user-controlled data or pulls in code and content from third parties, we test whether that trust can be abused.

An attacker who leaves no trace, or whose attempts are never noticed, can take their time. We assess whether security-relevant events are logged and whether an attack would be visible, and we note the gaps. This category rarely produces an exploit on its own, but it decides how bad every other finding becomes.

SSRF earned its own place in the Top 10 because cloud-hosted apps made it so valuable. Where your app fetches a URL, imports from a link, or processes a webhook, we test whether it can be pointed at internal services and cloud metadata endpoints that were never meant to be reachable from outside.

We work through the Testing Guide test cases so every category is examined, then spend the remaining time going deep on the categories where your app is weakest. This avoids the two common failure modes: a shallow pass that touches everything and finds nothing, and a deep dive that ignores whole categories.

Every finding is tagged with its Top 10 category and its CWE identifier, scored with CVSS, and paired with reproduction steps and a specific fix. That mapping is what makes the report useful for an auditor or a customer who asked for Top 10 coverage: they can see exactly which categories were tested and what was found in each.

PCI DSS 4.0 requirement 6.2.4 expects developers to address the common software attacks the Top 10 describes, and requirement 11.4 calls for application-layer testing. For ISO 27001 the results support control A.8.29, and SOC 2 auditors accept Top 10-mapped testing as independent evidence under the security criteria.

Where personal data is processed, testing against a recognised standard like the Top 10 is a reasonable way to demonstrate the technical measures GDPR expects, and a mapped report makes that easy to show.

The OWASP ASVS defines three verification levels, and we scope the depth of testing to the one that fits. Level 1 suits lower-risk applications and gives solid baseline assurance. Level 2 is the right target for most applications that handle personal or business data. Level 3 is for the systems where a compromise is genuinely serious, such as payment or health platforms, and it demands the most thorough test cases. Telling us your target level on the scoping call lets us size the engagement correctly.