Application Penetration Testing

Application penetration testing is a scoped security assessment in which a tester attempts to compromise a named application within agreed limits. The work examines how authentication, authorisation, data handling, business logic and supporting interfaces behave when someone actively tries to misuse them.

In brief: A useful application test names the systems, user roles, methods, evidence and exclusions before work begins. The report should show what was tested, what succeeded, what remained outside scope and who owns each remediation action.

What application penetration testing covers

An application is rarely one interface. A customer portal may depend on APIs, identity services, administrative functions, mobile clients, background jobs and third-party integrations. The scope must say which parts are included.

Typical coverage includes:

• registration, authentication and account recovery;
• session creation, renewal and termination;
• role and object-level authorisation;
• input handling and output encoding;
• file upload, download and document processing;
• business workflows and state transitions;
• APIs used by web, mobile or partner clients;
• administrative and support interfaces;
• secrets, tokens and credentials exposed to the client;
• logging, alerting and response paths relevant to the test.

Coverage is not automatic. A web application test does not necessarily include its API, mobile application, cloud account or corporate identity platform. Each component needs a named boundary.

The OWASP Web Security Testing Guide provides a broad catalogue of web testing activities. The OWASP Application Security Verification Standard provides verification requirements. Neither source replaces a scope based on your architecture and risk.

Testing should also state the environment. Production may provide the most realistic behaviour, but it carries operational risk. A test environment may be safer, but only if its code, configuration, integrations and roles represent production closely enough for the evidence to matter.

How testing differs from vulnerability scanning

Vulnerability scanning and penetration testing support the same programme, but they answer different questions.

A scanner applies known checks repeatedly across a defined estate. It is useful for broad coverage, routine detection and confirming whether known weaknesses reappear. It can run often and report consistently.

A penetration tester works through context. The tester combines weaknesses, changes assumptions, follows business workflows and asks what an attacker can achieve. That judgement is useful where the effect depends on identity, sequence, data or application purpose.

The National Cyber Security Centre guidance on penetration testing explains the role and limits of a penetration test. Testing provides assurance about the target and conditions assessed. It does not guarantee that later changes remain secure.

Use scanning for routine visibility. Use penetration testing for focused assurance over attack paths and controls. Buying a penetration test to discover only scanner-grade findings wastes skilled time. Buying a scan when the question concerns business logic or chained access paths leaves the important question unanswered.

Choose the right application scope

The service label should match the technology and the decision you need to make.

A single product may need more than one row. A mobile application often depends on an API. A web portal may expose an administrative interface under a separate hostname. A desktop client may include an update service and a proprietary network protocol.

Define trust boundaries before techniques. Record where identities originate, where data crosses between systems and which components can perform privileged actions. This creates a testable map instead of a list of URLs.

Test accounts should represent the roles that matter. Include ordinary users, managers, support staff, administrators and service identities where those roles exist. Evidence should distinguish access granted for testing from access gained through a weakness.

Third-party services need explicit treatment. The assessment may review how your application calls them without testing infrastructure you do not own. Written authorisation and supplier rules determine what the tester may touch.

Define depth, access and constraints

Two suppliers can receive the same hostname and propose very different work. Make the required depth visible.

1. Name the assets: List applications, APIs, clients, environments and supporting identity services.
2. Name the roles: Define test accounts, starting permissions and any privileged access supplied.
3. Name the methods: State whether source-assisted review, authenticated testing, unauthenticated testing or code review is included.
4. Name the constraints: Record prohibited actions, sensitive workflows, production safeguards and rate limits.
5. Name the evidence: Agree what reproduction detail, screenshots, requests, logs and affected identifiers the report must contain.
6. Name the stop process: Provide operational contacts and a way to pause work immediately.
7. Name the closure: Define remediation support, retesting and the evidence required to close a finding.

Source access can improve coverage where the objective is assurance rather than simulation. Documentation, architecture notes and code context help a tester target important controls. Withholding all context may imitate an external attacker, but it can spend time rediscovering facts your team already knows.

That is a scoping choice, not a universal rule. State the threat model and choose access that supports it.

Authentication, authorisation and business logic

Authentication proves or recovers identity. Testing should cover registration, login, multi-factor flows, password reset, session renewal and account recovery. The important question is whether an attacker can become or remain another user.

Authorisation decides what an authenticated identity may do. Testers should examine both function-level and object-level controls. A user who cannot see an administrative button may still be able to call its endpoint. A user allowed to read one record should not be able to change an identifier and read another.

