API7 Gateway 3.10.7: Close the Trust Gaps From Client to Upstream

Key Takeaways

API security can fail between controls: a credential may be accepted too loosely, a duplicated header may change a policy decision, or an upstream certificate may not be verified as intended.
API7 Gateway 3.10.7, released on September 8, 2026, makes empty Basic Auth passwords fail closed and fixes denylist handling for duplicate User-Agent headers.
In API7 Enterprise 3.10.7, the new JWE Decrypt plugin authenticates a consumer from an encrypted token, then forwards the decrypted plaintext payload in a configured request header; it does not issue tokens.
TLS passthrough and gateway-terminated traffic are different trust models: one preserves encryption to the backend, while the other lets the gateway establish and verify an upstream TLS connection.
HTTPS and grpcs certificate checks now honor configured trust more accurately, so previously accepted certificate or hostname mistakes can become visible upgrade failures.
Chaitin WAF response reporting is useful for detection, but it happens after delivery and never blocks or changes the response.

Security controls are often reviewed one at a time. The identity team checks authentication, the platform team checks gateway policy, and the infrastructure team checks TLS. A production request, however, crosses all of those decisions in sequence.

That is where trust gaps appear. An empty credential can be treated as valid. A duplicated header can reach a parser branch that a single-header test never exercised. A gateway can be configured to verify an upstream certificate while the connection path silently ignores that setting. A response can be reported to a security service after delivery and be mistaken for something that could have blocked the leak.

API7 Gateway 3.10.7 provides a coherent security lesson across several changes: trust must be established for the exact request shape and exact transport path that production uses. The release strengthens that chain from client authentication to upstream TLS, while also making the limits of passthrough and advisory detection clearer.

Trust Breaks Between Controls, Not Only Inside Them

The first step is to separate two traffic models that are easy to blur.

For HTTP or gRPC traffic terminated at the gateway, API7 Gateway can authenticate the client, interpret request headers, apply Layer 7 policy, and then create a new TLS connection to the upstream. Each stage has its own trust decision.

For a stream listener configured with TLS passthrough, the gateway reads the Server Name Indication (SNI) from the ClientHello, selects a backend, and forwards the encrypted session without terminating it. That preserves encryption to the backend, but it is not an additional HTTP authentication or content-inspection stage.

flowchart LR
    client[Client] --> mode{Traffic mode}
    mode -->|HTTP or gRPC terminated at gateway| identity[Identity validation]
    identity --> headers[Request interpretation]
    headers --> tls[Configured upstream CA and hostname verification]
    tls --> upstream[Upstream]
    mode -->|TCP TLS passthrough| sni[SNI-based backend selection]
    sni --> upstream

The diagram is deliberately not a claim that every request receives every control. It shows why teams should test the path they actually configure instead of treating “the gateway” as one indivisible security boundary.

Reject Identity That Cannot Be Proved

Basic Auth illustrates how a small configuration value can change the meaning of an authentication boundary. Before 3.10.7, a consumer whose password was stored as an empty string—or resolved from an $env:// or $secret:// reference to an empty string—could authenticate with an empty password.

API7 Gateway 3.10.7 closes both sides of that gap:

The Control Plane rejects a consumer or credential configured with an empty password.
An existing empty-password consumer appears as an error in the compatibility report and cannot be edited successfully until the password is fixed.
The Data Plane rejects a credential when the configured value or resolved secret is empty, returning HTTP 401 and writing a warning to the error log.

The release also fixes passwords containing a colon. Basic Auth separates the username from the password at the first colon; everything after it belongs to the password. Earlier behavior split on every colon and truncated valid passwords.

These changes make a practical pre-upgrade inventory necessary. Search not only for literal empty values, but also for secret references whose current resolution is empty. Then test one password containing a colon so the canary environment exercises the corrected parser. The Basic Auth plugin documentation remains the configuration reference; the version-specific release notes define the 3.10.7 migration risk.

Treat JWE Decryption as a New Plaintext Boundary

