How to set up form login authentication in Cyberlop

To set up form login in Cyberlop, open your scan profile, go to Authentication, click + Add role, tick Form, then enter the login URL, a test username and password, an optional TOTP secret, a success condition and the login flow steps. Form login authentication is how the scanner signs in to your app through its normal login page, so it can test what sits behind it.

You need an existing scan profile.

What is form login authentication?

Form login is one of three authentication methods a role can use in Cyberlop, next to Header (token / API key) and OAuth 2.0. It suits apps where a person types a username and password into a page. The scanner follows the steps you give it, checks your success condition, and then tests the signed-in part of the app. This is authenticated testing, and without it a scan sees only the public pages.

Each form login belongs to a role: a name, a privilege level (Unauthenticated, User, Elevated or Admin) and one or more methods. The authentication roles guide explains how to plan several roles. If your app uses tokens or API keys instead, read the header and token guide or the OAuth client credentials guide.

How do you add a form login to a scan profile?

Open the profile, choose Authentication in the left-hand section switcher, add a role, keep Form ticked and fill in the form login block. Then save the profile.

1. Go to Scan Profiles and open a profile with the pencil icon, or click + New profile.
2. Click Authentication in the section switcher.
3. Click + Add role. Enter a Name (the placeholder is admin) and choose a Privilege level. The default is User.
4. Under Authentication methods, leave Form ticked. It is on by default. Untick it if this role should use a header or OAuth instead.
5. Fill in the Form login block, using the reference table below.
6. Optionally click Preview YAML to validate the form, then click Save.

What does each form login field mean?

The table lists every field in the block, in the order the form shows them.

How do you write the login flow?

Write one plain-language step per line, in the order a person would do them. The form's own placeholder shows the pattern, and it is a good starting point for a simple page.

Click "Sign in"
Fill #email with username
Fill #password with password
Click submit

In the placeholder, username and password stand for the values you entered in the fields above, so the steps do not need to contain the secrets themselves.

What breaks a login flow most often?

Use the real field selectors

The placeholder uses #email and #password. Open your login page, inspect each input, and use the identifier your page really has. A wrong selector will stop a login step dead.

Cover every screen between start and signed in

If your app shows a cookie banner, a "continue with email" button or a separate password screen, add a step for each. Walk through the login once in a private window and write down every click.

How do you choose a success condition?

Choose something that is true only when the login worked. A success condition is the check Cyberlop makes after the flow to confirm the account is signed in. If it can also be true on a failed login, a failed login can look like a success.

Which success condition type fits?

What makes a weak condition?

Avoid a value that is also on the login page, such as / or the site name. A path like /login?error=1 can match Url Contains with /login. Test your choice by failing a login on purpose and checking that your value does not appear.

How do you use a TOTP secret with form login?

Paste the account's shared secret into TOTP secret so the login can pass a time-based one-time password step. TOTP is the standard used by authenticator apps, defined in RFC 6238. Codes are derived from a shared secret and the current time, and the RFC sets a default time step of 30 seconds.

The secret is not the six-digit code. It is the seed that your app displays once, often under a "can't scan the QR code?" link, when you enrol the test account's authenticator. If you did not keep it, reset two-step sign-in on the test account and enrol again. The RFC says keys should be protected against unauthorised access, so treat the secret like a password. Cyberlop stores target login credentials encrypted and never shows them again.

If your app asks for the code on a second screen, add a step for it in the login flow, and check the result with the success condition. For background, see the glossary entries on TOTP and multi-factor authentication. If your own organisation requires MFA for staff sign-in to Cyberlop, that is a separate setting, covered in the two-factor authentication guide.

Why does a working login matter?

A login that holds is the difference between scanning a marketing site and scanning the product. Most of the data and actions in a typical app sit behind sign-in, and many serious flaws only show up there.

Credentials are also a favourite route for outsiders. The Verizon 2026 Data Breach Investigations Report says 31% of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in. Both matter, and your scan profile can cover the first while your test account setup respects the second. OWASP puts identification and authentication failures at number seven in its 2021 Top 10, with a maximum incidence rate of 14.84% across the data it analysed, and lists missing or ineffective multi-factor authentication among the signs. The OWASP cheat sheet on multifactor authentication cites an analysis that MFA would have stopped 99.9% of account compromises. That is why testing a login that uses a second step is worth the setup.

How do you set up a safe test account?

Create an account that exists only for scanning, with a known password you can rotate. Cyberlop signs in with it and tests from there, so anything that account can change, the scan can change.

• Use staging. Where you can, point the target at a non-production copy with fake data. If you must use production, add avoid rules for sensitive paths and write limits into Rules of engagement.
• Use least privilege. Match the role's Privilege level to what the account really is. See least privilege.
• Do not reuse a person's account. A shared test account is easy to rotate and easy to audit.
• Rotate afterwards. Change the password when a testing round ends. Use a long, unique password, because a stored secret is still a secret.
• Test only what you own or are authorised to test.

For context on keeping secrets out of code and chat, see secrets management. Do not paste the test credentials into free-text fields like Rules of engagement or application context.

How do you check that the login worked?

Save the profile, run a scan, and then look at the evidence. A good login shows up in two places: the sitemap and a finding's Evidence tab.

1. Click ▷ Scan on the profile. The run a scan guide explains what happens next.
2. Open the scan and check the Sitemap tab. Pages and endpoints that need a login should be listed, and each endpoint row carries a role chip. See the scan sitemap guide.
3. Open a finding and read the Evidence tab. It has an Authentication line that shows which login the test used.

If the sitemap shows only public pages, the login probably did not hold. Go to the troubleshooting section below.

How do you change or clear stored credentials?

Open the profile again and the form login block shows a notice: "Form credentials stored — leave fields blank to keep it." Stored secrets are never shown again.

• To keep the stored login, leave the username, password and TOTP secret blank and save.
• To replace it, type the new values and save.
• To remove it, click Clear next to the notice.

The edit a scan profile guide covers this in more detail, including Preview YAML. The preview shows the generated scanner config without secrets.

How do you fix a login that does not work?

Work from the simplest cause: the selector, then the success condition, then the account itself.

What are the most common mistakes?

Using a real person's account

Use a dedicated account. Real accounts hold real data and may trigger alerts or lockouts.

Using a success condition that is true when signed out

Check that the value is absent from the login page and error pages.

Expecting form login to cover an identity provider redirect

The form lists SSO as a Login type, but it does not say what that changes, so follow the help text in the app. Where a test token or API key exists, a header or OAuth role may be simpler. See the single sign-on guide for signing in to Cyberlop itself, which is a separate matter.

What should you do next?

Next step: add a second role of a different privilege with the authentication roles guide, or use a token instead of a form in the header and token guide. If a scan stops early, see failed or cancelled scans. Giving the scan background on your app helps it too: see application context.