Skip to content
Paul Marinos
Menu

Specialized Testing

Where standard web methodology stops — API and GraphQL authorization at scale, mobile's split client/backend surface, and testing LLM applications.

The web methodology transfers to most targets, but three classes have enough distinct surface to warrant their own approach. This is an orientation to each rather than a full treatment — the placeholder the site structure marks for expansion.

APIs are where authorization testing matters most, because the UI that used to hide broken authorization is gone. The OWASP API Top 10 exists precisely because API risks skew differently from the web list, and the top two are both authorization:

  • Broken object-level authorization (BOLA/IDOR). The dominant API vulnerability. Every endpoint taking an object ID needs testing with another user’s IDs. At API scale this is systematic work — enumerate every parameterised endpoint, substitute identifiers, record.
  • Broken function-level authorization. Admin endpoints reachable by non-admin tokens, often just undocumented rather than protected.
  • Mass assignment. The API binds request fields to the object directly, so adding "role": "admin" to a profile update tests whether it’s blindly accepted.
  • Excessive data exposure. The endpoint returns full objects and trusts the client to display a subset — so the extra fields are right there in the response.

GraphQL adds its own surface. Introspection, if enabled, hands you the entire schema. Nested queries enable denial of service through deep recursion. And authorization is per- resolver, so a field protected on one query path is frequently exposed on another — the single-endpoint model makes coverage harder to reason about than REST.

Mobile testing splits cleanly, and the split is the method:

Client-side — the app on the device:

  • Secrets in the binary: API keys, hardcoded credentials, endpoints. Decompiling is routine.
  • Insecure local storage — sensitive data in plaintext preferences or databases.
  • Certificate pinning — its presence complicates interception; its absence is a finding.
  • Platform misuse — exported components, insecure deep links, leaky IPC.

Backend — the API behind it, which is the higher-value half. A mobile app is a client to an API, and that API has every issue above. The frequent failure is trust placed in the client: validation done only in the app, “hidden” endpoints assumed private, integrity checks the server never re-verifies. Anything the client enforces, the backend must enforce again, because the client is fully under the tester’s control.

The fast-moving surface, and a genuinely new class rather than a rename of an old one. The securing-AI material covers the defensive side; the offensive view:

  • Prompt injection — the signature vulnerability. Direct injection overrides the system prompt; indirect injection hides instructions in content the model later ingests — a document, a web page, a retrieved record — and is the harder, more dangerous variant because the payload arrives through data, not the user.
  • Tool and function abuse. An LLM wired to tools is an execution surface. If it can call functions, injection can call them too — so the real question is what the model is authorized to do, which is a blast-radius question, not a prompt one.
  • Data exfiltration through the model — coaxing out training data, system prompts, or other users’ context.
  • RAG-specific paths — poisoning the knowledge base, or retrieving across a tenant boundary the retrieval layer failed to enforce.

The framing that matters: an LLM with tools is a confused-deputy problem with a natural- language interface. Test what it can be made to do, not just what it can be made to say — the second is embarrassing, the first is exploitable.

All three extend web methodology, and every finding maps to an AppSec control — the API Top 10, mobile platform guidance, or LLM defenses. The AI material connects directly to securing AI systems, where the same issues are addressed from the defender’s side.

Graph View