Skip to content
Book a call

Home / Attacks & tests

The full list, open to read

Attacks & Tests

This is the catalogue of security tests we run: what is tested, what each test is trying to prove, and how it is carried out. It is written as a reference — a reader should be able to scan it and answer “is this covered?” without asking us.

Each test case states its objective, the method, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture. Where a test maps to a published control — OWASP WSTG, ASVS, MASVS, the OWASP Top 10 for LLM Applications, or CWE — the identifier is quoted; where it does not, coverage is described in words rather than given an approximate reference.

The coverage matrix sets out which standards, platforms and depth of testing this methodology spans, and what is deliberately out of scope.

  • 5Platforms
  • 46Test categories
  • 276Named test cases
  • 5Standards referenced
Coverage matrixWhich published standards this maps onto, how much of it is done by hand, and what is deliberately out of scopeEvery category with its case count, the controls its cases cite and the balance of manual and automated work — 981 verified control references across five published standards. Each identifier is checked against the list it belongs to before it is published; where a test has no defensible mapping, none is given.Open the coverage matrix →

How to read a test case

Every entry in this knowledge base uses the same six fields, so two categories can be compared directly.

  • Objective — what the test proves, stated as a question about the application rather than as a vulnerability name.
  • How it is tested — the method. This is the substance: what is enumerated, what is submitted, and what is compared.
  • Prerequisites — what has to exist before the test can run: accounts, roles, tooling, environments. This is the part worth reading before an engagement is scheduled.
  • Indicators — what a positive result looks like, so the finding can be distinguished from expected behaviour.
  • Coverage — the published control the test maps to.
  • Depth — whether the work is manual, automated or hybrid. Where a scanner does the work, it says so.

Depth is stated honestly rather than flatteringly. Claiming manual craft for a check a scanner performs would devalue the claim in the cases where it is true.

Web Applications

The OWASP-derived core of a web application test, plus the categories added to cover ground the OWASP set does not reach on its own. 13 categories, 107 test cases.

AI and LLM Systems

Applications built on a language model — chat assistants, retrieval pipelines and tool-using agents. The model is one component; what is tested is the application around it, where instructions, retrieved data and tool calls meet. 5 categories, 26 test cases.

Android

Client-side testing on the device itself — what the app stores, what it exposes to other apps, and what it trusts. 10 categories, 53 test cases.

iOS

The same client-side ground on Apple's platform, where the sandbox, the keychain and the pasteboard behave differently enough to need their own checks. 11 categories, 53 test cases.

IoT and Embedded Devices

Where the attack surface is the hardware as much as the software — firmware, debug interfaces, and the radio. 7 categories, 37 test cases.

What we do not cover here

This catalogue describes application and device security testing. It does not cover physical intrusion, social engineering of named individuals, or denial-of-service testing against production systems — the last is run only against an environment agreed for it in advance.

Nor is it a compliance audit. A test case that maps to an ASVS requirement demonstrates whether the application satisfies that requirement in practice; it is not a certification against the standard, and this page does not claim one.

Where a category is tested on more than one platform, the technique differs even when the name does not. Those differences are described on the category page rather than flattened into a single description here.

Where these tests are used

Each engagement draws on the part of this catalogue that applies to it. How much access the testers are given is a separate question, set out in testing modes.

Further reading: our published research is at AppSec Labs research.

Tell us what the system does and what worries you.

If a penetration test is not what you need yet, we will say so.

Book a scoping callSee the test catalogue