fix: reject RestApiTool path params with '.' or '..' segments

[artemkulyk]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Closes: RestApiTool path parameters with '.' / '..' still reach the wire after quote(safe="") #7065

Problem:
RestApiTool percent-encodes path parameters with quote(value, safe="") and documents that this prevents a model-supplied value from steering the request onto an undeclared path. quote() never encodes ., so ../../admin/secret is sent as ..%2F..%2Fadmin%2Fsecret. Backends that decode %2F and then merge dot-segments can dispatch that request — with the tool's credentials — to a path the OpenAPI spec never declared.

Solution:
Reject a path parameter if any /- or \-separated segment is exactly . or .., then keep quote(safe=""). Slash-containing IDs such as foo/bar are still encoded as foo%2Fbar. Invalid values fail closed in call() as an {"error": ...} result; no HTTP request is sent.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

.venv/bin/pytest tests/unittests/tools/openapi_tool/openapi_spec_parser/test_rest_api_tool.py -q
76 passed

New coverage: _encode_path_param rejects ., .., ../../admin/v1/tenants, foo/../bar, ..\admin, ./x; still encodes foo/bar, ?/#, file..txt, .gitignore, ok.txt. call() with a traversal name returns an error and does not call _request.

Manual End-to-End (E2E) Tests:

OpenAPI spec GET /files/{name} against a local HTTP server:

• args={"name": "../../admin/secret"} → {"error": "... parent-directory segments."}, no wire request.
• args={"name": "ok.txt"} → GET /files/ok.txt succeeds.

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

Additional context

Google VRP 557701521 was closed as Infeasible (not tracked as a security bug) with a request to file this publicly. I have signed the Google CLA.

Made with Cursor

[google-cla]

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.