These docs are for v1.1. Click to read the latest docs for v1.2.

Troubleshooting Authentication Issues

For Browser Based Form Authentication, if a stage is still executing, the prior one doesn't immediately start


An intermediary stage can be added to allow the prior stage to fully complete before initiating the following stage.


For example, if Stage 1 takes twenty seconds to complete, you can add an intermediary WAIT-stage after Stage 1 before proceeding to Stage 3. In the Auth Flow Setup, at the end of any Stage, click Add StageStandbyWait for ... Seconds

Recording created with Google Chrome recorder is not replayed with the Evaluation failed error

When replaying the recording, an error appears: Evaluation failed. TypeError: Failed to execute ‘observe’ on ‘IntersectionObserver’: parameter 1 is not type ‘Element’…


Google Chrome cannot find the element by one of the selectors.


  1. Expand the step where the error appears.
  2. Click “-” against the affected selector to delete it.

3. Replay the recording.

4. If the replay is encountering the same errors, repeat steps 1-2 till the replay is successful.

Recording created with Google Chrome recorder is not replayed because UID was changed

Some web applications specify a UID in the element name. Since web applications are frequently releasing new features, UID might change, which will cause the authentication object not working.



Remove the UID from the recording to create a generic authentication object that would work even if a new web application is released.

  1. Expand the step containing UID.
  2. Delete the UID.



For creating recording, see Configuring Recorded Browser-Based Form Authentication.

Surface discovery

Indicators of this issue
  • Response statuses include:
    • NexPloit::Session::AuthFlow::Error
    • 401
    • 405
  • Percentage of problematic statuses out of the total responses >10%
Configuration problems
  • The authentication object is configured incorrectly.
  • The wrong authentication object is selected for the scan.
  • The scan requires more than one type of authentication object.
  • Some specific entry points may need different authentication parameters (like HMAC headers).
Remediation suggestions
  • Create an authentication object that follows the design and flow of authorization within your web application. Bright has different types of authentication objects that can be used in scans. For detailed information, see our documentation - Authentication Types.
  • Check the configuration of the exiting authentication object. For example, if you are using a Custom API Authentication object, check the validity of the regex and validate if your authorization data is correct. You can find more about regex in our documentation - String Interpolation Syntax.
  • Check if there is a need for an HMAC script for additional authorization (if more headers are needed). In the Repeater script, you should specify how exactly the server calculates the HMAC code to allow Bright to provide a valid HMAC token. Bright can reach targets ONLY after a successful HMAC authorization with the relative server. For more information, see our documentation - Using Repeater Scripts.



If you need help with this issue, contact our support at [email protected] or via Intercom at the bottom right of the Bright app.

An authorization flow can not be done successfully

While adjusting the TOTP in the authorization flow, sometimes the process can not be done successfully. An error will be shown at the step with OTP.


Try to change the type to Google Authenticator or vice versa.

How to set up the HOTP server counter

While using HOTP, a configured authentication server that will not increase the number of HOTP counters after each successful one-time iteration is needed.


To do this, the start counter on the server must be 0. Thus, the counter will increase by 1 after creating the first code and binding it to the server. Next generated codes will use the counter value = 1 on both the server and the Auth object.