Web Application Penetration Testing

Know How Your Web Applications Hold Up

A web application penetration test checks how your customer portal, booking system or online platform stands up to a skilled attacker. Pulsar IT scopes and coordinates the test, qualified specialists carry it out under written authorisation, and we help you act on the findings.

What is Web Application Penetration Testing?

A web application penetration test is an authorised, simulated attack on an application your business runs over the web: a customer portal, an online booking or ordering system, a client login area, an internal web app, or the APIs (application programming interfaces) behind a mobile app. The tester looks for ways someone could reach data or functions they shouldn't, and shows how it could be done.

It looks at something different from a network test. External and internal network tests examine the systems, ports and services on your network. A web application test looks inside the application itself: how people log in, what each type of user is allowed to do, how the application handles what users type in, and whether its business rules can be bent.

Pulsar IT scopes the work with you, arranges written authorisation and coordinates the test. The testing itself is delivered by qualified specialist testers, subject to specialist availability and approval, under a written scope and rules of engagement. When the report arrives, we help you understand it and plan the fixes.

Key benefits

  • Weaknesses in logins, permissions and data handling that scanners miss
  • Testing carried out only under written authorisation and an agreed scope
  • Findings ranked by risk, with recommendations your developers can act on
  • Help from Pulsar IT to plan and coordinate remediation
  • Optional retest to confirm fixes have worked

How does it work?

Every test follows the same controlled path: agree what will be tested and how, get written permission, test within those limits, then report and fix. No testing starts until the scope and rules of engagement are signed off.

  1. Scope and authorise

    We agree which applications, web addresses, APIs and user roles are in scope, whether testing runs against a test environment or production, and what is excluded. The application owner gives written authorisation, as does the hosting provider where its terms require it.

  2. Agree the rules of engagement

    Testing windows, contacts on both sides, how to pause testing if something unexpected happens, how any sensitive data seen during testing is handled, and how test-account credentials are supplied securely during the engagement (not through our website forms).

  3. Specialist testing

    Qualified specialist testers examine the application within the agreed scope, combining automated tools with manual testing of sign-in, access control, input handling and business logic.

  4. Report, fix and retest

    You receive a report with findings ranked by risk and recommended fixes. We go through it with you, help plan remediation with your developers or software supplier, and can arrange an optional retest of fixed issues.

  1. Scope and authorisationApplications, APIs, user roles and environments agreed in writing
  2. Rules of engagementWindows, contacts, test accounts and safeguards
  3. Specialist testingQualified testers work only within the agreed scope
  4. Report and remediationRisk-ranked findings, fixes planned, optional retest
How a web application test runs. The test starts with an agreed scope and written authorisation, follows rules of engagement during specialist testing, and ends with a risk-ranked report, remediation support and an optional retest.
Specialist testerWorking under written authorisation
  • AllowedIn-scope applications and APIsTested within the agreed windows and environment
  • AllowedTest accounts for each user roleSupplied securely during the engagement and removed afterwards
  • BlockedOut-of-scope systemsOther sites and third-party services not covered by the authorisation
  • BlockedDenial-of-service and load testingNot carried out unless explicitly agreed in writing
What the testers may and may not do. Testers work only on the applications and APIs named in the written scope, using test accounts supplied securely for each role. Systems outside the scope, including third-party services, are not tested, and disruptive testing such as denial of service is not carried out unless explicitly agreed.

What is tested

  • Authentication: sign-in, password reset, multifactor authentication (MFA) and account lockout
  • Session management: how sign-in sessions are created, protected, timed out and ended
  • Access control between user roles, for example whether a customer can reach another customer's data or an administrator function
  • Input handling, including injection flaws (such as SQL injection) and cross-site scripting (XSS)
  • Business logic, such as skipping or repeating steps in a checkout, booking or approval process
  • APIs that the application or a mobile app relies on, where they are in scope
  • File upload and download handling, where the application has these features
  • Security-related configuration visible through the application, such as error messages and security headers
  • Sensitive data exposed in responses, web addresses or error messages

Typical applications in scope

Customer portals

Clients log in to see invoices, documents or case updates. The key question is whether one client can ever reach another client's information.

Online booking and ordering

Prices, discounts and stock rules live in the application's logic. Testers check whether steps can be skipped or values altered.

Internal web apps

Staff tools such as HR, job-management or stock systems often hold sensitive data and have several permission levels to test.

APIs behind a mobile app

Mobile apps usually talk to an API on the internet. Testing the API checks what an attacker could reach without using the app at all.

Vulnerability scanning vs penetration testing

The two are often confused, but they answer different questions. A scan asks "which known weaknesses can a tool detect?" A penetration test asks "what could a skilled attacker actually do with this application?"

Both are useful. Many businesses scan regularly and commission a penetration test before a major launch, after significant changes, or when a customer or contract asks for one.

Web vulnerability scanning

An automated tool crawls the application and checks it against known issues and common misconfigurations. It is quick and repeatable, but it can report false positives and cannot understand your business rules or who should see what.

