Test the application logic an attacker will actually meet.
A scanner can identify signatures. It cannot reliably determine whether one user can manipulate another user’s workflow, whether a recovery path bypasses authentication, or whether several low-severity conditions form a credible attack chain. The assessment is structured around the application’s real roles, data flows and trust decisions.
SCOPE → DISCOVER → TEST → VALIDATE → REPORT → RETEST
ASSESSMENT BOUNDARY
What is being assessed?
The engagement boundary is defined by systems, identities, workflows and restrictions—not only a list of URLs or assets.
- Public and authenticated application surfaces
- User roles, permissions and administrative workflows
- Authentication, session and account-recovery flows
- Business logic and multi-step transactions
- Server-side processing, integrations and file handling
- Client-side behavior and security configuration
What Botnet tests.
Testing is manual-led and supported by appropriate tooling. Findings are manually validated before reporting. Coverage follows reachable trust decisions and agreed risk; source-code review is not implied unless explicitly scoped.
Identity and session
Authentication paths, session lifecycle, recovery, token handling and controls around sensitive account changes.
Authorization
Object, function and role boundaries across normal and privileged application workflows.
Input and processing
Injection classes, server-side request behavior, unsafe parsing, upload handling and other reachable processing paths.
Business logic
Sequence manipulation, state transitions, limits, approval paths and ways valid features may be combined against their intended purpose.
Configuration and client
Security headers, browser-side exposure, caching, transport assumptions and deployment conditions that change exploitability.
Practical validation
Controlled proof of impact where safe and authorized, with destructive actions excluded unless explicitly agreed.
How the work progresses.
- 01
Scope
Agree targets, roles, assessment perspectives, production restrictions and evidence boundaries.
- 02
Discover
Map the application from unauthenticated, authenticated and multi-role perspectives included in scope.
- 03
Test
Use manual analysis supported by appropriate tooling to challenge access, state and processing controls.
- 04
Validate
Manually validate findings and safely establish exploitability or impact within the Rules of Engagement.
- 05
Report
Document evidence, affected flows, impact, remediation guidance and constraints.
- 06
Re-test
Use the included re-test to validate agreed remediated findings in a separately scheduled window.
EVIDENCE + ACTION
What the customer receives.
- Executive summary framed around business-relevant exposure
- Detailed technical findings with reproducible evidence and affected workflows
- Severity/risk context and practical remediation guidance
- Attack-path context where relevant, plus scope and testing limitations
- Readout session for technical and security stakeholders
- One re-test outcome for agreed remediated findings
Evidence over assumption.
01Workflow-led testing instead of endpoint counting
02Manual authorization and business-logic analysis
03Controlled validation of exploitability and attack chains
04Clear separation between observed evidence and assessor inference
Before scoping.
Can the assessment cover authenticated and unauthenticated behavior?
Yes, when both perspectives are included in the agreed scope and suitable accounts are provided. Roles and workflows should be identified during scoping.
Can testing be performed against production?
Potentially, but only after restrictions, contacts, rate considerations and prohibited actions are agreed. A staging environment may be preferable for higher-risk test cases.
Does submission of the request form authorize testing?
No. Testing starts only after Botnet accepts the scope, authorization/SOW is executed and kickoff requirements are complete.
Define the target, constraints and required evidence.
An assessment request starts a scoping conversation. It does not authorize testing. Work proceeds only after scope acceptance, executed authorization/SOW and kickoff.