Use this page to prepare a first useful run. Give Tahr enough scope, access, and context to produce findings your team can review.
#The basic workflow
- Open Administration and verify the domains Tahr may assess.
- Add an application with the target URLs and scope.
- Complete the application setup checklist, including any login, repository, API, or mobile inputs needed by the assessment.
- Run an assessment manually, through a routine, on a schedule, or from CI/CD.
- Review findings, authorization issues, attack paths, source observations, and reports, then triage or export the results.
The setup checklist is conditional: a public web run may need only a verified target, while authenticated, API, source, mobile, or authorization work needs its corresponding inputs. Start with the smallest useful scope, confirm the evidence is relevant, and expand only after the first result is understandable.
#Before you begin
Prepare:
- The application URL and, when applicable, API URL.
- Permission to verify the application domain.
- A dedicated non-production target.
- Dedicated test accounts, with role, tenant, and object-ownership details.
- The login URL and an Authentication Check URL that proves a session is logged in.
- Repository access if source review is in scope.
- IP allowlist or WAF requirements, if the target restricts assessment traffic.
#Choose your first assessment type
For a first useful run, choose based on the question you need answered:
- Reconnaissance (Recon): discover and understand the external attack surface before broader testing.
- Source Code Analysis (Code Review): review a repository for code-backed security risks and remediation context.
- Full Assessment: perform broad web application security testing, including dynamic authorization testing when configured.
- Full Assessment (No Authorization): perform broad testing while skipping dynamic authorization testing when authorization is out of scope.
- Threat Modeling (Threat Model): identify threats, attack paths, assets, trust boundaries, and recommended mitigations.
- Android Pentest (APK): test an uploaded Android application package.
This onboarding shortlist is not exhaustive. See Choose the right assessment for every production assessment type and its prerequisites.
#Recommended first run
The Dashboard may recommend a first assessment based on a verified APK, usable authenticated setup, repository setup, or a public target. Always review the launch form before starting; the recommendation does not start an assessment automatically.
Start with one target your team controls and understands. Keep scope narrow, use dedicated test users, and review the setup checklist before launching. If a WAF or IP allowlist restricts traffic, configure the needed reserved IP first. Treat the first run as a setup-quality check: correct the target URLs, login flow, roles, and scope before expanding coverage.
A guided routine is an optional reusable, multi-step path. Selecting Start routine opens routine review and application selection; it never auto-starts a run.
#What good setup looks like
Use the real login URL, an Authentication Check URL that returns user-specific data, and test users for important roles. Describe tenant and ownership boundaries, mark out-of-scope areas, and add only the application context or repository details needed for the chosen workflow. Never put passwords, API keys, recovery codes, or other secrets in free-text fields.
#What Tahr produces
Depending on the assessment, Tahr may produce evidence-backed or potential findings, authorization issues, source observations, attack paths, and reports for review and remediation planning.