Available in API7 Enterprise from version 3.10.7, the new JWE Decrypt plugin adds an authentication path for clients that send a JSON Web Encryption token. The plugin reads the token key ID to identify a consumer, uses that consumer's 32-byte secret, and supports direct key management with dir plus A256GCM content encryption.

Tokens with an unparseable structure or that cannot be decrypted are rejected; for standard tokens that include the protected header as AES-GCM additional authenticated data (AAD), protected-header tampering is also rejected. Legacy tokens without AAD remain accepted for compatibility and do not authenticate the protected header. Handling of a missing token is configurable. After a valid token is decrypted, the plugin forwards the plaintext to the upstream in a configurable request header.

That last step is the boundary to design around. Encryption protects the token before it reaches the gateway. Once the gateway decrypts it, the plaintext header becomes sensitive application data. Limit which upstream receives it, prevent request-header logging from recording it, and send it only over an authenticated, protected network path. Do not rely on an HTTPS scheme alone: enable upstream server certificate verification and supply the intended CA certificates, or use a validating proxy or service mesh. Do not reuse a generic header name that another proxy or application component may already trust for a different purpose.

The plugin does not create or issue JWE tokens. Token issuance, key distribution, rotation, and revocation remain external responsibilities. In 3.10.7, an explicit alg value other than dir or an explicit enc value other than A256GCM is rejected, but a token that omits either field is still accepted. For standard RFC 7516 tokens, the encoded protected header is authenticated as AES-GCM additional authenticated data (AAD), so changing it causes authenticated decryption to fail. Legacy tokens carrying no AAD remain accepted for compatibility; their protected header is not authenticated, so changing kid may remain valid when another consumer uses the same secret.

Use the JWE Decrypt plugin documentation for the current configuration flow. Its token-generation example describes the legacy five-part format without AAD; for API7 Enterprise 3.10.7, also test the standard RFC 7516/AAD form described above and verify which contract your producer uses. Test the complete producer-to-consumer contract: key ID, secret encoding, algorithm-field handling, protected-header AAD compatibility, missing-token behavior, output header, and upstream handling.

Test the Request Shape an Attacker Can Actually Send

Security tests often use the cleanest possible request: one header, one value, and one conventional encoding. Attackers benefit when production parsers encounter shapes the test suite never covered.

Before 3.10.7, a request with more than one User-Agent header could invert the UA Restriction denylist decision. A duplicated user agent that matched the denylist was allowed, while a duplicate that did not match could be rejected. A denied client could therefore get through by sending the same header twice.

Version 3.10.7 rejects the duplicate-header denylist match with HTTP 403. Requests with a single User-Agent header and the allowlist branch were not affected by this defect.

The important operational lesson is broader than one plugin: test repeated headers at the same layer where the gateway receives them. Some client libraries combine duplicate headers before transmission, and some load balancers normalize them before the gateway. A useful regression test therefore captures the request at the gateway edge and confirms both the received shape and the policy result.

Choose Where TLS Ends—and Test That Exact Model

API7 Gateway 3.10.7 strengthens two different transport models. They solve different problems and should not be described as one combined control.

On a dedicated passthrough TCP listener, set tls_passthrough: true and leave tls unset or false. The gateway reads SNI, chooses a backend, and forwards every accepted encrypted stream untouched, so TLS terminates at the backend. If both tls: true and tls_passthrough: true are enabled, the listener operates in mixed mode: the matched stream route determines whether each connection terminates at the gateway or passes through. Configure either listener model in gateway_conf/config.yaml for Docker Compose or the gateway Helm chart values for Kubernetes.

Passthrough is useful when the backend must own the certificate and the encrypted session. For a connection that is passed through, the gateway does not terminate or decrypt TLS, so do not expect HTTP authentication, request-header policy, or response-body inspection on that stream. Validate SNI routing, the backend certificate presented to the client, and behavior for missing or unexpected SNI values.

