Web application penetration testing examines the software your customers, staff and partners actually use — your portal, platform, booking system or API — to find weaknesses an attacker could exploit through the application itself. Many UK businesses commissioning a penetration test assume that a standard infrastructure test already covers their web application. It usually does not. An external network test confirms which services are exposed and whether they have known weaknesses; it rarely logs in to your application, explores what each type of user can do, or tries to make the application behave in ways its designers never intended.
That gap matters because many of the most serious breaches of business web applications do not involve exotic network attacks. They involve one customer seeing another customer’s data, a standard user reaching administrative functions, a discount applied that should not be possible, or an API that returns more than the screen ever shows. These flaws live in the application’s logic and access controls, and finding them requires a different methodology, different skills and a properly scoped test.
This guide starts with why network penetration testing and web application penetration testing answer different questions, then covers what OWASP Top 10 testing actually examines, the difference between authenticated and unauthenticated testing, API-specific considerations, and how to scope a web application test so that flaws in your own business logic are found, not just generic vulnerability classes. It is written for business owners, product managers and technical leads commissioning or overseeing testing, and deliberately focuses on what a test covers and how to get value from it rather than on techniques.
What a web application penetration test is
A web application penetration test is a structured, authorised assessment in which experienced testers examine an application the way a determined attacker would, within agreed rules, and report the weaknesses they find with evidence and recommendations. It combines automated tools, which are good at finding common issues quickly, with manual testing, which is essential for understanding how the application works and where its particular weaknesses lie.
Typical areas include how users sign in and how sessions are managed; whether each type of user can only do and see what they should; how the application handles input and output; how it stores and transmits sensitive data; how it is configured; whether its components and libraries have known weaknesses; how its APIs behave; and whether its business processes can be misused. The output is a report that explains each finding, its potential impact on your business, how it was confirmed, and what to do about it.
A quick way to tell whether a proposed test will examine your application properly is to ask: which user roles will the testers log in as, and which parts of the application will they test while logged in? If the answer is “none”, the test will mostly see your login page and public content, and most of your application’s risk will go unexamined.
Why network and web application testing answer different questions
Both types of test are valuable. They simply look at different layers of your exposure, and one does not substitute for the other.
Infrastructure testing
An infrastructure or network penetration test asks: what systems and services can an attacker reach, are any of them running vulnerable or misconfigured software, and could an attacker use them to gain a foothold or move through the network? It looks at servers, firewalls, remote access, exposed services and, for internal tests, the wider network and identity systems. Our guide to internal versus external penetration testing covers these in more detail.
Web application testing
A web application test asks: can someone misuse this application to see data they should not, do things they should not, or take control of it? It examines the application’s own code and behaviour: authentication, authorisation, input handling, session management, business logic and APIs. Most of its findings are invisible to an infrastructure test, because the server hosting the application may be perfectly patched while the application itself lets one user read another’s records.
Different skills, different time
Application testers need to understand how web applications and APIs are built, how frameworks handle security, and how to think through business processes. Testing takes longer per target than an infrastructure scan, because testers need to learn how the application works before they can find where it fails. A two-day infrastructure test of a few external addresses and a two-day test of a complex multi-role application are very different exercises.
When you need both
If your business exposes infrastructure and runs a customer-facing or business-critical application, you generally need both: infrastructure testing for the hosting and network, application testing for the software. They can often be commissioned together from the same provider with appropriately scoped effort for each.
Web application testing in UK businesses — the numbers
The figures below are indicative, drawn from penetration testing engagements and scoping discussions with UK businesses. They are not a formal survey.
The second and third figures point to the same conclusion: the most valuable findings in web application testing usually come from logged-in testing across different user roles. Access control flaws — users reaching data or functions intended for others — are both common and often serious, and they are almost impossible to find without authenticated testing.
What web application tests typically find
The chart shows how often each category of finding appears in the authenticated web application tests we are involved with for UK businesses. Most tests produce findings in several categories, so figures add up to more than 100%.
Misconfiguration findings are common but often lower severity. Access control, authentication and business logic findings are less predictable and more often serious, because they allow misuse of the application’s intended functions. Classic injection flaws appear less often than they once did, as modern frameworks make them harder to introduce, but they remain worth testing for, particularly in older or heavily customised code.
What different tests cost
The table compares indicative costs for common test types for a UK business. Figures are broad ranges in pounds and depend on the size and complexity of the application, the number of roles and APIs, and the provider; they are a guide to proportion rather than a quotation.
| Test type | Typical duration | Indicative cost | What it covers |
|---|---|---|---|
| External infrastructure test | 1 to 3 days | £1,000 to £4,000 | Exposed services, network and hosting weaknesses |
| Web application test, unauthenticated only | 1 to 2 days | £1,000 to £3,000 | Public pages, login and what is reachable without an account |
| Web application test, authenticated with multiple roles | 3 to 10 days | £3,000 to £12,000 | Full application, access control between roles, business logic |
| API test | 2 to 8 days | £2,000 to £10,000 | Endpoints, authorisation per object and function, data exposure |
| Combined application, API and infrastructure | 5 to 15 days | £6,000 to £20,000 or more | Layered view of exposure across hosting and software |
The biggest driver of cost is the effort needed to understand and test the application properly, which depends on the number of features, roles, workflows and API endpoints. An unauthenticated test is cheap but sees little of a typical business application. Our guide to penetration testing costs covers pricing across test types in more detail.
What OWASP Top 10 testing actually examines
The OWASP Top 10, published by the Open Worldwide Application Security Project, is a widely used awareness document listing the most significant categories of web application security risk. It is revised every few years based on industry data, and successive editions have reorganised and renamed categories, so check which edition a provider references. OWASP Top 10 testing means checking an application against these categories, typically alongside more detailed standards such as the OWASP Application Security Verification Standard.
Recent editions have included categories along the following lines, described here at a business level:
- Broken access control. Users able to act outside their intended permissions, such as viewing another customer’s records or reaching administrative functions.
- Cryptographic failures. Sensitive data not adequately protected in transit or at rest, or protected with weak methods.
- Injection. Untrusted input interpreted as commands or code by a database, browser or other component.
- Insecure design. Weaknesses built into how features work, rather than coding mistakes, such as a password reset process that can be abused.
- Security misconfiguration. Unsafe default settings, verbose error messages, unnecessary features enabled or missing security headers.
- Vulnerable and outdated components. Libraries, frameworks and platforms with known weaknesses.
- Identification and authentication failures. Weak login, session or credential handling.
- Software and data integrity failures. Trusting updates, data or code without verifying their integrity, including supply chain risks.
- Security logging and monitoring failures. Attacks or misuse not recorded or detected.
- Server-side request forgery and related issues. The application being manipulated into making requests on an attacker’s behalf.
Two cautions apply. First, the Top 10 is an awareness list, not a complete testing methodology; a good test covers these categories and more, guided by how your application works. Second, a report that simply maps automated scanner output to Top 10 categories is not the same as a manual test of each category in the context of your application. Ask how each category will be tested, not just whether it is listed.
An automated scan labelled as a pen test versus a manual application test
The market includes services that run automated scanners and present the results as a penetration test. Scanners have their place, but the difference in what they find is substantial.
Automated scan labelled as a pen test
Tool output with limited human analysis
Manual web application test
Experienced testers supported by tools
Automated scanning is worthwhile as a regular hygiene check between tests, and good testers use tools extensively. But a test that relies only on tools will consistently miss access control and business logic flaws, which are among the most damaging. When comparing quotes, ask how much of the time is manual testing and what the testers will do beyond running tools.
Scoring three levels of test depth
The score grid compares three levels of web application test depth. A high badge means strong coverage on that dimension, except for the last row, where high means high cost and effort.
An unauthenticated test covers what anyone on the internet can reach, which is important but usually a small part of a business application. A single-role authenticated test adds the logged-in experience for one type of user and can find some access control issues between users of the same type. Testing with multiple roles — for example, two customers, a staff user and an administrator — is what reveals whether each role is genuinely confined to its own data and functions, and it is where most serious findings come from.
Authenticated versus unauthenticated testing
The single most important scoping decision for a web application test is whether, and how, testers will log in.
Unauthenticated testing
Testers approach the application as an anonymous visitor. They examine public pages, the login, registration and password reset processes, and anything else reachable without an account. This reflects the threat from opportunistic attackers and is a necessary part of any test, but for applications where most functionality sits behind a login, it leaves most of the risk untested.
Authenticated testing
Testers are given accounts and test the application as logged-in users. This reflects realistic threats: a malicious customer, a compromised account, a disgruntled employee, or an attacker who has obtained credentials. It allows testers to examine every feature, every workflow and every API call the application makes.
Testing across roles
Access control testing checks two directions. Horizontal checks ask whether one user can reach another user’s data at the same level, such as one customer viewing another’s orders. Vertical checks ask whether a lower-privileged user can reach higher-privileged functions, such as a standard user performing administrative actions. Both require at least two accounts per relevant role, and accounts in each role that matters.
Practical arrangements
Provide test accounts in each role, populated with realistic test data, ideally in a test environment that mirrors production. Agree in advance whether testers may create, modify or delete data, how payment or notification features should be handled, and who to contact if something unexpected happens.
API security testing
Modern web applications are often a thin user interface over one or more APIs, and mobile apps, partner integrations and internal systems may use the same APIs. API security testing deserves explicit attention in scope, because APIs frequently expose more than the interface shows.
Why APIs need specific testing
An interface may hide a field, disable a button or show only a user’s own records, while the underlying API returns extra data or accepts requests the interface never makes. Testing only through the browser can miss these gaps. OWASP publishes a separate API Security Top 10, which highlights risks such as authorisation not checked for each object a user requests, authorisation not checked for each function, excessive data returned in responses, lack of limits on resource use and undocumented or forgotten API versions.
What to provide
Testing is far more effective with API documentation, such as an OpenAPI specification or a collection of example requests, plus credentials for each relevant role. Without documentation, testers must discover endpoints by observing traffic, which takes longer and can miss endpoints the interface does not use.
Include every consumer
If mobile apps, partner integrations or internal tools use the same or related APIs, consider whether they should be in scope. Endpoints that exist for one consumer are reachable by anyone who finds them.
Versions and environments
Older API versions often remain live after newer ones are introduced, sometimes without the security improvements of later versions. Include all live versions in scope, and confirm that test and staging APIs are not exposed to the internet unintentionally.
Single-page applications and modern front ends
Many modern web applications are built as single-page applications, where a JavaScript front end running in the browser calls APIs for data and actions. This architecture shifts where security decisions must be made, and testing needs to reflect that.
In these applications, the front end often decides what to show and which buttons to enable based on the user’s role. That is a usability feature, not a security control: anything enforced only in the browser can be bypassed by calling the API directly. Every security decision — who can see which record, who can perform which action — must be enforced on the server. Testing therefore focuses heavily on the APIs behind the interface, checking that the server enforces the same rules the interface implies.
Single-page applications also bring their own considerations: how authentication tokens are stored and refreshed in the browser, how the application handles content from other sources, which third-party scripts it loads, and whether configuration or secrets have been included in the code delivered to the browser. A good tester examines the front-end code delivered to users for these issues as well as testing the APIs.
When scoping, explain the application’s architecture, including which front ends and APIs exist and how authentication works, so the test covers each layer appropriately.
From scoping to retest: a typical web application engagement
The timeline shows a typical sequence for a web application and API test for a UK business.
The scoping walk-through is where much of the test’s value is decided. Testers who understand the application’s users, data and workflows before they start can focus on the areas most likely to matter. Our guide to what happens during a penetration test covers the engagement process in more detail.
Preparing your team and environment
A little preparation on your side makes the testing days far more productive.
- Stabilise the environment. Avoid deploying major changes to the test environment during testing, so findings relate to a known version and testers are not chasing a moving target.
- Check accounts work beforehand. Log in with each test account, confirm the roles are correct and multi-factor authentication arrangements are workable for testers.
- Populate test data. Create records owned by different users, in different states, so access control and workflows can be tested meaningfully.
- Tell the right people. Let your hosting provider, security monitoring team and support desk know testing is happening, so alerts are understood rather than escalated as incidents, unless detection is deliberately part of the exercise.
- Name a contact. Someone available during testing who can answer questions, reset accounts and receive critical findings.
- Back up test data. Testing may create, change or delete records; make sure the environment can be restored.
- Plan developer time. Reserve capacity after the report for remediation and a debrief, so findings do not wait months for attention.
These steps take a few hours and prevent the most common causes of lost testing time: accounts that do not work, environments that change mid-test and questions nobody is available to answer.
Scoping so business logic flaws get found
Generic vulnerability classes such as misconfiguration or outdated components can be found in almost any application with a standard approach. Business logic flaws are different: they are specific to how your application is meant to work, and testers can only find them if they understand that. Scoping is where that understanding is built.
Explain the business, not just the technology
Walk the testers through who uses the application, what each role is allowed to do, what data is sensitive, and how money, approvals or entitlements flow through it. A tester who knows that managers approve expenses up to a limit, or that a customer’s discount depends on their contract tier, can test whether those rules can be bypassed.
Identify the processes that matter most
List the workflows where misuse would hurt most: payments, refunds, discounts, account changes, approvals, data exports, invitations, password resets, file uploads, integrations with other systems. Ask testers to prioritise these.
Share what worries you
Developers and product owners often have a sense of where the weak spots are: a feature built in a hurry, a legacy module, a complex permissions model, a recent change. Telling testers saves time and focuses effort where it is most likely to pay off.
Provide realistic data and roles
Business logic testing needs realistic scenarios: accounts in different tiers, orders in different states, records owned by different users, approvals at different levels. A test environment populated with a few placeholder records limits what can be tested.
Allow enough time
Understanding an application takes time before testing it deeply. Very short tests on complex applications inevitably focus on generic issues. Be wary of quotes that seem to allocate too little time for the number of roles and features involved.
Consider a grey-box approach
Giving testers documentation, architecture information or limited access to code — often called grey-box testing — makes tests more efficient and thorough than purely black-box testing, where testers start with nothing. Since the aim is to find weaknesses before attackers do, rather than to simulate an outsider’s exact starting point, more information usually means better results.
What businesses provide when scoping
The progress bars show how often each item is provided to testers when UK businesses commission web application tests. Figures are indicative, and the gaps explain why many tests find less than they could.
Information and access provided at scoping
Nearly everyone provides a URL and most provide an account. Far fewer provide the things that let testers find the most serious issues: multiple accounts per role, workflow walk-throughs, API documentation, realistic data and the development team’s own concerns. Providing these costs little and can transform what a test finds.
Where the serious findings come from
Across the authenticated web application tests we are involved with, the share of high and critical severity findings that fall into access control or business logic categories — the categories automated scanning finds least reliably — is striking.
The figure is indicative rather than a formal survey. It explains why scoping matters so much: the most serious weaknesses in business applications tend to be the ones that require logged-in testing across roles and an understanding of how the application is meant to work. Tests that omit authentication, roles or workflow context will tend to report many low and medium issues while missing the ones that could cause real harm.
What a good report contains
The report is the lasting output of a test, and its quality determines how easily findings are understood and fixed. A good web application test report typically includes:
- An executive summary in plain language: overall position, the most significant risks and what they could mean for the business.
- A clear statement of scope: which applications, environments, roles, features and API versions were tested, over what period, and what was excluded.
- Prioritised findings with consistent severity ratings, explaining the likelihood and impact in the context of your application.
- Evidence showing how each finding was confirmed, sufficient for developers to reproduce it in a controlled way.
- Remediation advice that is specific and practical, including where several findings share a root cause.
- Positive observations: controls that worked well, which help the team know what to keep doing.
- Retest results, once fixes have been verified, so the record shows what was found and resolved.
Reports that are mostly pasted scanner output, with generic descriptions and no evidence of manual testing, are a sign the test may not have examined your application in depth. Asking for a sample report before commissioning a test is the easiest way to avoid this.
The 12-point web app pen test scoping checklist
The checklist covers what to settle before commissioning a web application or API test.
- Define what is in scope. Applications, domains, APIs, mobile back ends and environments, including all live API versions.
- Choose the environment. A production-like test environment where possible, or agreed safeguards for production.
- List user roles and permissions. What each role should and should not be able to do.
- Provide at least two accounts per key role. To test access control horizontally and vertically.
- Populate realistic test data. Records owned by different users, in different states and tiers.
- Walk testers through critical workflows. Payments, approvals, refunds, exports, account changes.
- Supply API documentation. Specifications or request collections, plus credentials.
- Share known concerns. Recent changes, legacy modules, complex permissions.
- Agree rules of engagement. Testing windows, data changes allowed, contacts, out-of-scope actions.
- Confirm the effort is realistic. Days allocated in proportion to features, roles and endpoints.
- Agree reporting and critical issue escalation. Format, severity scheme and immediate notification of serious findings.
- Include a retest. To verify fixes after remediation.
Penetration testing must be authorised in writing by someone with the authority to do so, covering every system in scope. Where applications are hosted by third parties or use cloud services, check whether the host’s policies require notification or restrict certain testing. Testing systems you do not own or control, without permission, can breach the law and contracts; a reputable provider will insist on clear written authorisation before starting.
Web application test readiness — where most UK businesses sit
Combining clarity of scope, role and account provision, test data, workflow context, API documentation and remediation capacity gives an indication of how ready a business is to get full value from a web application test. The gauge reflects a typical UK business commissioning its first application test.
A score around forty typically reflects a business that has identified the need for testing and can provide access, but has not prepared the context that makes a test thorough: one account rather than several per role, sparse test data, no API documentation and no walk-through of the processes that matter most. The test will still find issues, but may miss the most serious ones.
A few days of preparation using the checklist above usually lifts readiness into the seventies or eighties, and with it the quality of findings. It also tends to reduce cost, because testers spend less time discovering what could have been explained.
Common web application testing mistakes
The mistakes below account for most of the disappointing web application tests we see.
- Assuming an infrastructure test covers the application. It examines different layers and different risks.
- Testing without logging in. Most business application risk sits behind authentication.
- One account for the whole test. Access control between users and roles cannot be tested properly.
- Accepting an automated scan as a pen test. Scanners miss access control and business logic flaws.
- Leaving APIs out of scope. APIs often expose more than the interface shows.
- Sparse test data. Business logic cannot be tested without realistic scenarios.
- Too little time for the application’s size. Short tests default to generic findings.
- No walk-through of business workflows. Testers cannot test rules they do not know exist.
- Fixing symptoms, not causes. Patching one endpoint when the underlying authorisation pattern is flawed.
- No retest. Fixes go unverified, and new issues introduced by changes go unnoticed.
A penetration test reports what testers found within the agreed scope, time and access. A report with few findings from a short, unauthenticated test says little about the security of the logged-in application. When sharing results with customers, insurers or auditors, describe the scope accurately — which roles, features and APIs were tested — so the report is not taken to mean more than it does.
Case study: the infrastructure test that missed the portal
A UK insurance services firm with around 110 staff ran a customer portal where brokers and policyholders could view policies, upload documents and request changes. Each year it commissioned an external penetration test, which covered its public IP addresses and returned a short list of low-severity findings. The firm’s board, and its own customers’ security questionnaires, took these results as evidence that the portal was secure.
When a large broker partner asked specifically for evidence of application-layer testing, the firm commissioned its first authenticated web application and API test. Scoping included a walk-through of broker, policyholder and staff roles, two accounts in each, API documentation for the portal and its mobile app, and realistic test data across several policies and brokers.
The test found that a broker could, by changing a policy reference in an API request, retrieve documents belonging to policies managed by other brokers; that a policyholder account could call an endpoint intended for staff to change policy details; and that an older API version, still live for an earlier mobile app, returned more personal data than the current version. None of these issues was visible to the infrastructure test, and none had been found by the automated scanning the firm ran monthly.
The development team fixed the issues by introducing a consistent authorisation check applied to every object and function in the API, rather than patching each endpoint individually, and retired the old API version. A retest confirmed the fixes. The firm now commissions annual authenticated application testing alongside its infrastructure test, and describes the scope of each accurately when responding to customer questionnaires.
“We genuinely believed our annual pen test covered the portal. It covered the servers the portal ran on. The application test found the problems that would actually have hurt us, and the way we fixed them made the whole platform stronger.” — Head of IT, UK insurance services firm
The lesson is not that the infrastructure test was poor. It answered the question it was designed for. The firm had simply not asked the question that mattered most for its portal.
Choosing a web application testing provider
Web application testing quality varies widely between providers, and price alone is a poor guide. A few points help distinguish them.
- Application testing experience. Ask about the testers who will work on your application, their experience with similar technologies and the kinds of applications they have tested.
- Recognised accreditation. In the UK, CREST accreditation for testing companies and recognised individual qualifications indicate that processes and skills have been independently assessed. Accreditation is not the only measure of quality, but it provides a baseline. Our comparison of CREST and standard penetration testing covers what accreditation means.
- Methodology. Ask how the test will be structured, which standards guide it and how much is manual. Expect references to OWASP guidance and a clear explanation of how access control and business logic will be tested.
- Sample report. A redacted sample shows how findings are explained, how severity is assessed and how useful remediation advice will be for your developers.
- Scoping engagement. Providers that ask detailed questions about roles, workflows and APIs before quoting are more likely to scope the test properly than those that quote from a URL alone.
- Retest and support. Check whether a retest is included and whether testers will discuss findings with your developers.
Reading the report and fixing root causes
The value of a test is realised in what happens after the report arrives. A few practices make remediation more effective.
Prioritise by business impact. Severity ratings are a starting point, but your own understanding of the data and processes involved matters. A medium-rated finding affecting payment workflows may deserve faster attention than a high-rated finding on a rarely used feature.
Look for patterns. Several access control findings across different endpoints usually point to a single missing pattern, such as authorisation not being checked consistently for each object a user requests. Fixing the pattern, for example through a shared authorisation layer, closes the reported issues and others the testers did not reach.
Involve developers early. A debrief between testers and developers helps the team understand each finding, reproduce it and fix it properly.
Address the hosting layer too. Some findings, such as missing security headers, outdated components or misconfiguration, relate to how the application is deployed and maintained. Our guide to website security hardening covers the ongoing practices that prevent many of these.
Retest and record. Verify fixes through a retest, record what was found and fixed, and feed lessons into development practices so similar issues are less likely in future.
How often to test, and testing during development
Web applications change continuously, and each change can introduce new weaknesses. Annual testing is a common baseline for business-critical applications, with additional testing after significant changes, such as new features handling sensitive data, changes to authentication or permissions, new APIs or major framework upgrades. Customers, contracts or regulators may set their own expectations.
Penetration testing is most effective as part of a wider approach rather than an annual event on its own. Secure coding practices, peer code review, automated security checks in the build pipeline, dependency scanning and regular automated scanning between tests all reduce the number of issues reaching production. Threat modelling during design helps catch insecure design before it is built. Penetration testing then serves as independent verification that these practices are working, and finds the issues they miss.
For teams releasing frequently, consider focused tests of significant new features as they are completed, alongside a periodic full test of the whole application. This keeps testing aligned with how the application actually changes.
At a glance: web application penetration testing
| Topic | Key point | What to do |
|---|---|---|
| Infrastructure vs application testing | Different layers, different questions | Commission both where you run critical applications |
| OWASP Top 10 | Awareness list of major risk categories | Ask how each will be tested in your application |
| Automated scans | Useful hygiene; miss logic and access flaws | Do not accept as a substitute for manual testing |
| Unauthenticated testing | Covers what anyone can reach | Necessary but rarely sufficient |
| Authenticated testing | Covers logged-in functionality | Provide accounts in every relevant role |
| Access control | Most common serious finding | Two or more accounts per role; test horizontally and vertically |
| APIs | Often expose more than the interface | Include all live versions; provide documentation |
| Business logic | Specific to your workflows | Walk testers through critical processes |
| Test data | Enables realistic scenarios | Populate records across users, states and tiers |
| Effort | Proportional to features, roles and endpoints | Be wary of very short tests on complex applications |
| Authorisation | Legal and contractual requirement | Written approval for every system in scope |
| Remediation | Fix patterns, not just instances | Debrief developers; address root causes |
| Retest | Verifies fixes | Include in the engagement |
| Frequency | Annually and after significant change | Combine with secure development practices |
How Cloudswitched approaches web application testing
We scope web application tests around how your application is actually used. Before quoting, we walk through your users, roles, sensitive data, critical workflows and APIs with your team, and agree where testing effort will be focused. We ask for accounts in each relevant role, realistic test data and API documentation, because those are what allow serious access control and business logic flaws to be found.
Our tests combine tools with substantial manual testing guided by OWASP standards and the specifics of your application. We test unauthenticated and authenticated access, access control horizontally and vertically, input handling, configuration, components, APIs and business processes. Serious issues are reported immediately during testing. The report prioritises findings by business impact, explains each clearly with evidence, and gives remediation advice your developers can act on, including where several findings share a common root cause.
We debrief with your developers, support remediation where needed and retest to confirm fixes. Where you also need infrastructure testing, we scope and deliver it alongside, so you have a clear view of exposure across hosting and software. No test can prove an application is free of weaknesses, but a well-scoped test finds the ones that matter most before an attacker does.
Has your application actually been tested?
Talk to us about scoping an authenticated web application and API penetration test around your users, roles and workflows.
Talk to a Penetration Testing SpecialistFrequently Asked Questions
What is web application penetration testing?
An authorised assessment in which experienced testers examine a web application and its APIs for weaknesses an attacker could exploit, combining tools with manual testing, and report findings with evidence and remediation advice.
Does an infrastructure pen test cover my web application?
Usually not in any depth. Infrastructure tests examine exposed services and hosting; web application tests examine the application’s own authentication, access control, input handling, business logic and APIs.
What is OWASP Top 10 testing?
Testing an application against the categories in the OWASP Top 10, a widely used list of significant web application security risks, typically alongside more detailed standards. It is a useful framework, not a complete methodology.
What is the difference between authenticated and unauthenticated testing?
Unauthenticated testing examines what an anonymous visitor can reach. Authenticated testing uses accounts to examine logged-in functionality, which is where most business application risk lies.
Why do testers need more than one account?
To check whether users can reach other users’ data at the same level, and whether lower-privileged roles can reach higher-privileged functions. Both require multiple accounts across roles.
Should APIs be included in a web application test?
Yes. APIs often expose data and functions that the interface hides, and they may be used by mobile apps and partners too. Include all live versions and provide documentation.
What are business logic flaws?
Weaknesses in how an application’s processes work, such as bypassing an approval step or applying a discount that should not be possible. They are specific to each application and found through understanding its workflows.
Is an automated vulnerability scan the same as a pen test?
No. Scans are useful for regular hygiene checks but consistently miss access control and business logic flaws, which manual testing is needed to find.
How long does a web application pen test take?
From one or two days for a small application tested without login, to two weeks or more for complex applications with many roles, features and APIs.
Should we test in production or a test environment?
A production-like test environment with realistic data is usually preferable, reducing risk to live operations. Where testing production is necessary, agree safeguards, timing and data handling in advance.
How often should web applications be tested?
Annually for business-critical applications as a common baseline, plus after significant changes such as new sensitive features, authentication changes or new APIs, alongside secure development practices.
What should we do with the report?
Prioritise findings by business impact, debrief with developers, fix root causes rather than individual instances, and retest to confirm fixes. Describe the test’s scope accurately when sharing results.
Related reading
More guidance for UK businesses from the Cloudswitched blog:
- AI integration architecture: connecting LLMs without a maintenance nightmare
- Cyber Essentials scope: deciding what is in and out of your certification
- Backup encryption: protecting backup data without locking yourself out
- Azure Kubernetes Service vs App Service: choosing the right compute platform
- Private connectivity to Azure and AWS: ExpressRoute and Direct Connect vs VPN
Test the application, not just the server
Cloudswitched delivers web application and API penetration tests scoped around your roles, workflows and data, so the flaws that matter most are found and fixed.
Talk to a Penetration Testing Specialist
Cloudswitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
