Manual, specification-driven security testing for APIs. Focused on business logic, authentication, and the flaws that automated tools are structurally unable to see.
Automated security scanners test for known patterns: SQL injection signatures, missing headers, exposed credentials. They're useful for baseline hygiene. They're useless for business logic.
Can a user access another user's data by changing an ID parameter? Can a payment be submitted twice under concurrent requests? Can a privilege be escalated by replaying a modified JWT? These are logic questions, not signature questions. No tool can answer them without understanding what the system is supposed to do.
That understanding is what Testclub brings. We read the specification (or discover its absence), map the logic flows, and test the boundaries that matter.
# BOLA: accessing another user's account data GET /api/v2/accounts/1045 Authorization: Bearer eyJhbG...user_1044 200 OK { "account_id": 1045, "balance": "£142,800.00" } # User 1044's token returns user 1045's data. # No scanner tests for this. It requires understanding # that the token and the resource should match.
We test against the OWASP API Security Top 10 as a starting framework, then go further into the logic specific to your system. Every engagement is different because every system's business rules are different.
Broken Object Level Authorization (BOLA). Broken authentication. Mass assignment. Server-side request forgery. Race conditions in payment and state-change flows. Privilege escalation through chained requests. JWT implementation flaws. GraphQL introspection and query abuse.
We use Burp Suite Pro as our primary tool, extended with custom scripts and manual testing against real attack scenarios. The output is a report with full reproduction steps, business impact assessment, and remediation guidance.
# Same request after remediation GET /api/v2/accounts/1045 Authorization: Bearer eyJhbG...user_1044 403 Forbidden { "error": "insufficient_permissions" }
Security and performance testing overlap more than most teams realise. A rate limit that can be bypassed is both a performance risk and a security vulnerability. An endpoint that degrades under load may be vulnerable to denial-of-service through normal-looking requests.
We use K6 for load testing, integrated into the same engagement where appropriate. Understanding how a system behaves under pressure reveals assumptions that were never tested.
Secure APIs are reliable APIs. Let’s make yours both.