WEFT / Application testing
Test the application like an attacker—
within a safe scope.
Find exploitable flaws in web, API, and mobile applications with manual testing, focused automation, useful remediation, and a comparable retest.
One-time or ongoing · Only approved scope and access
WEFT Security / Application testingRepresentative delivery view
Current scope
Review evidenceTest the application like an attacker—
01Broken object authorizationAPI · authenticated roleConfirmed
02Business-logic bypassWeb workflow · manual testFix planned
03Sensitive local storageMobile build · approved deviceReview
Tools and standards used where relevant
- Manual testing
- OWASP
- Burp-compatible workflows
- OWASP ZAP
- REST
- GraphQL
What the engagement changes
Focused work. Clear ownership. Verified results.
Cover behavior a scanner cannot understand.
Manual testing follows identities, workflows, trust boundaries, and business rules across the application.
Match intensity to the environment.
Targets, accounts, timing, exclusions, rate limits, and escalation contacts are agreed before testing.
Give teams a clear path to closure.
Reports explain reproduction, impact, evidence, remediation, and the result of retesting.
Service coverage
Know exactly what can be in scope.
The final scope is based on your application, environment, access, deadline, and risk—not a generic checklist.
Web application pentest
Manual testing covers authentication, authorization, sessions, business logic, input handling, and configuration.
API pentest
REST, GraphQL, and service APIs are tested for object, function, data, and workflow authorization failures.
Mobile application pentest
The client, API, storage, transport, and platform interactions are reviewed within the agreed device and build scope.
Authenticated testing
Approved roles and accounts are used to test real privilege and workflow boundaries.
Production-safe baseline
Low-impact checks can establish a baseline where active testing would be unsafe.
Retesting
Fixed issues are checked against the original vulnerable path and documented separately from open risk.
Manual depth
Follow the vulnerable path across clients and services.
Testing is organized around real identities and workflows, not a list of tool alerts.
- ✓Authentication and authorization
- ✓Business logic and abuse cases
- ✓Client, API, storage, and configuration boundaries
Attack pathRepresentative
01Role boundaryUser to administratorTested
02API object accessCross-tenant requestConfirmed
03Business impactUnauthorized actionExplained
Report to retest
Make every confirmed issue reproducible.
Evidence is kept concise enough to use safely while still giving developers what they need to understand and fix the problem.
- ✓Risk and business impact
- ✓Safe reproduction steps
- ✓Fix guidance and comparable retest
Retest evidenceRepresentative
01Original requestSensitive values redactedRecorded
02Fix suppliedNew build or deploymentReady
03Vulnerable pathNo longer exploitableVerified
How the service works
From approved scope to verified decision.
Testing depth and access are matched to the environment. Findings move through review, remediation support, and comparable retesting.
Authorize the target
Agree ownership, URLs or builds, environments, accounts, exclusions, and emergency contacts.
Model the application
Map identities, data, workflows, APIs, client behavior, and trust boundaries.
Test and communicate
Combine manual testing with relevant tooling and raise urgent issues through the agreed channel.
Report, fix, and retest
Deliver useful findings, support remediation, and verify the affected path.
Testing boundary
Authorization and safety come first.
No target is tested until ownership, scope, timing, intensity, and escalation contacts are agreed in writing.
Inspect trust practices- ✓Production testing uses explicitly approved techniques and limits.
- ✓Destructive testing, denial of service, social engineering, and third-party systems are excluded unless specifically authorized.
- ✓Credentials and sensitive evidence are handled through agreed secure channels.
- ✓A clean report never guarantees that an application has no vulnerabilities.
Complete application security
Bring in the other service areas when the scope needs them.
Do you test web, API, and mobile applications?
Yes. The exact combination depends on the application architecture, available build and accounts, test environment, and agreed objectives.
Can testing be performed against production?
Only with explicit authorization and a production-safe plan. Active or disruptive techniques are moved to a suitable non-production environment unless specifically approved.
Is retesting included?
Retesting can be included in the engagement scope and checks the original vulnerable path against the supplied fix.
Start with the application and outcome
Define a safe, useful scope.
Tell us what you build, what changed, what must be protected, and when you need the answer.