shreemaan-abhishek opened a new pull request, #14146: URL: https://github.com/apache/apisix/pull/14146
### Description `oas-validator` declared `ssl_verify` with `default = false` and passed it straight to `httpc:request_uri` when fetching `spec_url`. lua-resty-http verifies when the field is absent, so this was an active downgrade rather than an inherited default, and the plugin never called `core.utils.check_tls_bool`, so operators got no warning either. `spec_url` is `pattern = [[^https?://]]`, so https is an expected value. With verification off, an on-path attacker (or one able to spoof DNS or BGP for the spec host) can present any certificate and: 1. receive the credential configured in `spec_url_request_headers`, and 2. serve a permissive OpenAPI document, which the gateway compiles and caches for `spec_url_ttl` seconds (3600 by default). Every control the plugin provides (path, query, header and body validation, `reject_if_not_match`, which defaults to true) is then defined by the attacker's document. Comparable outbound fetches in this repo already default to `true`: `forward-auth`, `opa`, `authz-keycloak`, `clickhouse-logger`, `lago`, `ai-rag` and others. This change: - defaults `ssl_verify` to `true` - calls `check_tls_bool` in `check_schema` so an explicit opt-out is logged - replaces the `conf.ssl_verify or false` coercions, in the fetch and in the validator cache key, with a nil-safe helper so an absent field verifies This changes behavior for existing configurations that relied on the old default and needs a release note. ### Tests New cases in `t/plugin/oas-validator3.t` (TEST 31-36) against an https server holding a certificate that is not in the trust store: the default config fails the fetch and the route returns 500, `ssl_verify: false` still fetches and validates, and the opt-out warning is asserted. ``` prove -I. t/plugin/oas-validator3.t # 127 tests, PASS luacheck apisix/plugins/oas-validator.lua ``` Reverting the schema default to `false` makes TEST 31 and TEST 34 fail (the untrusted fetch returns 200), so the new coverage is not vacuous. ### Checklist - [x] I have explained **WHY** we need this PR and **HOW** the problem it solves - [x] The title of the PR concisely describes the code modification and complies with APISIX specifications. - [x] I have explained the changes or the new features added to this PR - [x] I have added **e2e test cases** corresponding to this change - [x] I have updated the documentation -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
