Start a new scan

Before you begin

New scan starts one manual assessment against an active target. It does not create a target, grant permission, verify ownership, or change a schedule.

• Confirm that the target shows Active and still has current written authorization and technical ownership verification.
• Confirm that the exact public URL and path tree are the scope you intend to assess.
• Use the default observational profile for the selectable scan types on this page. Sensitive-response and passive API assessments use their own dedicated profiles and safeguards.

Open New scan

1. Open Scans from Griffin's main navigation.
2. Select + Add to open the dedicated New scan page.
3. Choose the active target you intend to assess. If Griffin preselected a target from its details page, verify it before continuing.
4. Confirm that the displayed target type, environment, and exact public scope match the approved assessment.

Choose observational scan types

For the default observational profile, select any one or more of the four available scan types. The checked combination is recorded with this scan and cannot be changed after launch.

• Availability and redirects — request the exact public URL and follow only redirects that remain inside the authorized origin and path tree.
• Transport and TLS — observe the public TLS handshake, certificate validity, and negotiated protocol without changing server state.
• Security response headers — evaluate bounded response-header metadata such as CSP, HSTS, cache, framing, and disclosure posture.
• Cookie attribute flags — evaluate Secure, HttpOnly, and SameSite flags; cookie values are never retained.
• Unchecked types are not tested. Griffin does not treat an unchecked type as a successful result or use it to clear an earlier finding.

Understand scan profiles

A scan profile defines what Griffin may observe, which safeguards apply, and which versioned limits are enforced. Choose a profile for the assessment you intend to run; selecting a profile does not broaden the target's authorization.

Griffin keeps unavailable profiles visible so you can understand supported workflows. If a profile is labeled Unavailable, that deployment capability is not enabled. Its target, authorization, ownership, and, where applicable, inventory and consent requirements still apply after it is enabled.

• Observational default v6 — the routine low-impact profile with four combinable scan-type checkboxes.
• Passive API posture v2 — a separately gated, bounded assessment of an explicit API endpoint inventory.
• Sensitive response exposure (development) v1 — a separately gated, aggregate inspection for potential sensitive content in one direct response.

Observational default v6

Use this profile for routine availability and public security-posture observations on an active, authorized website, web application, or API target. It performs one bounded GET sequence against the exact public scope, with no separate request for each checked scan type.

• What it observes — any non-empty combination of availability and same-scope redirects, transport and TLS posture, security response headers, and response-cookie attribute flags.
• When to use it — routine monitoring or a focused follow-up when you need only some of the four ordinary observational groups.
• Prerequisites — an active HTTP or HTTPS target with current written authorization and technical ownership verification for the exact origin and starting path tree.
• Safety and limitations — the checker is GET-only and capped at five requests, 1 MiB per response and in total, a 20-second connection window, a 60-second overall runtime, and concurrency one; same-scope redirects are capped at five. Griffin sends no credentials, does not crawl or submit forms, does not use exploit payloads, and does not retain response bodies or cookie values.
• Selection behavior — all four checkboxes start unchecked. Select at least one; the accepted combination becomes immutable for that manual scan. Unchecked groups are not tested, are not reported as passed, and cannot clear an earlier finding.

Passive API posture v2

Use this early-development profile only when you have explicit permission to assess a small, known set of public API endpoints in a development or test environment. It observes fixed transport, header, CORS, cache, content-type, natural error, version, inventory-alignment, rate-limit, and aggregate sensitive-response signals and reports a deliberately limited OWASP API Security Top 10 2023 matrix.

• Prerequisites and gates — the deployment capability must be enabled; the active target must be an API marked development or test; authorization must include bounded passive API assessment; ownership verification must be current; and you must save a current inventory of one to ten unique query-free relative GET paths.
• Consent — confirm fresh consent for that manual scan. Consent expires after 15 minutes, is one-use, and is bound to the current target, inventory, authorization, ownership, and profile.
• Safety and limitations — Griffin sends one sequential GET request per selected path, with at least 100 milliseconds between starts. The profile is capped at ten requests, 256 KiB per response, 1 MiB total, a 5-second connection window, a 30-second overall runtime, zero redirects, and concurrency one. It performs no crawling or endpoint discovery, uses no credentials, sends no mutations, and does not retain response bodies or detected values.
• Selection behavior — this profile is selected instead of Observational default v6 and does not use or combine with its four checkboxes. The saved inventory selects the exact paths for this scan. Schedules and automatic finding retests cannot use the profile or reuse its consent.
• Interpretation — an observed aggregate is a related passive signal, not proof of an authorization weakness, exploitability, complete API Top 10 coverage, certification, or compliance. Incomplete or unavailable results do not establish absence or clear an earlier finding.

Sensitive response exposure (development) v1

Use this early-development profile only when you are specifically authorized to check a development or test target for potential sensitive content in its direct public response. It automatically runs all four ordinary posture groups and adds aggregate classification across nine fixed families, including authentication material, credentials or secrets, private-key material, debug or database details, configuration data, regulated-data bundles, and authorization metadata.

• Prerequisites and gates — the deployment capability must be enabled; the target must be marked development or test; current written authorization must explicitly include sensitive-response inspection; and technical ownership verification must be current.
• Consent — confirm fresh consent immediately before each manual scan. Consent expires after 15 minutes and can be used only once. Authorization enables the capability but never substitutes for this one-scan confirmation.
• Safety and limitations — Griffin makes one GET request with a 1 MiB response and total-byte cap, a 20-second connection window, a 60-second overall runtime, zero followed redirects, and concurrency one. It inspects only the already-retrieved response, does not validate, decode, replay, or attempt to use detected material, and never retains or displays the body, matched values, excerpts, credentials, tokens, or value hashes.
• Redirect and compatibility behavior — a redirect is terminal: Griffin does not read its body or follow or retain its destination. Unsupported content types, encodings, redirects, and incomplete responses are reported as not evaluated or incomplete rather than clear.
• Selection behavior — this profile is selected instead of Observational default v6. It always runs all four ordinary posture groups plus the nine aggregate families, cannot be narrowed or combined through the v6 checkboxes, and is manual-only; schedules and automatic finding retests cannot use it or inherit consent.
• Interpretation — a result identifies a potential aggregate exposure. It does not prove credential validity, exploitability, an authorization bypass, or the absence of sensitive content when nothing was evaluated.

Review preflight and start

1. Confirm the selected target, default observational profile, and checked scan types. At least one observational scan type is required.
2. For a dedicated profile, complete its inventory or consent controls instead of selecting default observational types.
3. Select Review preflight. Griffin rechecks current authorization, ownership, target scope, profile, selected types, and enforced limits; review the displayed decision, profile, selected types, and target concurrency against the target summary above.
4. If preflight is blocked, resolve every reported requirement. Do not switch targets or profiles merely to bypass the denial.
5. When preflight is allowed and the summary is correct, select Start authorized scan once and wait for Griffin to accept it.

Monitor and interpret the result

• Use Scans to follow queued or running progress and open the scan details after acceptance.
• Review results only for the types selected when the scan started. Unchecked types remain not tested, not passed.
• A failed, cancelled, incomplete, or unavailable observation is not a successful security result.
• The checkbox selection applies only to this manual scan. It does not modify a schedule, automatic retest, target authorization, or a historical scan.
• Schedules and automatic finding retests that use Observational default v6 intentionally run the full four-type ordinary pack; they do not inherit a manual scan's narrower checkbox selection.