Find the flaws in your web app and APIs before someone else does.
Independent, manual testing of web applications and APIs, following an OWASP-aligned methodology and delivered by an experienced tester, not an automated scan with a logo on it.
Most real breaches don't come from a missing patch. They come from a login that can be bypassed, a URL that hands one customer another customer's data, or a checkout that can be talked into charging nothing.
Those are logic and authorisation problems, and automated tools do not understand them. Our web application testing pairs industry-standard tooling with hands-on manual testing, so you get a prioritised list of what an attacker could actually achieve, not a raw export of theoretical issues.
The whole engagement is run to be low-friction: a real tester from the first reply, clear scope and dates, and a report your developers can act on straight away.
Guided by the OWASP Top 10 and the OWASP Web Security Testing Guide, so the coverage is thorough and consistent.
Whether one user can reach another's data or actions by changing an identifier, escalate their privileges, or step outside the boundaries their role should enforce. The most common serious finding, and the one scanners miss most.
Places where input crosses into a query, command or template and changes its meaning, from classic SQL injection through to server-side template injection, with careful, non-destructive validation.
Login, multi-factor, password reset, and how sessions and tokens are issued, stored and revoked. Weaknesses here undermine everything else, so they are tested closely.
Reflected, stored and DOM-based cross-site scripting, and cross-site request forgery, tested in the context of how your application actually handles and renders user input.
Server-side request forgery, insecure file upload, exposed components and headers, and the configuration mistakes that quietly widen your attack surface.
The abuse cases unique to your application: workflows completed out of order, limits that can be bypassed, pricing or quantity that can be manipulated. This is judgement work a tool cannot do.
Your API is often a bigger attack surface than the interface in front of it, and it is where authorisation goes wrong most often.
We test REST and GraphQL APIs against the OWASP API Security Top 10, whether they sit behind a web or mobile front end or stand on their own. API testing can form part of a web application engagement, or be scoped on its own.
Broken object-level authorisation (BOLA) and function-level checks: whether changing an ID or calling a hidden endpoint lets a caller read or do something that isn't theirs.
How API keys, bearer tokens and OAuth flows are issued, validated and revoked, and whether they can be replayed, forged or leaked.
Endpoints that return more than the client needs and rely on the front end to hide it, handing everything to anyone who reads the raw response.
Missing rate limits and resource controls that allow scraping, brute force, or a single caller to degrade the service for everyone else.
A short enquiry, answered by a tester rather than a sales team.
15 to 30 minutes on your app, its roles, and any APIs, so the scope fits what you actually need.
Clear scope, clear price, clear dates, typically within 48 hours.
Agreed rules of engagement, testing to an OWASP-aligned methodology, then a report you can act on.
Once you have fixed the findings, we confirm the fixes hold at no extra cost.
Weak API authentication can allow attackers to bypass login controls, MFA and session protections. Manual testing helps uncover these hidden weaknesses.
Authentication testing examines login, MFA, password recovery, APIs and session handling to identify practical routes attackers could use to compromise user accounts.
Small configuration mistakes can expose sensitive data, administrative functions and wider application infrastructure.
MFA is highly effective, but weak workflows, recovery routes, APIs or session handling can create ways around it.
SSRF can trick a web application into accessing internal systems, cloud services and sensitive resources on an attacker’s behalf.
File uploads are a common but often overlooked web application attack surface. This article explains how insecure upload handling can lead to data exposure, malware distribution, denial of service and potentially code execution.
ISO 27001 does not mandate an annual penetration test, but it is risk-based, and testing is often the clearest way to show that technical vulnerabilities are being found, understood and managed.
We provide independent testing that supports an ISO 27001 programme, scoped to your risks rather than a generic checklist, with a report that feeds straight into your risk register and remediation plan.
Does ISO 27001 require penetration testing?Independent testing provides evidence that these controls work in practice, not just on paper.
We test the things that actually get applications breached: broken access control and insecure direct object references, injection flaws such as SQL injection, authentication and session management weaknesses, cross-site scripting, server-side request forgery, insecure file upload, security misconfiguration, and business-logic flaws a scanner cannot understand. The work is guided by the OWASP Top 10 and the OWASP Web Security Testing Guide, so nothing important is skipped.
Yes. Web application testing follows an OWASP-aligned methodology, built around the OWASP Web Security Testing Guide and the OWASP Top 10, and API testing follows the OWASP API Security Top 10. Automated tooling is used for breadth, but the findings that matter come from manual testing by an experienced tester.
Yes, and this is where the most serious issues usually live. We test as different user roles to find broken access control, horizontal and vertical privilege escalation, and data that one user can reach when they should not. Give us a set of test accounts covering each role and we will exercise the boundaries between them.
Yes. REST and GraphQL APIs are tested against the OWASP API Security Top 10, covering broken object-level authorisation, broken authentication, excessive data exposure, and rate-limiting and resource issues. API testing can form part of the same engagement as the web application it supports, or stand on its own.
We agree the rules of engagement in writing before any testing begins. Where possible we test a staging environment that mirrors production; where production must be used, we schedule around your quiet periods, avoid genuinely destructive actions, and stay in contact throughout so there are no surprises.
A clear report written to be read by both your board and your developers: an executive summary, then each finding with a risk rating, the evidence, step-by-step reproduction, and specific remediation advice. We talk you through it if that helps, and once you have fixed the issues we retest to confirm the fixes hold, at no extra cost.
A scanner is fast and good at breadth, catching known issues and missing patches. It cannot tell you whether a flaw is genuinely exploitable, chain several small issues into a real breach, or reason about your application's business logic and authorisation model. A penetration test combines the tooling with a skilled tester doing exactly that, and validates findings so you are not chasing false positives.
There is no fixed public price, because it depends on scope: the size of the application, how many user roles and authenticated areas are involved, and whether APIs are in play. Tell us about your application on a short scoping call and we will come back with a fixed-price quote, typically within 48 hours.
Tell us about your application and any APIs, and we'll recommend an appropriate scope and provide a no-obligation quotation.
A real tester, not a sales team, so the first reply is already useful.
15 to 30 minutes to understand your application and what you need to prove.
Clear scope, clear price, clear dates, typically within 48 hours.
Not sure whether you need the web application, the API, or both tested? Tell us what you're trying to achieve and we'll help you scope it.
