<details><summary>Original Issue</summary> <!-- Triage of infradev Issues is desired to occur asynchronously. For maximum efficiency, please ensure the following, so that your infradev issues can gain maximum traction. https://about.gitlab.com/handbook/engineering/workflow/#a-guide-to-creating-effective-infradev-issues --> ## Summary 1. Some messages are logging the `request.fullpath` and hence not doing any filtering 1. `PRIVATE-TOKEN` is not filtered ## Impact Customer `glpat-` are exposed in Kibana logs ## Recommendation 1. Use `request.filtered_path` when logging. 2. Add `PRIVATE-TOKEN` to filter parameter list. The known logs are `Rack_Attack` and `Application_Rate_Limiter_Request` - https://log.gprd.gitlab.net/app/r/s/cBdJa - https://log.gprd.gitlab.net/app/r/s/CKRY1 Probable places in code : - `app/controllers/application_controller.rb` - `lib/gitlab/middleware/path_traversal_check.rb` - `lib/gitlab/middleware/go.rb` - `lib/gitlab/application_rate_limiter.rb` - `lib/gitlab/auth.rb` - `app/controllers/concerns/invisible_captcha_on_signup.rb` ## Verification <!-- Provide a method for validating that the original issue still exists. Having a way of checking validity can save on a great deal of back-and-forth discussion between Infradev Triage participants including Engineering Managers, Directors and Product Managers and make space for other non-resolved issues to get scheduled sooner. Ideally, provide a link to a PromQL query or an ELK query and clear instructions on how to interpret the results to determine whether the problem is still occurring. --> Check Kibana logs for `json.path: glpat` <!-- Workflow and other relevant labels /label ~"severity::" /label ~"priority::" /label ~"group::" /label ~"devops::" See also: - https://about.gitlab.com/handbook/engineering/quality/issue-triage/#availability - https://about.gitlab.com/handbook/product/categories/ - https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml --> </details> ## Summary Some log messages include `request.fullpath` without applying filters, resulting in sensitive information being logged. Specifically, `PRIVATE-TOKEN` values, such as `glpat-` tokens, are visible in Kibana logs without filtering. ## Steps to Reproduce 1. Trigger a log entry containing a `glpat-` token. See this [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/489459#note_2111140889) 2. Check the logs in Kibana for unfiltered entries where the `PRIVATE-TOKEN` appears ## What is the Current Bug Behaviour? Logs capture and expose sensitive tokens (e.g., `glpat-` tokens) in plain text within Kibana logs. ## What is the Expected Correct Behaviour? Logs should filter sensitive information, ensuring `PRIVATE-TOKEN` values are not displayed in logs. ## Relevant Logs and/or Screenshots Example impacted logs: - [`Rack_Attack`](https://log.gprd.gitlab.net/app/r/s/cBdJa) - [`Application_Rate_Limiter_Request`](https://log.gprd.gitlab.net/app/r/s/CKRY1) ### Probable Code Locations - `app/controllers/application_controller.rb` - `lib/gitlab/middleware/path_traversal_check.rb` - `lib/gitlab/middleware/go.rb` - `lib/gitlab/application_rate_limiter.rb` - `lib/gitlab/auth.rb` - `app/controllers/concerns/invisible_captcha_on_signup.rb` ## Recommendation 1. Replace `request.fullpath` with `request.filtered_path` in logging 2. Add `PRIVATE-TOKEN` to the filter parameter list to prevent exposure in logs ## Verification Check the Kibana logs post-update to confirm that sensitive tokens, such as `glpat`, no longer appear unfiltered in log entries.