Web application penetration testing that finds what scanners miss.
Automated scanning tells you an application has a header missing. Manual, authenticated testing tells you a standard user can pull another customer's invoices. We do the second one.
Most application risk lives below the checklist.
Every automated scanner can tell you whether a security header is missing or whether a library version has a known CVE. Very few can tell you whether your role-based access control actually stops a standard user reaching an admin endpoint, or whether your checkout process can be manipulated to apply the wrong discount. That gap between what a scanner reports and what an attacker actually exploits is where most real-world application compromises happen.
Bespoke applications are particularly exposed because every business logic decision — pricing rules, approval workflows, multi-tenant data boundaries, file upload restrictions — is unique to that codebase. There's no signature database for 'this specific application lets a user edit someone else's order by changing a number in the URL'. Finding that requires a tester who understands the workflow and deliberately tries to break it, not a tool matching known patterns.
Authentication and session handling are recurring weak points too. Password reset tokens that don't expire, JWTs that remain valid after logout, multi-factor authentication that can be bypassed by hitting an older endpoint directly, and session fixation across subdomains all show up regularly in applications that otherwise look well built. These issues rarely appear in a passive scan because they only reveal themselves when someone actively manipulates the session lifecycle.
APIs compound the problem. Most applications now expose a REST or GraphQL API that does more than the visible front end — internal tooling, mobile app support, partner integrations — and that surface is frequently tested less rigorously than the web pages a QA team clicks through. Object-level authorisation failures, where one user's ID can be substituted for another's in an API call, are among the most common critical findings we report.
Underneath all of this sits a governance question: who is accountable if a customer's data is exposed through a logic flaw rather than a textbook vulnerability? Increasingly, clients, insurers and regulators expect evidence that an application has been tested by someone who actually exercised its authenticated functionality, not just that a report exists.
- Broken access control between customer accounts or organisations
- Business logic that can be manipulated to bypass pricing, limits or approvals
- Session and token handling that survives logout or password changes
- API endpoints tested less thoroughly than the visible web interface
We log in, and then we try to break what the login is meant to protect.
We start by mapping the application properly — every role, every workflow, every API endpoint the front end calls, and every place user-supplied data reaches the server. This map becomes the test plan, so effort is directed at the parts of the application that carry genuine risk rather than spread evenly across pages that don't matter.
Testing is authenticated by design. We work with credentials for each role in scope and deliberately test the boundaries between them: can a standard user reach an admin function by guessing a URL, can one tenant's data be reached from another tenant's session, does removing a parameter or changing an ID expose a record that shouldn't be visible. This is where most of the serious findings come from.
OWASP Top 10 categories — injection, broken access control, cryptographic failures, security misconfiguration and the rest — are all covered systematically, but treated as a floor rather than a ceiling. We spend proportionally more time on business logic abuse: workflow bypass, race conditions in payment or approval processes, and file upload handling, because these are the issues that generic tooling structurally cannot find.
The API is tested directly, not just observed through the front end. We replay authenticated requests with modified identifiers, test rate limiting and input validation independently of whatever the UI enforces, and check that authorisation decisions are made server-side rather than assumed from what the interface displays.
Every finding is written up with a reproducible proof of concept, a realistic assessment of business impact, and remediation guidance pitched at the developer who will actually fix it. We're available during the fix window to answer questions, and every critical and high finding is retested free of charge once addressed.
- Role-by-role access control testing, not a single generic account
- API tested directly with authenticated requests, independent of the UI
- Business logic and workflow abuse prioritised over checklist coverage
- Free retest of every critical and high finding once fixed
Everything in the engagement, set out up front.
A fixed-scope engagement built around your application's actual roles and workflows.
Application and role mapping
A structured review of every role, workflow and endpoint in scope before testing starts, agreed with your team.
Authenticated multi-role testing
Direct testing of access control boundaries between anonymous, standard and administrative accounts.
OWASP Top 10 coverage
Systematic testing against injection, broken access control, misconfiguration and the other established risk categories.
API and session testing
Independent testing of REST or GraphQL endpoints and of session and token handling across login, logout and password change.
Business logic assessment
Deliberate attempts to manipulate pricing, approval workflows, file handling and multi-tenant data boundaries.
Developer remediation support
Direct access to the tester during the fix window and a free retest of every critical and high finding.
What you receive.
- Executive summary suitable for boards and auditors
- Risk-rated findings with realistic business impact
- Step-by-step reproduction steps with evidence
- Annotated request and response data for API findings
- Remediation guidance written for engineers, not managers
- Role and access control matrix showing what was tested
- Free retest report for critical and high findings
- Optional developer debrief call to walk through fixes
Built for organisations that need the work done properly.
SaaS and product teams
Businesses shipping a customer-facing web application who need independent assurance before a release, audit or client due diligence request.
Multi-tenant platforms
Applications where one customer's data must never be reachable from another's session, and where that boundary has never been independently tested.
Organisations replacing legacy systems
Teams migrating from an older platform who want the new build tested properly before it takes over live traffic.
Regulated and client-facing services
Firms in finance, legal, healthcare or the public sector needing evidence of application testing for contracts, insurance or compliance.
What changes once the work is done.
What changes once testing and remediation are complete.
Access control verified, not assumed
Confirmation that role boundaries and multi-tenant separation hold up under active testing, not just code review.
Business logic flaws closed
Workflow and pricing manipulation paths identified and fixed before a customer or competitor finds them first.
API surface properly tested
Confidence that endpoints supporting mobile apps, integrations and internal tooling meet the same bar as the web front end.
A report developers can act on
Findings written with enough technical detail to fix directly, reducing back-and-forth during remediation.
Evidence for clients and auditors
A clear, dated report demonstrating independent testing for procurement, insurance or compliance requirements.
A retested, verified fix
Free retesting confirms remediation actually closed the issue rather than just changed its symptoms.
Why authenticated testing matters more than an external scan.
An unauthenticated scan of your application's login page tells you almost nothing about the risk that matters once a real user, or an attacker with stolen credentials, is inside. The overwhelming majority of serious application compromises we see in the field involve a legitimate session being abused, not a login being bypassed. That's why authenticated, role-based testing sits at the centre of every engagement we run, rather than being an optional add-on.
It's also why we push back on scopes that only cover the anonymous, pre-login parts of an application. A test that never logs in can confirm your marketing pages are reasonably configured, but it cannot tell you whether a standard user can escalate to admin, or whether your API leaks another customer's records when an ID is changed. Those are the findings that end up in breach notifications, not the missing security header.
We work with development teams across Chesterfield, Sheffield, Derby, Nottingham, Leeds, Manchester, Birmingham and London, and the pattern holds regardless of stack or framework: applications built quickly under commercial pressure tend to get authentication and basic input validation right, and get authorisation and business logic wrong, because those decisions are scattered across the codebase rather than handled in one place.
None of this requires an adversarial relationship with your development team. We report findings the way we'd want them reported if we were the ones fixing them — reproducible, prioritised honestly, and free of jargon that obscures rather than clarifies. Most engagements end with a short debrief call rather than a report thrown over the wall.
Questions we are asked most often.
Do you test against the OWASP Top 10?
Yes, but the OWASP Top 10 is our starting checklist rather than the whole engagement. Injection, broken access control, authentication weaknesses and misconfiguration are all covered, but the majority of serious findings in bespoke applications come from business logic and role-handling issues that a checklist alone won't surface.
Can you test multiple user roles in one engagement?
Yes, this is standard practice. Most applications have at least an anonymous, standard user and administrator role, and we test transitions between them directly — checking whether a standard user can reach admin functionality, whether one customer can view another's data, and whether role checks are enforced server-side rather than just hidden in the interface.
Do you test our API as well as the web front end?
Yes. Modern applications are typically a thin front end sitting on top of a REST or GraphQL API, and the API itself is usually where the real access control decisions are made. We test the API directly using the same authenticated sessions as the front end, including endpoints the UI doesn't expose but that still exist and respond.
What do you need from us before testing starts?
Test accounts for each role in scope, a brief walkthrough of the application's core workflows, and confirmation of any areas that are out of bounds — for example a live payment gateway or a third-party integration you'd rather we didn't touch. A short scoping call covers all of this in under an hour.
Will testing affect our production environment?
We strongly prefer testing against a staging or pre-production environment that mirrors production configuration, particularly for anything involving data manipulation or business logic abuse. Where production testing is unavoidable, we agree rate limits and out-of-hours windows in advance and flag any action with a realistic chance of disruption before we run it.
How do you report session and authentication issues?
Each finding includes the specific request and response demonstrating the weakness — token reuse after logout, missing session invalidation, predictable password reset tokens, or missing multi-factor enforcement — along with a reproducible proof of concept and remediation guidance your developers can act on without needing it re-explained.
Do you offer a free retest?
Yes, retesting of every critical and high finding is included in the fixed price, provided it's booked within a reasonable window of the original report. We re-run the specific proof of concept rather than the whole test, so retests are quick and don't disrupt a development sprint.
How long does a typical web application test take?
A single application with two or three roles and a moderate number of workflows usually takes five to eight days of testing, plus reporting. Larger applications, multiple integrated services, or a wider set of roles extend that. We scope on functionality and role complexity rather than a flat day-rate guess.
Penetration testing
Our full range of testing services across web, API, infrastructure and cloud environments.
Vulnerability management as a service
Ongoing scanning and patch tracking to keep the estate around your application in a known state.
Managed security
Continuous monitoring and response support for organisations that want more than a point-in-time test.
Ready to test your application properly?
Tell us about your application's roles and workflows on a short scoping call, and we'll come back with a fixed price and realistic timeline — no pressure, no hard sell.
Scope a web application test