Choose vulnerability classes in a Cyberlop scan profile

A vulnerability class in Cyberlop is a family of weakness, such as Injection or Authz, that you switch on or off per scan profile. To choose vulnerability classes, open the profile's Scope section and tick the ones you want. Tick none and the profile covers all ten. This guide explains what each class covers and when to narrow.

What are vulnerability classes in Cyberlop?

Vulnerability classes are the ten checkboxes under Vulnerability classes in a scan profile: Injection, Xss, Auth, Authz, Ssrf, Crypto, Config, Business-logic, Dependency and Secrets. They decide which kinds of weakness the profile looks for. The help text under the box is short: "Leave empty to scan all classes."

Each finding's Class column uses the same ten names. The picker you use before a scan is the vocabulary you filter by afterwards.

What happens if you tick none?

The profile scans all classes, and nothing is left out. In the Scan Profiles list, such a profile shows All under Vuln classes. A narrowed profile lists its classes by name, for example "Injection, Auth, Authz, Ssrf".

For most first scans this is the right choice. A narrow profile means looking at less, so narrow on purpose. If you have not made a profile yet, start with create a scan profile.

What does each of the ten vulnerability classes cover?

Eight classes have a dedicated specialist agent in the vulnerability analysis phase, and the in-app Documentation gives each one a line. Dependency and Secrets appear in the picker and the Issues filter, but the Documentation does not describe them, so this guide covers them by name only. Table 1 sets all ten against the closest area of the OWASP Top 10:2025.

Table 1. The ten classes, what each covers and the nearest OWASP Top 10:2025 area

OWASP's own wording shows why the split is useful. Its 2025 edition reports that every application tested had "some form of broken access control" (OWASP, 2025), which is the ground the Authz class covers.

Which classes deal with untrusted input?

Injection, Xss and Ssrf all start with data your app trusts when it should not. The in-app docs keep each specialist "in its own lane" so one weakness is not reported several times.

Injection

Use it when your app builds queries, commands or templates from user input. A proven SQL injection finding shows the payload, request and response. OWASP's 2025 data counts 1,404,249 occurrences in its Injection category (OWASP, 2025).

Xss

Use it for pages that echo or store user content. Its three kinds are reflected, stored and DOM, and the exploitation phase proves findings with a real browser. See cross-site scripting.

Ssrf

Use it where your server fetches a URL a user can influence, such as webhooks, imports or previews. See server-side request forgery.

Which classes deal with identity and access?

Auth asks whether the app knows who you are and keeps that safe. Authz asks what you may then touch.

Auth

Login, logout, MFA, OAuth, SSO and session handling. Pair it with authentication roles so the scan can test behind login.

Authz

Missing ownership checks and privilege escalation. This is where one account reads another account's data, so give the profile at least two roles of different privilege.

Which classes deal with how the app is built and run?

These four look at the app's makeup rather than a single request.

Crypto

Weak keys, the wrong algorithm, JWT signing and timing-unsafe comparisons. OWASP's 2025 data counts 1,665,348 occurrences in its Cryptographic Failures category (OWASP, 2025).

Config

Security headers, CORS, cookie attributes, TLS and error verbosity. OWASP found "100% of the applications tested" had some form of misconfiguration (OWASP, 2025).

Dependency

The packages your app pulls in. OWASP notes that supply chain failures had the highest average incidence rate of any category, at 5.19% in its 2025 data (OWASP, 2025).

Secrets

Credentials and keys in the wrong place. In a white-box scan a finding points to a file and line.

What does Business-logic cover?

Business-logic covers flaws in your own rules, not in a framework. The docs list payment, pricing and quota bypass, replay, race conditions and workflow state flaws. Nothing is technically broken, but the rules can be turned against you. See business logic flaw.

How do you choose which classes to scan?

Leave everything unticked unless you have a specific reason to narrow. A reason is a change you know about, a question you want answered, or a re-check after a fix. Table 2 maps common situations to a starting point. These are suggestions for you to adjust, not rules the app enforces.

Table 2. Situations and a sensible class selection