Business logic sits above both. The application may enforce every technical permission and still allow an unsafe sequence. Examples include reusing a one-time action, bypassing an approval step, applying a discount repeatedly or changing an object after it has been approved.

These tests require context. Automated requests can help explore states, but the tester needs to understand what each state means to the organisation.

Multi-tenant applications need a clear tenant boundary. The test should show whether identifiers, searches, exports, background jobs and shared caches respect that boundary. Evidence should state which tenant owned the source data and which identity obtained it.

API and integration testing

APIs deserve their own inventory. Record public endpoints, internal endpoints, partner interfaces, webhooks and administrative operations. Do not assume the front end calls every available function.

API testing should consider:

• token issuance, scope, expiry and revocation;
• object-level and function-level authorisation;
• request validation and mass assignment;
• pagination, filtering and export controls;
• rate limits and resource consumption;
• webhook authenticity and replay protection;
• error responses and sensitive metadata;
• versioning and deprecated endpoints;
• machine-to-machine identities and secrets.

GraphQL and other query interfaces need limits that match their design. The test should examine what fields and relationships an identity can request, not merely whether the endpoint responds.

Integrations create inherited trust. If a support platform, payment provider or automation service can change application state, test the controls on that route. The supplier’s platform may remain outside scope, while your handling of its messages, tokens and callbacks remains in scope.

Testing safely in production

Production testing may reveal behaviour that a test environment cannot reproduce. It also creates a real chance of disruption, data change or alert fatigue. The rules of engagement should decide whether that trade-off is justified.

Where production is included, define safe test windows, excluded records, rate limits and actions that require separate approval. Confirm backups, monitoring and the person authorised to stop work. Use identifiable test accounts so operational teams can distinguish agreed activity from an unrelated incident.

Destructive tests should be simulated unless the objective requires otherwise and the owner gives explicit approval. Evidence collection should minimise customer data. A tester may need to prove access without downloading an entire dataset.

Test environments still need scrutiny. Confirm they use representative code, roles and integrations. A permissive test tenant can hide an authorisation defect. A disconnected integration can remove the exact trust path the assessment was meant to examine.

The report should name the environment used for each finding. That detail determines whether the result can be reproduced and how confidently it applies to production.

Evidence and application test deliverables

A finding should be reproducible by the team responsible for fixing it. It should not require the reader to infer the affected user, endpoint or consequence.

For each finding, ask for:

1. the affected application, environment and component;
2. the starting identity and permissions;
3. the requests, sequence or workflow used;
4. the observed result and supporting evidence;
5. the realistic technical and business consequence;
6. the control that failed or was absent;
7. practical remediation guidance;
8. the accountable remediation owner;
9. verification terms for confirming the fix.

Severity should follow consequence and likelihood in your environment. A generic label without context is less useful than a clear explanation of what an attacker needs and what they gain.

The final report should also identify important areas tested where no exploitable issue was found. That record helps teams understand coverage. It must not be presented as proof that those areas can never fail.

Limitations belong beside the conclusion. Time, unavailable roles, unstable environments, excluded integrations and incomplete test data all affect confidence.

How to compare application testing providers

Give every supplier the same written boundary and required outputs. Otherwise, prices describe different services.

Ask:

• Who will perform the work, and what relevant application experience do they have?
• Which parts of the scope will receive manual testing?
• How will APIs, mobile clients or thick clients be handled?
• What access and test accounts are assumed?
• Can the provider show a redacted example report?
• How are credentials, screenshots and downloaded records protected?
• Are subcontractors involved?
• How are urgent findings escalated?
• Are remediation support and verification included?
• What exclusions could materially change the conclusion?

Credentials can provide useful evidence about an organisation, process or individual. They do not define the exact boundary, depth or delivery team for your engagement. Ask for both.

The CREST OVS programme is relevant when buyers need evidence about application security verification services. Treat any scheme against its published criteria and your procurement requirements. Do not infer coverage that the proposal does not state.

Compare price after scope, access, depth and deliverables are aligned. A lower price may reflect a narrower boundary, fewer roles, less manual investigation or no retest. That may be acceptable when it is visible.

Define the application boundary before requesting prices

Document the application, interfaces, user roles, permitted actions and evidence the assessment must produce. A precise boundary makes proposals comparable and the test more useful.

Ask LEVERAGE CYBER to review your application testing scope.