Authenticated testing

Most of a real application sits behind a login. A scan that only sees the signed-out surface misses it.

Auth profiles

An auth profile is a set of credentials the scanner replays on every request. It is saved against one asset, so you pick it from a dropdown each time you start a scan on that target.

Two kinds:

• HTTP headers — for bearer tokens and API keys. One row per header, such as Authorization, X-API-Key, or X-Tenant-ID.
• Cookie jar — for session cookies. One row per cookie, such as session, auth_token, or remember_token.

Values are encrypted before they are stored, and only the scan runner reads them.

Leaving the profile unset (Unauthenticated) does not confine the scan to the signed-out surface. The agent uses any credentials you include in the scan's notes or context documents, and signs up its own test accounts where the application allows it.

The section appears for repository assets and for grey-box and white-box scans. A black-box scan against a public URL has nowhere to send credentials.

Env profiles

An env profile is environment variables, not credentials. It is offered for a white-box scan where Interopt boots the runtime from source: the values are injected into the install and build step before static analysis runs.

Pasting .env-style text into the form imports it as rows, so you can move a file across without retyping it. Like auth profiles, values are encrypted and scoped to one asset.

Context documents

The Scope step takes supporting material under Documentation: an OpenAPI or WSDL spec, a Postman collection, architecture diagrams, screenshots, or written notes.

Up to five documents per scan, 10 MB each and 25 MB in total. They are stored privately and given read-only to that scan's agents.