Phase 3.5: Smart Routing (Endpoint-to-Test Mapping)¶

Overview¶

Phase 3.5 is an intelligent router that analyzes all discovered endpoints and maps each to the most relevant test scopes. Instead of testing every endpoint with every skill (wasteful), Smart Routing reduces testing scope to only relevant tests.

Purpose: Create a focused test-plan.json that directs Phase 4 agents to test only the endpoints where vulnerabilities are most likely to exist.

Why Smart Routing Matters¶

Without routing, Phase 4 would test: - Parameter injection on endpoints that don't accept parameters - CSRF on endpoints that don't change state - IDOR on endpoints that don't return resources - File upload on endpoints that don't accept files

This wastes time and tokens. Smart Routing prevents this waste by analyzing endpoint signals and assigning only relevant test categories.

Signals: How Endpoints Are Classified¶

The router analyzes endpoints using 20+ signal rules:

Injection Signals (SQLi, XSS, CMDi, etc.)¶

Signal	Indicates	Test Assignment
Parameter name contains `sort`, `order`, `filter`, `search`, `q`	Injection on sorting/filtering	test-injection:sqli, test-injection:xss
Parameter name contains `filename`, `path`, `file`	File path injection	test-injection:lfi, test-injection:cmdi
Parameter value accepts special chars: `'`, `"`, `;`, `\\|`, `&`	Injection likely	test-injection:* (all)
Endpoint path contains `/export`, `/download`, `/report`	Command/template injection	test-injection:cmdi, test-injection:ssti
Response contains `System.out.print`, `exec`, `eval`	Server-side code execution	test-injection:ssti, test-injection:cmdi
Parameter used in response (echo back)	XSS likely	test-injection:xss

Access Control Signals (IDOR, Authz, etc.)¶

Signal	Indicates	Test Assignment
URL contains `{id}`, `{userId}`, `/:id`	Resource-based access	test-access:idor
Endpoint returns user data (email, name, profile)	IDOR target	test-access:idor, test-access:authz
Different responses based on user role (admin vs user)	Authz enforcer	test-access:authz
Endpoint path contains `/admin`, `/staff`, `/moderator`	Privilege escalation target	test-access:authz
User can enumerate IDs (1, 2, 3, 4...)	IDOR enumeration	test-access:idor

Authentication/Session Signals¶

Signal	Indicates	Test Assignment
Endpoint path `/login`, `/authenticate`, `/oauth`	Auth testing	test-auth:jwt, test-auth:oauth, test-auth:session
Response includes `Set-Cookie` with `SessionId`, `JSESSIONID`	Session-based auth	test-auth:session
Response includes `Authorization: Bearer` header	JWT or OAuth	test-auth:jwt, test-auth:oauth
Token expiration in response	Session lifetime testing	test-auth:session

Business Logic Signals¶

Signal	Indicates	Test Assignment
Endpoint path `/cart`, `/checkout`, `/payment`, `/order`	Financial logic	test-logic:business
Parameter name contains `amount`, `price`, `quantity`, `discount`	Amount manipulation	test-logic:business
Endpoint accepts concurrent requests	Race condition testing	test-logic:race
Request has side effects (creates data, modifies state)	Race conditions	test-logic:race

API/GraphQL Signals¶

Signal	Indicates	Test Assignment
Endpoint path `/graphql`	GraphQL testing	test-api:graphql
Response `Content-Type: application/graphql`	GraphQL API	test-api:graphql
REST endpoint with nested resources	REST API testing	test-api:rest
Parameter structure matches JSON schema	REST API	test-api:rest

File Upload Signals¶

Signal	Indicates	Test Assignment
Endpoint path contains `/upload`, `/import`, `/attachment`	File upload testing	test-logic:upload
Endpoint accepts `Content-Type: multipart/form-data`	File upload handling	test-logic:upload
Request body contains file data	File upload testing	test-logic:upload

Test-Plan JSON Structure¶

The /route skill generates a test-plan.json file:

