Repository navigation
fix(client): security hardening - #707
Conversation
Security hardening and input validation in request path building. Fixed path prefixes are passed one segment at a time; request URLs are unchanged.
🟡 Risk Classification: MINORApproval route: AI Review + Human Approval Classification reasons
Operational gates
Files analysed: 13 wall-e 2026.06.19-02 · policy |
🔬 Debug — why this classification?Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
Input validation of the request path on every HTTP operation; the resolved URL must stay under the base URI. Query parameters are always sent apart from the path, with new Type overloads for query.
The Type overloads of query are default methods. A base URI without a path resolves request paths under its root.
The event types version is sent as an encoded query on the same call as before, so no ApiClient overloads are added. The transport accepts only an already encoded query after the path.
🟡 Risk Classification: MINORApproval route: AI Review + Human Approval Classification reasons
Operational gates
Files analysed: 13 wall-e 2026.06.19-02 · policy |
🔬 Debug — why this classification?Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
|
Summary
Security hardening and input validation in request building.
Changes
src/main/java/com/checkout/AbstractClient.java:buildPathpercent-encodes each path parameter as one segment; input validation of path parameters (null, empty,.,..or invalid text raiseCheckoutArgumentException).src/main/java/com/checkout/ApacheHttpClientTransport.java: input validation of the request path and its query, and the resolved URL must stay under the configured base URI. A base URI without a path resolves under its root.src/main/java/com/checkout/events/previous/EventsClientImpl.java: the event typesversionis encoded.SepaClientImpl,BacsClientImpl,IssuingClientImpl,IdealClientImpl,InstrumentsClientImpl,PaymentSetupsClientImpl: refactoring, fixed path prefixes passed one segment at a time.EventTypesQuery.cs(new, internal): the event typesversionis now sent as a query filterthrough
ApiClient.Query, like the other query filters, instead of being appended to the pathby hand.
?version=1.0is unchanged on the wire.ApiClient.cs(LoggablePath): the request log line keeps the HTTP method and path, but leaves out the query string and masks path segments that hold an email address.Tests
./gradlew build: all unit and integration tests pass.AbstractClientBuildPathTestandApacheHttpClientTransportRequestUrlTest(every HTTP operation, sync and async, and file uploads); new cases inEventsClientImplTestandIdealClientImplTest.ApiClientLoggingTest.cs(new): the logged path has no query string and no email address, checked on the helper and on a realApiClientrequest.Related
None.
API Reference
None.
Breaking changes
None. No public or protected signature changes, and the
ApiClientcalls made by every client are the same as before. Path parameters that are null, empty,.,..or not valid text now raiseCheckoutArgumentExceptioninstead of sending a request. Request URLs are unchanged for the built-in environments; with a custom base URI that has a path, iDEAL requests now stay under that path like every other request.