How to scan behind login in Cyberlop with authentication roles

To scan behind login in Cyberlop, open the Authentication section of a scan profile, click + Add role, name the role, set its privilege level and tick one or more login methods. An authentication role is a named login identity that the scanner uses to reach the parts of your app that only signed-in accounts can see.

Why scan behind login at all?

Most of what matters sits behind a login: orders, invoices, admin screens. A scan with no credentials only sees public pages. Cyberlop's own empty state says it plainly: "No auth roles. Add a role to scan behind login, or leave empty for unauthenticated scanning."

Attackers go after accounts, not just public pages. In the Verizon 2025 Data Breach Investigations Report, credential abuse (22%) and exploitation of vulnerabilities (20%) were the two leading initial access vectors, across more than 22,000 incidents including 12,195 confirmed breaches. Once someone holds a valid account, the weaknesses that count are the ones a signed-in account can reach.

The weakness families that live behind login are also the most common. The OWASP Top 10:2021 puts broken access control first: 94% of tested applications showed some form of it, with 318,487 occurrences and a maximum incidence rate of 55.97%. Identification and authentication failures, covered by the same list at A07, recorded 132,195 occurrences.

Only scan applications you own or are authorised to test, and only with accounts that were created for testing.

What is an authentication role in Cyberlop?

A role is one card in the profile's Authentication section. It has a name, a privilege level and one or more authentication methods. Roles belong to a scan profile, so each profile carries its own set. The Scan Profiles list shows the count in its Auth roles column, and so does the Scan profiles card on a target page.

The in-app documentation gives the pattern: add a normal user and, for IDOR and privilege testing, a second user. Each role can combine form login, header or API key, and OAuth 2.0, and can take free-text AI guidance. A role is also how the scan tells you which account did what: the sitemap shows a role chip on each endpoint, and a finding's Evidence tab states which authentication the proving request used.

This is authenticated testing. The post why your scanner has one login explains why a single account is rarely enough.

How do you add an authentication role?

Add a role from the profile form in six steps. The same steps apply when you edit an existing profile, apart from the fixed target.

1. Go to Scan Profiles and click + New profile, or open a saved profile with the pencil icon. Fill in the target and name on Scope first.
2. Click Authentication in the section switcher on the left.
3. Click + Add role. A role card appears, titled "Role 1".
4. Type a Name, such as customer-a or support-agent.
5. Choose the Privilege level.
6. Tick the Authentication methods, fill in the block that opens for each, then click Preview YAML and Save.

The role card, field by field

Which privilege level should you choose?

Pick the level that matches the real account you are giving the scan. The select offers four values, and the level is shown as a badge on the role card next to the method badge, for example "User" and "Form".

The app does not say how each level changes the scan, so treat the level as an honest label for the account, not a switch. What does the work is the set of accounts you add and the access each one really has.

How many roles do you need?

Start with two ordinary accounts, then add one for each privilege step you offer. Two accounts at the same level let the scan check whether one account can read the other's data. An account at a lower level plus one at a higher level lets it check whether the lower one can reach the higher one's functions.

A starter set of roles

The OWASP API Security Top 10 (2023) rates broken object level authorization as easy to exploit and widespread. Its prevention advice includes writing tests for the authorisation mechanism. Its sibling, broken function level authorization, is also rated easy to exploit and common. It appears when an ordinary account can reach a function meant for someone else. The first needs two peer accounts to test. The second needs accounts at different levels.

Keep test accounts safe

• Create them in a staging copy of the app, with made-up data.
• Give each the least access its level needs, in line with least privilege.
• Rotate them when someone leaves the project.

Which authentication method fits your app?

Choose the method your app actually uses to recognise an account. A role can tick more than one, because some apps need a form login plus an API key, or a token minted on the fly.

Form login in brief

The Form block asks for a Login type (FORM, SSO, API or BASIC), the Login URL, a username and password, an optional TOTP secret, a success condition and a login flow written one step per line. The placeholder flow reads "Click "Sign in"", "Fill #email with username" and so on. A TOTP secret lets the scan get past a second factor on an account made for testing.

Header and OAuth in brief

The Header block takes name and value rows. The OAuth 2.0 block mints a token through a client-credentials exchange and injects it as a header at scan time, "Authorization" with the prefix "Bearer " by default. Complete authentication runs the exchange to confirm a token is issued, and stays disabled until the fields are filled. See bearer tokens and OAuth.

What is AI guidance and how do you write it?

AI guidance is an optional text box, one step per line, that tells the scan how to use a credential. The Header and OAuth 2.0 blocks both have one. Use it for the facts only you know about how the credential behaves.

The placeholders show the style. For a header role: "Treat this as an admin API key", "Send it on every API request as-is; do not refresh it" and "Watch for endpoints that ignore it and fall back to a session cookie". For OAuth: "Prefer the freshly minted OAuth 2.0 access token" and "If a request is rejected, re-mint rather than reusing an expired token".

What good guidance looks like

Write one instruction per line

Keep each line short and in plain words, as the placeholders do.

Say how the credential behaves

• How long it lasts, where it goes, and what to do on a rejection.
• No secrets: they go in the credential fields.

Guidance about your app as a whole, such as tenancy model and business-critical flows, belongs in application context. Where a rule keeps the scan away from certain paths, use focus and avoid rules.

How do you check that a role worked?

Run the scan, then look for the role in three places: the sitemap, the Evidence tab and the profile list. None of them needs a special report.

1. Start the scan with ▷ Scan on the profile row. See run a scan.
2. Open the scan, then the Sitemap tab. Each endpoint row shows a role chip on the right, such as "admin", and a note written by the scan.
3. Open a finding and read the Authentication line on the Evidence tab. A finding proven with no credential says "No auth header was attached to the proving request."
4. Back on Scan Profiles, confirm the Auth roles count matches the roles you meant to add.

Read the scan sitemap guide for how to use it as a coverage check, and read a finding for the Evidence tab.

How do you edit or rotate a role?

Open the profile with the pencil icon and change the role card. Stored secrets are never shown again. On a saved role the Form block displays "Form credentials stored — leave fields blank to keep it." with a Clear button.

• Leave the username and password blank to keep the stored values.
• Type new values to replace them.
• Click Clear to remove the stored credentials.
• Click the trash icon on the role card to delete the role, then Save.

The target is fixed after a profile is created, so a role cannot be moved to another target. See edit a scan profile for the full rules.

Troubleshooting authentication roles

Most problems come from a role that is added but not complete, or a credential that no longer matches the app.

If a scan fails outright, follow failed or cancelled scans.

Common mistakes to avoid

• One role only. One account cannot show whether it reaches another account's data.
• A real customer account. Use made-up data in a test copy.
• A very powerful role for everything. An admin-only profile hides what an ordinary account can wrongly reach.
• Stale credentials. Passwords and tokens expire. Rotate and re-save them.

What to do next

Choose the method for your first role and set it up. For an app with a sign-in page, the next step is form login authentication. If you are still deciding which test type to use, read white-box vs black-box scans, and key terms for the vocabulary. Background on how the platform works is on how it works, and what a proven finding looks like is on evidence.