← Tahr SecurityCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Tahr Security
Snapshot Sep 30, 2026 · 23:16 UTC · version 0.3.3
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "tahr-map-attack-surface",
"description": "Map the real security-relevant surface of a web application or API from source, specifications, JavaScript, browser behavior, and authorized traffic. Use for pre-pentest reconnaissance, security-review scoping, hidden route or parameter discovery, undocumented API inventory, role-aware surface comparison, or judging whether an existing review actually covered the application.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 233
},
{
"relative_path": "references/coverage-gates.md",
"size_in_bytes": 1814
},
{
"relative_path": "references/surface-inventory.md",
"size_in_bytes": 2128
}
],
"skill_md_contents": "---\nname: tahr-map-attack-surface\ndescription: Map the real security-relevant surface of a web application or API from source, specifications, JavaScript, browser behavior, and authorized traffic. Use for pre-pentest reconnaissance, security-review scoping, hidden route or parameter discovery, undocumented API inventory, role-aware surface comparison, or judging whether an existing review actually covered the application.\n---\n\n# Map the Attack Surface\n\nBuild an evidence-backed inventory before testing vulnerabilities. Treat every discovered item as coverage evidence, not as a finding.\n\n## Set the boundary\n\n1. Identify the repository roots, application origins, API origins, environments, and supplied specifications or traffic captures.\n2. Record the allowed runtime scope. Do not contact a live target unless the user supplied it or clearly authorized testing it.\n3. Default to source-only analysis when authorization, credentials, or a runnable environment are absent.\n4. Keep runtime activity read-only and low volume. Do not submit destructive forms, create real orders, send invitations, modify accounts, or enumerate unrelated infrastructure.\n5. Never print or persist passwords, cookies, bearer tokens, API keys, reset links, private keys, CSRF values, or user PII. Retain names, locations, value classes, lengths, and short SHA-256 fingerprints when useful.\n\n## Inventory independent evidence sources\n\nInspect each available source independently before merging:\n\n- server routes, controllers, RPC handlers, middleware, authorization declarations, background jobs, queues, and WebSocket/SSE handlers;\n- OpenAPI, Swagger, GraphQL schemas and documents, generated clients, protobufs, and API examples;\n- frontend routes, forms, fetch/axios clients, lazy chunks, source maps, feature flags, upload configuration, storage keys, and custom headers;\n- infrastructure routes, reverse-proxy rules, serverless functions, storage buckets, callback handlers, and public documentation;\n- authorized unauthenticated and authenticated browser/API traffic, separated by identity, role, and tenant.\n\nDo not infer reachability from a route name alone. Mark each operation as source-derived, documented, browser-observed, traffic-observed, or runtime-confirmed.\n\n## Build canonical operations\n\nRead [surface-inventory.md](references/surface-inventory.md) and create one record per meaningful operation. Preserve:\n\n- protocol, origin, method or operation type, path, content type, and request shape;\n- query, path, body, header, cookie, form, multipart, and GraphQL variable fields;\n- authentication state, identity/role/tenant context, object identifiers, owner hints, and workflow state;\n- response class, state-changing behavior, source artifact, and confidence.\n\nDo not merge operations when method, body shape, parser, auth state, role, tenant, owner, response behavior, or workflow state differs. Preserve exact endpoint-to-field provenance; a global parameter list is insufficient.\n\n## Prioritize attacker-relevant surface\n\nRank concrete operations higher when they expose:\n\n- login, reset, MFA, invite, token, session, or account lifecycle behavior;\n- admin, role, tenant, membership, ownership, billing, entitlement, approval, or settings functions;\n- object IDs in any carrier, bulk/composite IDs, exports, downloads, or sensitive response fields;\n- upload, import, preview, render, conversion, callback, webhook, URL-fetch, or integration behavior;\n- price, total, quantity, discount, status, state, owner, tenant, role, or idempotency fields;\n- HTML/Markdown/template input, search/filter/sort expressions, file paths, XML, or serialized data;\n- undocumented versions, hidden client routes, debug endpoints, source-map leads, or role-specific discrepancies.\n\nPriority controls review order only. Do not discard lower-ranked operations.\n\n## Close coverage gaps\n\nRead [coverage-gates.md](references/coverage-gates.md). Assign every discovered item one terminal state: `visited`, `runtime_confirmed`, `source_only`, `queued`, `partially_explored`, or `skipped_with_reason`.\n\nWhen discovery is unexpectedly shallow, perform one bounded second pass using a different evidence source: follow lazy routes, inspect request builders, parse schemas, expand safe UI elements, or compare another supplied identity. Never describe absent evidence as proof that a feature is absent.\n\n## Deliver the inventory\n\nReport:\n\n1. scope and evidence sources inspected;\n2. canonical operations grouped by trust boundary and identity context;\n3. high-value targets with exact provenance;\n4. identity, tenant, object, upload, callback, and workflow maps;\n5. coverage gaps, blocked areas, and the consequence of each gap;\n6. candidate hypotheses clearly labeled as unverified.\n\nDo not assign vulnerability severity from recon alone. Recommend the appropriate Tahr testing skill for each candidate class.\n"
}SHA-256: 9c757d930490ca2cdacb8fcd06639b767a67432551132a442ec0e6136524d441