fix: preserve semicolon-separated query parameters in proxy requests

[Flgado]

Problem

Oathkeeper drops query parameters that use semicolon separators (e.g., ?param1=value1;param2=value2) when proxying requests to upstream services. This occurs because Go's httputil.ReverseProxy calls `cleanQueryParams(), which removes semicolon separators as they are considered invalid per RFC 3986.

This breaks compatibility with:

• Legacy(or not) systems that rely on semicolon-separated parameters
• Applications using semicolons for structured parameter encoding
• APIs that expect semicolon separators for specific functionality

Root Cause

The issue originates in Go's standard library net/http/httputil.ReverseProxy.cleanQueryParams() function, which intentionally removes semicolon separators to enforce RFC 3986 compliance. While technically correct, this breaks transparent proxy behavior expected from an identity proxy like Oathkeeper.

Solution

Preserve the original query string by setting `r.Out.URL.RawQuery = r.In.URL.RawQuery after Go's URL processing but before forwarding the request. This follows the pattern documented in Go's httputil.ReverseProxy.Rewrite function documentation for transparent proxies.

Security Considerations

⚠️ Important Security Notice

As noted in Go's httputil.ReverseProxy documentation, preserving RawQuery "can lead to security issues if the proxy's interpretation of query parameters does not match that of the downstream server."

Potential risks:

• Parameter parsing differences between Oathkeeper and backend services could be exploited
• Malformed or malicious parameters might be interpreted differently by proxy vs. backend
• URL parsing inconsistencies could potentially bypass security controls

Mitigation:
Backend services should implement proper query parameter validation and sanitization
Operators should monitor for unusual query parameter patterns
Consider implementing additional query parameter filtering if required by your security policy

I believe this is is an inherent trade-off when operating as a transparent proxy: RFC compliance vs. real-world compatibility. The fix prioritizes transparency while requiring operators to ensure backend security.

Related issue(s)

#1248

Checklist

• I have read the contributing guidelines.
• [X ] I have referenced an issue containing the design document if my change
  introduces a new feature.
• I am following the
  contributing code guidelines.
• I have read the security policy.
• I confirm that this pull request does not address a security
  vulnerability. If this pull request addresses a security vulnerability, I
  confirm that I got the approval (please contact
  security@ory.sh) from the maintainers to push
  the changes.
• I have added tests that prove my fix is effective or that my feature
  works.
• I have added or changed the documentation.

Further Comments

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}