The second model applies when the gateway terminates client traffic and establishes an HTTPS or grpcs connection to the upstream. Several 3.10.7 fixes make the configured upstream trust policy take effect correctly:

An HTTPS upstream with certificate verification enabled that supplied a CA certificate without also supplying a client certificate previously failed because the trusted store was not applied. The configured CA can now validate that upstream.
A grpcs upstream previously ignored certificate verification settings and checked the wrong hostname. Verification, configured CA certificates, and the upstream host name now take effect.
Parsed CA stores are now keyed by the certificate set, preventing one upstream from being verified against another upstream's CA certificates.

The grpcs correction is intentionally upgrade-visible. If verification is enabled and the certificate does not chain to the configured CA, or its subject alternative names do not cover the upstream host, the connection now fails with HTTP 502 where it may previously have connected. A 502 accompanied by a certificate-chain or hostname verification error is evidence of a trust mismatch—not a reason to disable verification without investigation. Other upstream failures can also return 502, so use the related error log to identify the cause.

Separate Advisory Detection From Enforcement

API7 Gateway 3.10.7 can send response information from Chaitin WAF to the SafeLine detection service alongside the request. This can surface data leaked in a response body, exploit output, or an unexpected status code.

Response reporting is off by default. config.log_resp enables it, config.resp_body_size limits the reported body size in KB, and a value of 0 reports only the response status and headers. config.extra_ignored_content_types extends the built-in list of content types that should not be reported.

The timing defines the security boundary: the report is sent after the response has already been delivered to the client. It is advisory only and never blocks or modifies that response. Use it for detection, triage, and follow-up—not as a data-loss prevention claim.

Response capture also creates a data-handling responsibility. Start by reporting only the response status and headers or by using the smallest useful body limit, exclude sensitive content types, control access to SafeLine findings, and verify retention and redaction expectations before enabling it broadly.

Run a Staged Trust-Boundary Validation

Use the rolling upgrade guide together with the 3.10.7 release notes. A focused canary plan should include:

Basic Auth credentials: find literal and resolved empty passwords, replace them, test a colon-containing password, and confirm invalid credentials return HTTP 401.
JWE contract: test standard protected-header AAD and legacy no-AAD tokens, including protected-header tampering for the standard AAD path, plus missing, malformed, wrong-key, wrong-algorithm, and omitted-alg/enc cases; confirm the upstream receives plaintext only in the intended header over an authenticated, protected path.
Duplicate headers: send repeated User-Agent headers through the real edge path and confirm a denylist match returns HTTP 403.
HTTPS upstreams: test each custom CA bundle with and without client certificates as configured, and confirm failures identify the expected chain problem.
grpcs upstreams: verify the CA chain and subject alternative names against the exact upstream host before rollout; if a new HTTP 502 is accompanied by certificate-chain or hostname verification errors, diagnose the trust configuration while ruling out other upstream failures.
TLS passthrough listeners: confirm SNI routing, backend certificate presentation, and the absence of assumptions that require gateway-side plaintext inspection.
Chaitin WAF reporting: verify the body limit, ignored content types, access controls, and after-delivery timing; document that the signal cannot block the response.

Record the expected accept or reject result for every case. A security control is easier to operate when its failure mode is known before production traffic discovers it.

Trust Has to Survive the Whole Path

API Gateway security is not the sum of enabled plugins. It is the continuity of trust decisions from the first byte a client sends to the certificate an upstream presents.

API7 Gateway 3.10.7 closes several concrete gaps in that path. Empty Basic Auth passwords no longer become usable identities. JWE Decrypt establishes a defined encrypted-token contract and an explicit plaintext boundary. Duplicate User-Agent headers no longer reverse a denylist decision. TLS passthrough keeps termination at the backend, while gateway-originated HTTPS and grpcs connections apply configured CA and hostname checks more reliably. Advisory response reporting is clearly separated from enforcement.

Review the full API7 Gateway 3.10.7 release notes, map each change to the traffic path that uses it, and canary the exact request and certificate failures your production environment must reject.