Application penetration testing since 2010
We test the whole surface,
including the edge nobody drew.
Every application is a map of trust boundaries — clients, gateways, identity, data. We test all of them, including the edge that never made it onto anyone's diagram.
← drag to follow the path →
Hover or tap any boundary to see what we test there.
Who we are
Engineers who attack software
We are software engineers who specialise in attacking software. That background is why we find the flaws that require understanding a system rather than recognising a pattern — broken authorization, business logic abused exactly as designed, one tenant reaching another tenant’s data.
Web applications, REST APIs, mobile and AI-enabled systems, tested by engineers who build their own platform, CybeRapid, to take the repetitive work out of an engagement so more of our time goes on the parts that need judgement.
Founded in 2010 by Erez Metula, author of Managed Code Rootkits. Application security is the only thing we do.
- Specialists, not generalistsApplication security only — no network audits, no compliance box-ticking as a side business.
- The same people throughoutYou are not handed to a junior after the kick-off call.
- Tools as acceleratorsAutomation and AI take the repetitive work; judgement stays human.
- Retesting includedA finding is not closed until it has been verified as fixed.
Trusted by security teams at
What we test
Six surfaces, one discipline
Each one is a service we run end to end, and each is backed by published test cases rather than a claim.
Web applications
Authenticated, in-depth testing of complex applications — roles, workflows, business logic and the places where they interact.
Read moreAPIs and web services
REST and GraphQL tested as a first-class attack surface, not as an afterthought behind the interface.
Read moreAI and LLM features
Prompt injection, business-logic bypass, and models given far more authority over your systems than they should have.
Read moreMobile applications
iOS and Android, the data they leave on the device, and the backend they talk to.
Read moreCloud applications
Cloud-hosted applications and the identity, storage and network boundaries they depend on.
Read moreSaaS and tenant isolation
Multi-tenant platforms where the security model rests on one customer never reaching another customer's data.
Read moreWe also test IoT and embedded devices — 37 published test cases covering firmware, hardware interfaces and device protocols. See them in the catalogue
The process
How an engagement runs
Six steps from first call to verified fix. You always know where the engagement is, what has been found so far and what happens next — there is no silent period where we disappear and return with a PDF.
Scoping
We learn what the system does.
Testing
Hands-on testing against the catalogue.
Report
Written for whoever has to fix it.
Walkthrough
A session with your developers.
Repair
Your team fixes; we stay available.
Retest
Every finding verified. Included.
Scoping
A remote session in which we go through the application with you: what it does, who its users are, which roles exist and what would hurt most if it went wrong. We agree the scope, the environment and the timeline before anything starts, so you get a fixed plan rather than an open-ended engagement. If a penetration test is not what you need yet, this is where we say so.
Testing
We work through the application as an attacker would, authenticated as each role, following the workflows and the business logic to their edges. Testing is driven by our published catalogue so coverage is deliberate rather than improvised. Anything critical reaches you the same day we find it — you never wait for the report to learn something urgent.
Report
Every finding states what it is, how to reproduce it step by step, what an attacker actually achieves with it in your application, and a concrete remediation. Severity reflects real impact rather than a generic score: an issue that exposes another customer’s data is treated as what it is.
Walkthrough
We sit with the development team and go through the findings one by one — what we did, why it works, and what a correct fix looks like. It is the fastest way to turn a report into fixes, and the point where most questions get answered before anyone writes code.
Repair
Your developers implement the remediations. We remain reachable while that happens: reviewing a proposed fix, confirming an approach, or clarifying a finding costs a message rather than a change request.
Retest
We retest every reported finding against the fixed build and confirm each one is genuinely closed. This is part of the engagement, not an upsell — and it is regularly where a team discovers that a fix addressed the symptom rather than the cause.
The deliverable
A report your developers can act on
Testing is only useful if someone can act on it. Our reports are written for the engineers who have to fix the problem — reproduction steps, real impact, and a concrete remediation.
The findings that need context
Authorization flaws, tenant isolation failures, workflow abuse and chained issues do not look malformed to a tool. Finding them takes someone who understands what your application is supposed to allow before they can say what it should not.
Human-led, accelerated by our own platform
Automation finds the known patterns. People find the flaws that only make sense once you understand what the application is supposed to do — and that is where the serious findings live.
Built to remove the repetitive work
We built CybeRapid to take the mechanical part of an engagement off our testers, so more of their time goes on the parts that need judgement — and so the report you get is deeper for the same number of days.
In their words
What clients say
Every quote comes from a real engagement. These are anonymised because our agreement with those clients requires it — not because there is anything vague about the work.
They found a critical IDOR in our claims portal within the first two days. We had been live for 18 months without anyone catching it.
Their API security assessment covered edge cases we hadn’t thought of — broken object-level authorization, mass assignment, rate limiting gaps. The report read like a masterclass in API security.
We needed SOC 2 compliance fast. AppSec Labs didn’t just run the pentest — they helped us understand which findings were blockers and which could wait, so we passed the audit on our first attempt.
Another way to buy
Available on the Microsoft Azure Marketplace
Our web application penetration testing is listed on the Azure Marketplace, so if your organisation already buys through Azure you can procure a test there and draw it down against your existing Microsoft commitment.
It is simply an additional route. Most clients engage us directly, and scoping, testing and reporting are identical either way — pick whichever is easier for your procurement.
Evidence
We publish the tests themselves
Most firms describe their methodology in a paragraph. Ours is 276 named test cases across 42 category pages — each stating what the test proves, how it is carried out, what has to be in place beforehand and what a positive result looks like. Every identifier is checked against the standard it belongs to before it is published: 981 verified control references across WSTG, ASVS, MASVS, the OWASP LLM Top 10 and CWE.
- 276Named test cases
- 42Category pages
- 981Verified control refs
- 5Standards mapped
- 107Web and API
- 26AI and LLM
- 106Android and iOS
- 37IoT and embedded
Questions
Frequently asked
What exactly is an application penetration test?
A hands-on security assessment where experienced testers attack your application the way a real attacker would — looking for ways to reach data or functionality they should not be able to reach.
What do we actually receive at the end?
A report written for the people who have to fix the problem. Every finding includes what it is, how to reproduce it step by step, the real business impact, and a concrete remediation.
Do you use automated tools or AI?
Both, as accelerators — never as a substitute for a human. We use our own platform, CybeRapid, to take the repetitive work out of an engagement so that more of our testers' time goes on the parts that need judgement.
How long does a test take?
It depends on the size of the application and the number of roles and workflows involved, but a typical engagement runs from a few days to a few weeks. We scope it with you first so you get a fixed timeline.
Do you retest after we fix the issues?
Yes. A finding is not closed until it has been verified as fixed, and retesting is part of the engagement rather than an upsell. It is also the point at which many teams discover a fix was incomplete.
Can you help with compliance requirements?
Yes — our testing and reporting are regularly used to satisfy customer security reviews, regulatory expectations and certification requirements.
Get in touch
Tell us what the system does and what worries you.
We will come back with scoping questions, a clear proposal and a realistic timeline. If a penetration test is not what you need yet, we will say so.
- No obligationScoping costs you a conversation, not a commitment.
- Under NDA as standardHappy to sign yours rather than insist on ours.
- A person, not a queueYou speak to someone who will be on the engagement.