{
  "_version": "1.0",
  "target": "https://api.example.com",
  "total_endpoints": 47,
  "test_groups": {
    "test-injection:sqli": [
      "/api/v1/users?sort=",
      "/api/v1/tickets?filter=",
      "/api/v1/reports?q=",
      "/api/v1/employees?order="
    ],
    "test-injection:xss": [
      "/api/v1/comments?text=",
      "/api/v1/tickets?description=",
      "/api/v1/messages?content="
    ],
    "test-access:idor": [
      "/api/v1/users/{id}",
      "/api/v1/profiles/{id}",
      "/api/v1/tickets/{id}",
      "/api/v1/documents/{id}"
    ],
    "test-access:authz": [
      "/api/v1/admin/users",
      "/api/v1/admin/settings",
      "/api/v1/admin/reports"
    ],
    "test-auth:session": [
      "/api/v1/auth/login",
      "/api/v1/auth/logout",
      "/api/v1/auth/refresh"
    ],
    "test-logic:business": [
      "/api/v1/cart/add",
      "/api/v1/checkout/process",
      "/api/v1/orders/create"
    ],
    "test-logic:race": [
      "/api/v1/cart/add",
      "/api/v1/tickets/claim",
      "/api/v1/resources/reserve"
    ],
    "test-api:rest": [
      "/api/v1/users",
      "/api/v1/tickets",
      "/api/v1/comments"
    ],
    "test-logic:upload": [
      "/api/v1/documents/upload",
      "/api/v1/profiles/avatar",
      "/api/v1/attachments/upload"
    ]
  },
  "endpoint_groups": {
    "test-injection:sqli": {
      "group_count": 2,
      "groups": [
        ["/api/v1/users?sort=", "/api/v1/tickets?filter=", "/api/v1/reports?q="],
        ["/api/v1/employees?order="]
      ],
      "reason": "18 injectable endpoints split into 2 agent groups"
    }
  },
  "skipped_endpoints": {
    "test-static-assets": ["/css/style.css", "/js/app.js"],
    "reason": "Static assets do not require testing"
  }
}

Endpoint Grouping for Level 3 Parallelism¶

When an endpoint category has many endpoints, the router groups them for parallel testing:

Grouping Rules¶

Endpoint Count	Groups	Reason
1-12	1 group	Single agent sufficient
13-24	2 groups	Balanced parallelism
25-36	3 groups	Maximum useful parallelism
37+	3 groups	Cap at 3 (more overhead than benefit)

Grouping Strategy¶

Endpoints grouped by resource type, not random: - All /users/* endpoints in Group 1 - All /tickets/* endpoints in Group 2 - All /reports/* endpoints in Group 3

This ensures each agent has coherent context about a resource domain.

Routing Rules vs. Blanket Testing¶

Smart Routing: Only test endpoints with relevant signals - SQLi testing only on endpoints with sort, filter, search parameters - IDOR testing only on endpoints with {id} in path - File upload testing only on endpoints that accept file content

Blanket Testing (NOT RECOMMENDED): Test everything with everything - Would test 47 endpoints × 17 skills = 799 total test scenarios - Most would be false negatives (endpoint doesn't support that test) - Wastes tokens and time

How Phase 4 Uses test-plan.json¶

During Phase 4, the /pentest wave coordinator reads test-plan.json:

# Phase 4 dispatch examples
dispatch_agent "test-injection" "example.com" "$EDIR" "sqli" \
  "--endpoints /api/v1/users?sort=,/api/v1/tickets?filter="

dispatch_agent "test-access" "example.com" "$EDIR" "idor" \
  "--endpoints /api/v1/users/{id},/api/v1/tickets/{id}"

Each agent receives ONLY the endpoints relevant to its test category.

False Negatives Prevention¶

Smart Routing prevents false negatives by:

Testing ALL endpoints of a vulnerable type
If injection found on /search?q=, also test /filter?q=, /query?q=, etc.
If IDOR on /users/{id}, test /profiles/{id}, /tickets/{id}, etc.
Using signal-based heuristics, not blacklists
Instead of excluding endpoints, signals INCLUDE only relevant tests
Endpoint without signals gets baseline tests (no auth, invalid role, etc.)
Fallback testing for edge cases
If endpoint matches no signals, it still gets tested by generic agents
Prevents "safe looking" endpoints from being skipped

Skipped Endpoints¶

Some endpoints are explicitly skipped to save time:

Endpoint Type	Reason
Static assets (`.js`, `.css`, `.png`, `.jpg`)	No server-side logic
3rd-party iframes (`/stripe/`, `/google/`)	Tested by 3rd-party
Health checks (`/health`, `/ping`, `/status`)	No vulnerability surface
Documentation (`/swagger`, `/docs`, `/api-docs`)	Read-only disclosure

Output: test-plan.json¶

Location: discovery/test-plan.json Size: 5-50 KB depending on endpoint count Used by: Phase 4 testing coordinator

Next Phase¶

After Phase 3.5 completes, proceed to Phase 4: Testing where agents dispatch with focused test plans based on test-plan.json.