Add PayPal REST API secret detector and validator. Fixes #1027 - #1815

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@erikvarga ready for QA/QC

@erikvarga the lint-plugger failure is pre-existing from main and not related to the PayPal secret detector.

@erikvarga fixed the lint errors. This feature is ready for review. Thank you.

@another-rex @erikvarga PR is review-ready, lint-clean, all checks passing

@erikvarga PR is ready for review - related to #1027 (comment)

Hi @cybrdude

Thanks for the updates and the documentation. I left a couple more comments to reduce the risk of the detector reporting false positives.

Once those are resolved, the PR looks good on my side.

Thank you @alessandro-Doyensec ,

Added word boundaries (\bA… / \bE…), matching the structural + word-boundary approach used elsewhere (e.g. gcpoauth2client's \bGOCSPX-…). On requiring a context keyword before the value: I prototyped it, but it breaks velestest.AcceptDetector, which asserts the secret is reported at the start of the embedded example a leading keyword shifts the position by its length. No pair detector in the tree uses a preceding context token. Between the word boundary and the pair requirement (an A- and an E-prefixed token within 200 bytes)

Hi @cybrdude

Thanks again.

I prototyped it, but it breaks velestest.AcceptDetector, which asserts the secret is reported at the start of the embedded example a leading keyword shifts the position by its length

To solve this issue, it should be enough to report the position of the secret right at the start of the matched payload. So, for example:

• context_key=A392rn23r23rk32rm32

  The position here should be 0

• some header context_key=A392rn23r23rk32rm32

  The position here should be 12.

Hope I've been clear enough, feel free to ping me if you need more details.

@alessandro-Doyensec The detector now requires a PayPal/client-id (and client-secret) context keyword and reports the position at the start of the matched payload per your example (client_id=A… → 0; some header client_id=A… → the keyword offset). The credential stays capture group 1, so the reported secret value is clean. AcceptDetector's position cases pass, and I added a true-negative for a bare A…/E… pair with no keyword. Ready for another look.

Thanks @alessandro-Doyensec . Completed.

All five keys are recognized now. On your note that some were already caught: PAYPAL_CLIENT_ID and PAYPAL_CLIENT_SECRET were already matched via the generic client_id / client_secret groups; PAYPAL_ID, PAYPAL_SECRET, and PAYPAL_SECRETKEY were previously missed because the _ after PAYPAL fell outside the separator class, so the paypal branch never reached the value. The keyword groups are now:

• ID: (?i:paypal(?:[ _-]?client)?[ _-]?id|client[ _-]?id|paypal)
• Secret: (?i:paypal(?:[ _-]?client)?[ _-]?secret(?:[ _-]?key)?|client[ _-]?secret|paypal)

These also cover space/hyphen/underscore and no-separator variants and any case. The credential stays capture group 1, the A/E prefix stays case-sensitive, and the pair-within-200-bytes requirement is unchanged, so false-positive exposure does not widen. I added table tests for all five keys plus JSON and mixed-case shapes, and two negatives (an unrelated key on the secret side, and a bare SECRETKEY with no paypal/client keyword) to lock the anti-FP behavior. gofmt clean, tests green.

@alessandro-Doyensec validator.go now uses simplevalidate.Validator[Credentials] per your draft (Live+Sandbox in Endpoints, 200 is Valid / 401 is Invalid / else = Failed). I kept the original 10s timeout via HTTPC (same as squareapikey)

@alessandro-Doyensec , The UI lists that you only have read-only approve permissions. The restrictions indicate 'Merging is only allowed by At least 1 approving review is required by reviewers with write access.'

@erikvarga picking this back up.

Current status: approved by @alessandro-Doyensec on Jul 1, merge pending. main had moved, so I merged it in today as 2539ca5:

• binary/proto/scan_result.proto: main took field 92 in SecretData.secret for HTTPCookie http_cookie, so PayPalCredentials paypal_credentials moves from 92 to 93, the next free number (the message only reserves 3).
• binary/proto/scan_result_go_proto/scan_result.pb.go: regenerated from the merged proto with protoc 23.x and protoc-gen-go v1.36.11, the same versions the Go workflow installs, rather than hand-merged.

The branch builds, the proto, paypal, and list tests pass, and no conflicts remain. cla/google is green on the new head.

Asks:
The three workflow runs on 2539ca5 are sitting at "awaiting approval", so the required GitHub Actions Scan check cannot report until a maintainer approves them.

@alessandro-Doyensec @erikvarga is there anything else needed from my end?

@alessandro-Doyensec @erikvarga Merged with main again on Oct 25 (8ee4b70) and regenerated scan_result.pb.go with the repo's protoc / protoc-gen-go versions; the build and the paypal, binary/proto and list tests pass. Is anything else needed before this can merge?