Bumping version of httparty to ensure protection from CVE-2025-68696 (2nd approach)

[michelgoldstein]

Purpose

• https://nvd.nist.gov/vuln/detail/CVE-2025-68696
• In order to ensure that our clients will not accidentally pick a vulnerable version of httparty, we bump the minimum version of the library dependency to 0.23.3 (> 0.23.2 as defined in the CVE)
• It also required increasing the minimum Ruby version to 2.7.0

Summary

• Part of the fix to the vulnerability was to prevent overriding the base URL. Unfortunately we use that feature in our code to point some APIs to api.siftscience.com and others to api3.siftscience.com. Therefore it required a little bit more work to define multiple instances with different base URLs instead of a single one.
• This is different from the first approach to handle the ability to more directly modify the instance of HTTParty and change other parameters, like loggers. The initial approach would hide the underlying instances forcing us to control the exposed parameters (like timeout).
• This is still not exactly the same behavior as before as the dynamic creation happens once and is cached, which means that if parameters are overridden later, they will not propagate to the subclasses. The assumption here is that this is not an important use case as usually those overrides are set on initialization (to handle logging and timeouts).
• Includes some other small bug fixes around overriding API versions

Testing

• Ran unit tests, also included some new unit tests to highlight the bug fixes and the different ways to use the client and propagate configuration.
• Ran integration tests against test account

Checklist

• The change was thoroughly tested manually
• The change was covered with unit tests
• The change was tested with real API calls
• Necessary changes were made in the integration tests (if applicable) - N/A
• New functionality is reflected in README - (just minimum Ruby version)