Skip to content

Added GitLab OAuth Detector#4729

Open
shahzadhaider1 wants to merge 3 commits intotrufflesecurity:mainfrom
shahzadhaider1:INS-265-gitlab-oauth-detector
Open

Added GitLab OAuth Detector#4729
shahzadhaider1 wants to merge 3 commits intotrufflesecurity:mainfrom
shahzadhaider1:INS-265-gitlab-oauth-detector

Conversation

@shahzadhaider1
Copy link
Copy Markdown
Contributor

@shahzadhaider1 shahzadhaider1 commented Feb 4, 2026

Adds a new detector for GitLab OAuth application credentials (client_id + client_secret).

Credential Format

  • Client ID: 64 hex characters
  • Client Secret: gloas- prefix followed by 64 hex characters

Example:

client_id: 04fcf956cb6c5f4b106f3ed54a76eaf70e8c5d07a976ecf3baff9ac778549ae5
client_secret: gloas-8406980541370e5bd4f04c5da232c2cdabe7fa3959eb1757eeef7299e2874258

Additional Notes

  • Supports custom endpoints for self-hosted GitLab instances via EndpointCustomizer
  • Defaults to https://gitlab.com

Checklist:

  • Tests passing (make test-community)?
  • Lint passing (make lint this requires golangci-lint)?
image

Note

Medium Risk
Introduces a new detector with network-based verification logic and a protobuf enum change, which can affect scan behavior/performance and downstream consumers relying on detector type IDs.

Overview
Adds a new gitlaboauth2 detector that identifies GitLab OAuth application credentials by pairing a context-prefixed 64-hex client_id with a gloas- 64-hex client_secret, and optionally verifies them via a POST to /<endpoint>/oauth/token (with custom/self-hosted endpoints supported).

Registers the detector in defaults and adds a new protobuf enum value DetectorType_GitLabOauth2 plus unit/integration tests and benchmarks covering matching behavior and verification error handling.

Written by Cursor Bugbot for commit 7001aca. This will update automatically on new commits. Configure here.

@shahzadhaider1 shahzadhaider1 requested a review from a team February 4, 2026 17:04
@shahzadhaider1 shahzadhaider1 requested review from a team as code owners February 4, 2026 17:04
@shahzadhaider1 shahzadhaider1 linked an issue Feb 4, 2026 that may be closed by this pull request

for clientId := range uniqueIdMatches {
for clientSecret := range uniqueSecretMatches {
for _, endpoint := range s.Endpoints() {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should keep the endpoints loop at the top level.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any specific reason why? I just followed the pattern in the existing GitLab detectors

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't change anything but I have to agree it would feel more natural 😀

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, I'd prefer to keep consistency with existing GitLab detectors. What do you guys think?

//
// Note: Apps with `api` scope may return 422, which we treat as unverified (not verified or invalid)
// to avoid false positives.
switch res.StatusCode {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No 200 OK or success code handling?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This API never returns 200, even for valid credentials, and I also couldn't find an official documentation where all the possible status codes are listed for this API, so I went with what I experienced during testing. Feel free to let me know if you think we need to add 200 for additional safety

What Claude said: "You're using grant_type=client_credentials, which GitLab doesn't support for OAuth apps. So even with valid credentials, you'll never get 200 — only 400 with invalid_scope."

@shahzadhaider1 shahzadhaider1 force-pushed the INS-265-gitlab-oauth-detector branch from b1daae3 to 48f063b Compare February 25, 2026 12:29
Copy link
Copy Markdown

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 2 potential issues.

Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.

@shahzadhaider1 shahzadhaider1 force-pushed the INS-265-gitlab-oauth-detector branch from ee28670 to eb1df56 Compare March 9, 2026 16:26
@shahzadhaider1 shahzadhaider1 force-pushed the INS-265-gitlab-oauth-detector branch from eb1df56 to 11d3127 Compare March 18, 2026 16:51
s1.SetVerificationError(verificationErr, clientSecret)

if s1.Verified {
// if secret is verified with one endpoint, break the loop to continue to next secret
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If one client_id + secret combination is verified with one endpoint, is it possible it can be verified with another secret? If not, we should skip that pair fully and move to next client_id.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually client_id + secret combinations are unique and if we found the verified one, we should not try to match same client_id with remaining secrets.

@shahzadhaider1 shahzadhaider1 force-pushed the INS-265-gitlab-oauth-detector branch from 03e1d44 to 7001aca Compare April 1, 2026 09:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add support for Gitlab OAuth Application Token

3 participants