Skip to content

Request Method Customization in Custom Detector #4134

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
effortlessdevsec opened this issue May 11, 2025 · 2 comments
Open

Request Method Customization in Custom Detector #4134

effortlessdevsec opened this issue May 11, 2025 · 2 comments

Comments

@effortlessdevsec
Copy link

Currently, TruffleHog custom detectors do not support customization of the HTTP request method (e.g., GET, POST, PUT, DELETE) used during outbound validation. This limits compatibility with certain APIs that require specific request methods for validation or scanning workflows.

Preferred Solution

Add support for specifying the HTTP method in the custom detector configuration. For example:

custom_detector:
  name: MyDetector
  request:
    method: POST
    url: https://api.example.com/validate
    headers:
      Authorization: Bearer {{API_KEY}}
    body:
      key: "{{secret}}"

If the method field is omitted, it should default to GET to preserve backward compatibility. TruffleHog should then use the specified HTTP method when calling the external service.

Additional Context

Many API providers (e.g., AWS STS, Vault, or custom internal tools) require specific HTTP methods (often POST or PUT) to validate secrets or tokens. Without support for method customization, these integrations cannot be fully utilized with TruffleHog's custom detectors.

TruffleHog Custom Detector Documentation

@kashifkhan0771
Copy link
Contributor

Thank you for opening this issue, @effortlessdevsec. I’ll discuss it with the internal team and get back to you.

@nabeelalam
Copy link
Contributor

Hey @effortlessdevsec. Thanks for opening up the discussion.

The ability to specify the HTTP method along with the endpoint (and other customizations) is actually under consideration by the team, although we don't currently have a timeline for it.

In the meantime, if you need this functionality right away, have you considered using a custom verification server in order to achieve what you're describing?

Happy to help if you'd like further guidance on setting it up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants