Improve Detectors Verification Logic and Error handling

[kashifkhan0771]

Please review the Community Note before submitting

Description

Many TruffleHog detectors currently lack robust error handling in their verification logic. A common pattern observed is:

if err == nil {
    defer res.Body.Close()
    if res.StatusCode >= 200 && res.StatusCode < 300 {
        s1.Verified = true
    }
}

This approach has several shortcomings:

• It silently ignores errors, making debugging difficult.
• It doesn't handle non-success status codes like 401 Unauthorized or 403 Forbidden, which are critical for correctly assessing whether a secret is invalid.
• It fails to return meaningful verification errors or reasons for failure.

Improving this by explicitly handling all error cases and status codes will lead to more reliable and informative verifications.

Preferred Solution

A straightforward solution is to update the verification logic to explicitly handle all possible errors. This includes setting a verification error in the result when any error occurs and properly handling unauthorized status codes such as 401 and 403. Be sure to test the API locally to confirm that the errors you're handling in code match the actual responses returned by the API.

Additional Context

Feel free to choose any detector that requires this refactoring. When submitting a PR, avoid linking the issue directly to prevent the issue from being closed upon merge. Instead, mention the issue in the PR description to help track all related contributions.

References

You can refer to following PR's for guidance:

• Added support for indeterminate verification for letter B detectors #4049
• (fix) Indeterminate verification issue in Clickup detector #4047
• Okta Detector - Added Check for Indeterminate Verification Results #4045
• Bitly Detector - Added support for indeterminate verification #4031

Use these as a reference to refactor any detector that requires improved error handling.

[kashifkhan0771]

Pull Request to add support for indeterminate verification for letter Z detectors

[patidartanay]

I would like to work on it @kashifkhan0771 can you assign it to me?

[kashifkhan0771]

Hello @patidartanay thank you for your interest!

This is quite a large change, and I’m not sure if you’re comfortable tackling all detectors at once. I’d recommend starting with a smaller subset. This will make it easier for you to implement and for us to review.

Feel free to open a PR even with improvements for just one detector, or up to around 30 at a time. Keeping PRs smaller will help speed up reviews and merging.

[patidartanay]

@kashifkhan0771 how do I test the API locally to confirm that the errors you're handling in code match the actual responses returned by the API.

[kashifkhan0771]

@kashifkhan0771 how do I test the API locally to confirm that the errors you're handling in code match the actual responses returned by the API.

You can create an account for the service, generate its token, and test the API using cURL or any API client (such as Postman or Insomnia). This will help you observe the responses for both valid and invalid cases, allowing you to handle them appropriately in code.