Glossary

Definitions for the terms used across APIsec documentation and the console. Terms are listed alphabetically. Each entry has a stable link, so you can reference one directly — for example /docs/glossary#instance.

Application

A logical API product in APIsec — the entry that anchors all testing for that API. An application holds one or more instances, and it is the level at which access is granted to teams and users.

Creating the application is Step 1 of the App Model, and it can exist before you have a reachable URL.

App Model

APIsec's seven-step workflow for building up API test coverage one layer at a time: create the application, set the instance URL, run an unauthenticated scan, configure authentication, run an authenticated scan, add parameter values, then configure RBAC. Each layer is validated before the next depends on it.

See Understanding the App Model.

BOLA

Broken Object Level Authorization — a flaw where one user can read or modify another user's objects by changing an identifier in a request. It is the first entry in the OWASP API Top 10 and among the most common serious API vulnerabilities. APIsec tests for it by replaying requests across identities and comparing what each is allowed to reach.

See BOLA findings.

Business unit

An organizational grouping that contains teams. Business units let a large tenant mirror its internal structure — for example a region or a division — so team and application access can be organized along the same lines.

Console

The APIsec web application, where you onboard APIs, run scans, review findings, and manage users and credentials. Some actions are available only in the console and not through the API; where that is true, the documentation says so.

CVSS

Common Vulnerability Scoring System — the industry-standard severity score. APIsec reports each detection with a numeric cvssScore and a qualifier of Low, Medium, High, or Critical. Threshold controls, including the CI/CD gate, act on the qualifier.

Detection

A single finding produced by one security test against one endpoint. Detections belong to an instance, not to the application as a whole — so an application with a staging and a production instance carries two independent sets of findings.

Every detection has a status and, where the test maps to one, an OWASP API Top 10 tag.

Endpoint

One operation on your API — an HTTP method plus a path, such as POST /identity/api/auth/login. Endpoints are discovered from your API specification or from recorded traffic, and they are the unit APIsec runs tests against.

Entitlement role

A user's relationship to one specific application: either Owner or Collaborator. It is distinct from platform role, which is tenant-wide. Ownership matters for access management — a user with the USER platform role must be an owner of an application to change who can reach it.

Alongside the entitlement role, each user has a permission of View or Edit on the application.

False Positive

A status an analyst applies to a detection that is not a real vulnerability. The detection stays visible in the console so the decision can be reviewed or revoked later, and it records who made the call.

Revoking a False Positive triggers a re-test, because the point of revoking is to find out whether the finding was real after all.

Hosted agent

A container you run inside your own network so APIsec can test APIs that are not reachable from the internet. The agent opens one outbound connection to APIsec over TCP 443 and runs no listener of its own, so your perimeter stays closed and your target APIs stay internal.

See Hosted Agents.

Instance

One deployed environment of an application — production, staging, and so on. An instance carries its own host URL, its own scan history, and its own detections.

Most APIsec operations that return findings or metadata work at the instance level rather than the application level, so you generally need both an application ID and an instance ID.

Because detections attach to an instance, the same vulnerability present in two environments is two separate detections, with separate identifiers and independent triage histories. Fixing it in staging does not resolve the production finding.

Issue tracker

An external system — such as Jira, Azure DevOps, or ServiceNow — that APIsec connects to so findings can become tickets. Once configured for an instance, APIsec can create tickets for new findings and update or close them as the underlying detection changes state.

See Integrations.

Metadata tag field

A tenant-wide label definition you can assign to instances — for example a Data Classification field with the options Public, Internal, and Confidential.

Metadata is not free-form key/value. Each field carries a fixed catalog of options, and an instance is assigned one or more of those options. Both the field and its options are referenced by identifier.

OWASP API Top 10

The Open Web Application Security Project's list of the ten most critical API security risks. APIsec tags applicable findings with the corresponding identifier — for example API8:2023 — so results can be mapped to the framework for reporting.

Personal Access Token

A long-lived API credential, also called an API Token or PAT, presented as a bearer token in the Authorization header. A token is bound to one tenant, one platform role, and a fixed set of scopes chosen when it is created. Scopes cannot be added afterward — create a new token instead.

For CI/CD, prefer a short-lived OAuth Client Credential over a PAT.

See API Credentials.

Platform role

A token or user's tenant-wide role: ADMIN, USER, VIEWER, or GLOBAL_VIEWER. It is one of the two checks that govern API access, the other being scope. It is distinct from entitlement role, which applies to a single application.

ADMIN bypasses per-application ownership requirements. VIEWER is read-only over the applications shared with that user; GLOBAL_VIEWER is read-only over every application in the tenant, without needing direct or team-based assignment.

The console shows these as Viewer and Global Viewer. The API, the CSV import, and SSO group names always use the literal VIEWER and GLOBAL_VIEWER.

RBAC

Role-Based Access Control. In APIsec, RBAC testing validates that each role in your API can reach only what it is permitted to — catching privilege escalation and horizontal access flaws that a single-identity scan cannot find. Configuring it is Step 7 of the App Model.

See RBAC findings.

Risk Accepted

A status an analyst applies to a real detection the organization has decided to accept rather than fix. It records who accepted the risk and can carry an end date, after which the acceptance lapses.

Unlike False Positive, Risk Accepted does not dispute the finding — it acknowledges it.

Scan

One execution of APIsec's test suite against an instance. A scan is either running (Processing) or finished (Complete, Failed, or Aborted), and produces detections. Scans can be started manually, on a schedule, or from a CI/CD pipeline — see trigger source.

Scan profile

A saved, reusable scan configuration. Rather than setting options each time, you define a profile once and run scans against it, which keeps repeated runs consistent.

See Scan Profiles.

Scope

A permission string on a Personal Access Token that authorizes a category of API operation — for example scan:get to read scans, or app:manage:access to share applications. Scope is checked alongside platform role; a request needs both to succeed.

Specification

A machine-readable description of your API, usually OpenAPI. APIsec uses the spec to discover endpoints, parameters, and expected responses, which is what lets it generate meaningful tests. You can supply one directly, generate it from recorded traffic, or let APIsec analyze and enrich what you provide.

See Spec Analysis.

Status

The triage state of a detection. The values are:

Value	Meaning
ACTIVE	Open. The finding is present and untriaged.
RESOLVED	Fixed — a later scan no longer reproduces it.
FALSE_POSITIVE	An analyst judged it not to be a real vulnerability.
RISK_ACCEPTED	Real, but accepted rather than fixed.

Surface

Surface is APIsec's family of products that contribute to deeply understanding applications in order to perform the most extensive and accurate dynamic tests possible.

It builds a picture of your API estate and correlates statically discovered risk with what testing confirms at runtime.

Team

A group of users within a tenant, optionally organized under a business unit. Associating an application with a team grants access to every current member of that team, and to anyone added later. Adding a user to a team does not by itself grant them any application.

Tenant

Your isolated organization within APIsec. Every application, scan, finding, user, team, and credential belongs to exactly one tenant, and nothing is visible across tenants. A Personal Access Token is bound to a single tenant.

Trigger source

What started a scan. The console's Scan History shows one of three values:

Value	Meaning
MANUAL	Started by a user in the console.
CI_CD	Started by a pipeline.
SCHEDULED	Started by a configured schedule.

See CI/CD Integration.