When does narrowing make sense?

Narrow when the question is specific. A team that has just rewritten its payment flow gets a clearer result from Business-logic and Authz than from a full run, and the narrow profile also keeps the Issues list short enough to read in one sitting.

The app does not say a narrower profile finishes faster or costs less, so do not assume it. After a run, the scan's Overview tab shows the cost and tokens consumed, so you can compare. For where those numbers sit, see the scan detail page.

When should you keep all classes on?

Keep them on for a first scan, for a pre-launch review, and for any scheduled or pipeline run you rely on to catch something new. A class you cut is a class nobody looked at in that run. Most targets are best served by one full profile that runs on a schedule, plus one or two focused profiles that you run after related changes and before releases.

How do you set vulnerability classes on a scan profile?

You set them in the Scope section of the profile form, the same place on a new profile and when you edit one. Follow these steps.

1. Open Scan Profiles and click + New profile. From a target page, use + New profile on its Scan profiles card to preselect the target.
2. In Scope, pick the Target and give the profile a Name.
3. Find Vulnerability classes and tick the classes you want. Leave all ten unticked to scan everything.
4. Decide whether Run exploitation phase stays ticked. It is on by default.
5. Choose the Scan location, then add any focus or avoid rules.
6. Click Preview YAML to check the generated configuration, then click Save.
7. Click ▷ Scan on the profile row to run it.

The Scope section has these fields. Table 3 lists them in the order you see them.

Table 3. Scope fields on the scan profile form

Can you change the classes later?

Yes. Open the profile with the pencil icon on Scan Profiles, or Edit on the target page. The target is fixed, but the classes are not. Change the ticks and click Save. Your edit a scan profile guide covers stored secrets and validation.

How do classes work with the exploitation phase?

The classes decide what is looked for, and the exploitation phase decides whether it is proved. Per the Documentation, each specialist produces hypotheses with an exact file and line, and the exploitation phase then tries to demonstrate each one against the live target in a real browser. Findings are graded Confirmed, Likely or Unconfirmed by how well they were proved.

With Run exploitation phase unticked, the profile does static source analysis only and nothing is tested live. Read the exploitation phase guide before you run against production. Report filters in the Reporting section, covered in reporting rules, then cut the findings by minimum severity and confidence.

How do you see results by class afterwards?

Use the Class filter on the Issues page. It lists "All classes" plus the ten names, and sits beside the Severity, Confidence and Target filters. Each finding also shows a class in the scan's Findings tab, and its ID begins with a class prefix, for example INJ-VULN-02 or AUTHZ-VULN-04.

The API supports the same filter: GET /api/issues accepts a vulnClass parameter alongside scanId, targetId, severity, confidence and triageStatus. Each finding also gets CWE and OWASP references, which map the class to the standard names your auditor knows (CWE, OWASP Top 10).

Table 4. Where the class shows up in the app

What are the common mistakes when choosing classes?

Narrowing before you have a baseline

A first scan with two classes ticked can look clean for the wrong reason. Run one full profile first, so the focused ones have something to be compared with.

Treating a narrow re-scan as proof everything is fixed

Issues persist per target, and a re-scan marks a finding Fixed only when it genuinely did not re-detect it. The Documentation we captured does not say how a class you left unticked is treated. Open the Diff tab and read it before you trust the Fixed count. See compare scans and fixed and regressed issues.

Ticking Authz with a single role

Access-control flaws show up when two accounts of different privilege are in play. The Documentation suggests "a normal user and, for IDOR/privilege testing, a second user". Add the roles first, as authentication roles explains.

Leaving out application context

The classes say what to look for, and the Application context fields say what matters in your app: tenancy model, sensitive data types, business-critical flows. Fill them in; see application context.

Scanning something you do not own

Only scan targets you own or are authorised to test, whatever classes you pick. Black-box targets need ownership verified first.

Next step: now that the scope is set, decide how far each scan should go in the exploitation phase guide. For the terms used here, see key terms. If you are still choosing between scan types, read white-box vs black-box scans.