Skip to main content

Cyberstrike is now open source! AI-powered penetration testing for security professionals. Star on GitHub

Context Management

As the proxy-agent processes captured requests, it builds a progressive picture of the target application. This accumulated knowledge — credentials, roles, objects, functions, and discovered vulnerabilities — is called session context.

Two TUI commands give you direct access to this context during a testing session.

/web

/web

Aliases: /endpoints /roles /credentials

Opens an interactive dialog showing everything the proxy-agent has learned about the target application so far. The dialog has five sections you can navigate between.

Endpoints

Lists all HTTP requests captured and processed in the session:

ColumnDescription
MethodHTTP method (GET, POST, PUT, PATCH, DELETE)
PathNormalized endpoint path
StatusProcessing status (queued, processing, processed)

Use this to track which parts of the application have been analyzed and identify any endpoints still queued for testing.

Roles

Lists user roles discovered by proxy-analyzer across all processed requests:

ColumnDescription
NameRole identifier (e.g. admin, user, guest)
LevelPrivilege level — higher numbers indicate more access

Roles are extracted from responses (JWT claims, role fields in JSON), API documentation patterns, and endpoint naming conventions. They are used by proxy-tester-authz to determine whether privilege escalation is possible.

Credentials

Lists all registered credentials and the authentication headers the extension has captured for each:

ColumnDescription
LabelHuman-readable name (e.g. admin-user)
TypeAuthentication scheme (Bearer, Cookie, API Key, etc.)
RoleLinked role if the proxy-analyzer identified one
ContainerFirefox container ID

Select a credential to view its full auth headers and any claims extracted from JWT tokens.

Objects

Lists data entities discovered by proxy-analyzer:

ColumnDescription
NameEntity name (e.g. User, Order, Product)
FieldsAll known fields for this entity
Sensitive FieldsFields flagged as security-relevant (e.g. role, price, is_admin)
ID FieldsFields used as identifiers for IDOR testing

Select an object to see discovered values — specific IDs associated with each credential. These values are what proxy-tester-idor uses to test whether Credential A can access IDs belonging to Credential B.

Functions

Lists endpoint-to-function mappings extracted by proxy-analyzer:

ColumnDescription
NameFunction label (e.g. Login, Create Order, Delete User)
Action TypeCRUD classification: create, read, update, delete, auth
ObjectsData entities this function operates on
RoleRole required to use this function (if identified)

Functions give the proxy-agent a semantic understanding of the application — not just which endpoints exist, but what they do and who can call them. This is used for business logic testing and authorization analysis.

KeyAction
Switch between sections
Navigate items
EnterView detailed information
EscClose dialog or go back
h lSwitch sections (vim mode)
j kNavigate items (vim mode)

/vulnerabilities

/vulnerabilities

Aliases: /vuln /vulns

Opens the vulnerability viewer, listing all findings reported by the proxy-testing subagents.

Vulnerability Fields

Each finding includes:

FieldDescription
Severitycritical high medium low info
TitleShort description of the vulnerability
CWE IDCommon Weakness Enumeration identifier
LocationAffected endpoint, file, or parameter
DescriptionFull explanation of the issue
Steps to ReproduceExact request sequence to trigger the vulnerability
Business ImpactWhat an attacker could achieve
Proof of ConceptRequest/response evidence
RecommendationHow to fix the issue
Statusopen fixed ignored
KeyAction
Navigate vulnerabilities
EnterView full details
cCopy vulnerability to clipboard
EscClose or go back

Severity Reference

SeverityCVSS RangeExample
Critical9.0 – 10.0Auth bypass granting admin access, RCE
High7.0 – 8.9IDOR exposing other users’ data, Stored XSS
Medium4.0 – 6.9Reflected XSS, CSRF, information disclosure
Low0.1 – 3.9Missing security headers, verbose errors
InfoArchitecture observations, non-exploitable findings

How Context Accumulates

Session context is not pre-populated — it builds progressively as the proxy-agent processes captured requests:

Request 1: POST /api/login
→ proxy-analyzer discovers: User object, "admin" role, credential claims in JWT
Request 2: GET /api/orders/573
→ proxy-analyzer discovers: Order object, ID field, value "573" for admin credential
→ proxy-tester-idor tests: orders/572, /574, /1, /0 — finds no IDOR
Request 3: POST /api/orders
→ proxy-analyzer discovers: Order creation function, "total" and "discount" fields
→ proxy-tester-mass-assignment tests: inject discount field → FINDING: mass assignment
Request 4: GET /api/admin/users (logged in as regular-user)
→ proxy-tester-authz tests: access with regular-user credential
→ FINDING: admin endpoint accessible without admin role

Each new request adds to the knowledge base. Later requests benefit from context discovered by earlier ones — for example, IDOR testing becomes more precise once the proxy-analyzer has associated specific object IDs with specific credentials.

Programmatic Access

The web_get_session_context tool provides the same data to the proxy-agent and subagents. You can also ask the agent directly:

> What roles have been discovered in this session?
> Show me all objects with sensitive fields
> List all vulnerabilities found so far
> Which credentials do we have and what roles are they linked to?