Manual penetration testing
Hands-on security testing for web applications, APIs, mobile apps, SaaS platforms, cloud environments and AI systems. Built for engineering teams who need findings they can act on, not a scanner export.
Coverage
Six testing surfaces, each scoped and tested on its own terms. Where systems connect, we test the joins as well as the parts.
Authenticated, role-aware testing of application logic: broken access control, privilege escalation between roles, injection, server-side request forgery and the business-logic flaws a scanner cannot reason about.
REST, GraphQL and gRPC surfaces tested against their own contract. Object and function level authorisation, mass assignment, rate-limit bypass, token handling and the undocumented endpoints that ship by accident.
iOS and Android builds examined on device and in transit: local data storage, keychain and keystore use, certificate pinning, tamper resistance, and the backend the app talks to.
Multi-tenant isolation as the first-class concern: cross-tenant data access, tenant-scoped identifiers, role and permission models, subscription and entitlement logic, and administrative separation.
AWS, Azure and GCP estates reviewed for identity and trust-boundary failures: over-broad IAM policies, assumable roles, exposed storage and metadata services, network segmentation and key management.
LLM-backed features treated as an attack surface in their own right: prompt injection through untrusted content, tool and function-call abuse, over-permissive retrieval scope, output handling and training-data exposure.
Approach
Automated tooling finds what it recognises. Chained access-control failures, broken tenant isolation and abusable business logic take a person who understands what your system is for.
Targets, test accounts, environments and rules of engagement are agreed in writing before any traffic is sent. You know what will be touched and when.
Hands-on testing by an engineer who reads your application, not a scan with a report generator attached. Tooling assists; it does not decide.
Every finding arrives with reproduction steps, evidence, an impact assessment and a remediation path written for the engineer who has to fix it.
Once fixes ship, the affected findings are retested and the report is reissued to reflect the current state of the system.
Deliverables
A report is only useful if someone can fix things from it. Every finding is written to be reproduced, understood and closed.
Every finding with reproduction steps, request and response evidence, affected components and a concrete remediation recommendation.
A short, non-technical account of what was tested, what was found and what it means, written for readers who will not open the technical section.
Standardised severity scores alongside a plain description of real-world impact in your environment, so prioritisation is not left to a number alone.
Specific, code-level direction rather than a link to a generic advisory. Where a fix has architectural implications, the report says that too.
Verification of the fixes you ship, and an updated report reflecting the remediated state of the system.
A working call with your engineers and stakeholders to walk the findings, answer questions and agree the fix order.