Web application penetration testing

A qualified tester uses tools plus manual techniques, signs in as different user roles, and tries to combine small weaknesses into real attacks. Findings are confirmed and explained in terms of business risk.

Risk prioritisation

Each finding in the report is ranked by risk, taking into account how easy it is to exploit and what it would expose, so you know what to fix first rather than working through a long, unranked list.

A test only covers what is in the agreed scope, during the agreed time. Anything outside the scope, such as third-party services your application relies on, is not tested unless their owner gives written permission.

Problems solved

Not knowing whether customers can see each other's data

Access-control flaws rarely show up in normal use. Testing each user role checks that people reach only what they should.

A customer, partner or tender asks for evidence of testing

A scoped test with a written report, and a record of what you fixed, gives you something concrete to show.

Scanner reports full of noise

Automated scans can list many low-value or false findings. A tester confirms what is real and explains the risk in business terms.

A new application or major release going live

Testing before launch, or after significant changes, finds problems while they are easier and cheaper to fix.

No clear plan after a test

Reports can be hard to act on. We turn findings into a prioritised remediation plan with your developers or software supplier.

What's included

Included as standard

  • Scoping call and written scope covering applications, APIs, user roles and environments
  • Arranging written authorisation from the application owner, and the hosting provider where its terms require it
  • Agreed rules of engagement, testing windows and points of contact
  • Coordination of testing by qualified specialist testers within the agreed scope
  • Report with findings prioritised by risk and remediation recommendations
  • Walk-through of the findings with your team

Optional or scoped

Available on request and confirmed in your proposal; not part of the standard service.

  • Retest of fixed issues to confirm remediation
  • Remediation of hosting, server or configuration issues by Pulsar IT, scoped separately
  • Testing of additional applications, APIs or user roles
  • Out-of-hours testing windows, where agreed

What's not included

  • Changes to your application's code, which remain with your developers or software supplier
  • Testing of systems you do not own or are not authorised to test, including third-party services, unless their owner gives written permission
  • Network penetration testing, covered by our external and internal testing services
  • Denial-of-service or load testing, unless explicitly agreed in the rules of engagement

A penetration test is a snapshot of the application at the time of testing, within the agreed scope and time. It reduces risk but cannot find every possible weakness, and new code or configuration changes can introduce new issues.

Testing is delivered by qualified specialists, subject to specialist availability and approval. Timescales and tester details are confirmed in writing during scoping.

Testing a live application carries some risk of disruption or test records appearing in live systems. A test environment that closely mirrors production is often preferred, and any safeguards are agreed in the rules of engagement.

Who it's suitable for

  • Businesses with a customer portal, client login area or online ordering system
  • Organisations launching a new web application or a major update
  • Companies asked by customers, partners or tenders for evidence of application testing
  • Businesses that commission software from an external developer and want an independent check
  • Organisations with APIs that support mobile apps or integrations

Pricing

This service is tailored to your business, so we confirm the price after a short conversation about your requirements. There is no charge for the conversation.

Use the quote builder to add Web Application Penetration Testing to an indicative quote, or book a free security review and we'll recommend what fits.

Price

Price Based on Scope

Price to be confirmed following a review of your requirements.

What affects the price

  • Number of applications and APIs in scope
  • Number of user roles to test
  • Size and complexity of the application
  • Test environment or live (production) testing
  • Whether a retest is required
  • Specialist availability

All prices exclude VAT.

Add to Your Quote

Frequently asked questions

Our developer already runs a security scanner. Do we still need a test?

Scanners are good at spotting known issues and missing settings, and are worth running regularly. They can't reliably tell whether a signed-in customer can reach another customer's records or whether a business rule can be bypassed. A penetration test adds manual testing by a skilled person to look for those problems.

Should you test our live site or a test environment?

A test (staging) environment that closely matches production is usually safer, because testing can create records, send emails or trigger alerts. Some issues only show up in production, such as hosting configuration. We agree the approach, and any safeguards, in the scope.

How do the testers get access to user accounts?

We ask you to create dedicated test accounts for each user role in scope, set up for the engagement and removed afterwards. Credentials are exchanged securely during the engagement. Please don't include passwords or sign-in details in our website forms or quote builder.

Who carries out the testing?

Testing is delivered by qualified specialist testers, subject to specialist availability and approval. Pulsar IT scopes and coordinates the work and supports remediation. Tester details and relevant qualifications are confirmed in writing before testing starts, so you can check them against any requirements set by your customers or insurers.

Our application is hosted by a third party. Is that a problem?

Not usually, but some hosting and cloud providers have terms about security testing. During scoping we check who owns and hosts each part of the application, and get the authorisations needed before any testing starts.

What happens after the report?

We go through the findings with you, agree which to fix first and help coordinate the work with your developers or software supplier. Fixes to infrastructure we manage can be scoped separately, and an optional retest confirms whether the issues are resolved.

Let's Secure Your Business

Find out how Pulsar IT can help protect, manage and improve your IT environment.