API7 Gateway 3.10.5: Make Every Control Identity-Bound

Key Takeaways

• Multi-tenant API security depends on binding every configuration read, metric, status update, and portal view to an authenticated identity and its authorized scope.
• API7 Gateway 3.10.5, released on August 11, 2026, tightens gateway-group isolation across configuration, metrics, and service-registry state.
• Control Plane input is safer when sort parameters are allowlisted, custom plugin schemas run in a restricted parser, and generated deployment credentials use temporary files with restrictive permissions.
• OpenID Connect gains opt-in Pushed Authorization Requests (PAR) and DPoP, while LDAP Auth Advanced maps directory identities to gateway consumers.
• Developer Portal fixes align decoded paths, application ownership, two-factor enforcement, and outbound SSRF policy with the authority used to approve a request.
• The release has upgrade-visible changes: Alibaba Cloud Logging (SLS) verifies TLS certificates by default, Loki Logger headers gain at-rest encryption, and existing Dashboard sessions are invalidated once.

An API platform may authenticate every request and still make an authorization mistake. The failure often happens after authentication: a tenant identifier is taken from a payload, a metrics label is trusted instead of derived from the connection, a path is checked before it is decoded, or an uploaded extension is parsed with more privileges than its schema needs.

Those are context failures. The credential can be valid, the payload can be well-formed, and the requested operation can exist, yet the platform may apply the decision to the wrong tenant, gateway group, application, path, or process boundary.

API7 Gateway 3.10.5 addresses that class of problem across the Control Plane, Data Plane, Developer Portal, and identity plugins. Its most important security story is not a single new feature. It is a repeated design principle: derive authority from the authenticated channel, constrain every input before it changes privileged behavior, and keep the same boundary from request entry to stored state.

That principle is especially important for enterprise API management. A gateway platform sits between many teams and environments, so a small mismatch between identity and scope can become a cross-tenant exposure, a misleading operational signal, or a control-plane compromise.

flowchart LR
    request[Authenticated Request or Connection] --> identity[Verified Identity]
    identity --> scope[Authorized Tenant, Gateway Group, or Application]
    scope --> validate[Validate Path, Parameters, and Payload]
    validate --> action[Apply Configuration, Metrics, or Portal Action]
    action --> audit[Record Result in the Same Scope]

    untrusted[Untrusted Labels and Identifiers] -. never define authority .-> validate

Multi-Tenant Control Starts with the Authenticated Scope

In a shared API platform, identifiers appear everywhere. A Data Plane reports its gateway group, a portal user carries a developer ID, and a service registry update names the registry it belongs to. Those identifiers are useful for locating records, but they should not decide what the caller is allowed to reach. That decision must come from the credential and its server-side authorization context.

API7 Gateway 3.10.5 corrects several places where those two responsibilities could diverge. The etcd-compatible configuration endpoint used by Data Planes now rejects keys outside the authenticated caller's gateway-group namespace. A Data Plane can no longer use that channel to read, write, or delete another group's configuration merely by presenting a different key.

The same rule now applies to telemetry. When a Data Plane pushes metrics, the Control Plane derives gateway_group_id from the authenticated connection instead of trusting the label in the payload. Service-registry health and probe reports are also scoped to the reporting Data Plane's gateway group, rather than being applied by registry ID alone.

The Developer Portal follows the same pattern. API usage is now limited to applications owned by the caller. A developer identifier that happens to be identical in two portals is no longer enough to expose API product names or hourly call counts from the other portal.

These fixes demonstrate a practical zero-trust rule for API control planes: client-supplied identifiers may select a resource only inside the scope already established by authentication. They cannot expand that scope.

For operators, the lesson extends beyond the upgrade. When reviewing a custom integration, ask where its tenant or gateway-group context comes from. The safest answer is a verified credential, session, or mutually authenticated channel—not a request field that the caller can rewrite.

Privileged Inputs Need Smaller Execution Boundaries

Control planes accept inputs that ordinary data-plane requests never carry: plugin packages, query parameters, deployment manifests, certificates, and configuration objects. Validation therefore has to cover not only data types but also what parsing that input is allowed to do.

The custom-plugin upload path illustrates the distinction. API7 Gateway can now distribute a complete custom plugin package, including its entry file, dependencies, and metadata, as one unit. At the same time, 3.10.5 hardens the schema parser used during upload. The parser runs with only the libraries needed to read a declarative schema and rejects files that exceed a three-second execution budget. A schema check should describe configuration; it should not become a general-purpose program running on the Control Plane host.

List endpoints receive a similar boundary. order_by and direction values are now validated before SQL is generated. Unsupported values return HTTP 400, while valid column sorting continues to work. This keeps user-selected presentation options from becoming fragments of a privileged database query.

Generated Helm installation scripts now create Data Plane private keys, certificates, and CA files with umask 077, use temporary names, and delete the files when the script exits. On the traffic path, control characters in a rewritten upstream URI are percent-encoded instead of being copied into the upstream request line, preventing them from truncating the line and injecting headers.

The common pattern is bounded interpretation: treat a schema as a schema, a sort key as one value from an allowlist, a secret file as short-lived private material, and a URI as data that cannot introduce a new request-line boundary.

Identity Proof Should Survive Redirects and Token Theft

Identity-bound control is also about preserving proof across an authentication flow. API7 Gateway 3.10.5 adds three capabilities for organizations that connect gateway traffic to enterprise identity systems.

The OpenID Connect plugin gains opt-in support for Pushed Authorization Requests (PAR, RFC 9126). With par.enabled, the gateway sends the authorization parameters to the identity provider over a back channel and redirects the browser with a request_uri. Sensitive or security-relevant authorization parameters no longer need to travel through the user agent where they can be exposed or modified.

The same plugin adds opt-in DPoP sender-constrained tokens (RFC 9449). With dpop.enabled, the gateway uses a key pair to prove possession during the token request. The issued token is bound to that key, reducing the value of a token copied and replayed from another client. When PAR and DPoP are both enabled, the key thumbprint is included on the pushed request as required by the specification.

The new LDAP Auth Advanced plugin takes a complementary path for directory-backed identities. It searches the configured base_dn for the supplied user attribute, binds as the resolved entry, and can map that directory identity to a gateway consumer through the recorded user_dn. Consumer-level plugins, rate limits, and analytics can then apply to LDAP-authenticated traffic like other consumer identities. LDAPS and StartTLS support certificate verification by default, and connections are pooled between requests.

These features are opt-in and require careful identity-provider configuration. They do not replace least-privilege scopes, token lifetime controls, or consumer policy. They strengthen the chain that connects the user or client to the identity on which gateway policy acts.

sequenceDiagram
    participant B as Browser or Client
    participant G as API7 Gateway
    participant I as Identity Provider
    participant U as Upstream Service

    B->>G: Request protected API
    G->>I: Push authorization request (PAR)
    I-->>G: request_uri
    G-->>B: Redirect with request_uri
    B->>I: Authenticate and authorize
    I-->>G: Authorization response
    G->>I: Token request with DPoP proof
    I-->>G: Sender-constrained token
    G->>U: Authorized request under gateway policy

Portal Security Must Use the Same Parsed Request

Proxies and access-control layers can disagree when they normalize a URL differently. A policy may approve one path while the backend receives another after percent-decoding. API7 Gateway 3.10.5 fixes this class of mismatch in the Developer Portal backend proxy by validating path segments after decoding. A decoded segment containing a path separator, query delimiter, fragment delimiter, or control character is rejected.

Two-factor authentication enforcement is narrower and more reliable as well. The sign-in exemption no longer covers the entire /api prefix; it is limited to the authentication endpoints that need it. If the portal cannot load the session while enforcing required 2FA, it blocks the request instead of continuing with an undefined result. Related fixes ensure the password dialog waits for account data before deciding whether a password is required and refreshes session state after 2FA is enabled.

Outbound trust is aligned too. The security.ssrf_protection setting, introduced for Control Plane connections, now applies to Developer Portal approval webhooks and dynamic client registration. When enabled, the portal uses the same restrictions against loopback, private, link-local, and carrier-grade NAT destinations, including hostnames that resolve to those addresses.

Together, these changes reduce policy gaps between the path that is checked, the session that is enforced, and the destination the portal is permitted to contact.

Secure Defaults Can Change Upgrade Behavior

Some security improvements are intentionally visible during an upgrade. The Alibaba Cloud Logging (SLS) plugin now verifies the log server's TLS certificate by default through ssl_verify: true. Earlier versions established TLS without validating the certificate. After upgrading, a self-signed, private-CA, expired, or otherwise untrusted certificate causes the TLS handshake to fail and the batch processor to drop those log entries. Install the issuing CA in the Data Plane trust store before upgrading, or make an explicit, risk-reviewed decision to set ssl_verify: false temporarily.

When Data Plane encryption is enabled through apisix.data_encryption.enable, the Control Plane now encrypts Loki Logger headers at rest. During the normal Control Plane-first rolling upgrade, a 3.10.5 Control Plane can produce encrypted values that a 3.10.4 Data Plane cannot decrypt. Teams using Loki Logger headers should upgrade Data Planes promptly and avoid editing that plugin until both sides run 3.10.5.

Dashboard session cookies also move from a compile-time constant shared by every deployment to a random 32-byte key generated on first start and stored per deployment. Existing sessions were signed with the old value, so every signed-in Dashboard user must sign in again once after the Control Plane upgrade. No pre-upgrade configuration is required; the sign-out is the expected security consequence.

Finally, Docker Compose deployments now default to the radixtree_host_uri router, aligning them with Helm deployments. Plain host and path matching is unaffected, but overlapping host-specific and host-less routes can resolve differently. Teams that need the prior behavior can explicitly configure radixtree_uri, but should first test whether the old result represents the routing policy they intend to keep.

What to Validate Before Upgrading

Use the rolling upgrade guide together with the 3.10.5 release notes, and validate the boundaries that apply to your deployment:

1. Inventory Alibaba Cloud Logging (SLS) endpoints, verify their certificate chains from a Data Plane, and install private issuing CAs before rollout.
2. Find Loki Logger configurations that use headers; preserve the Control Plane-first order, shorten the mixed-version window, and avoid edits until every Data Plane reaches 3.10.5.
3. Notify Dashboard users about the one-time sign-in and confirm that the per-deployment session key persists across Control Plane restarts and replicas.
4. Compare Docker Compose route resolution under radixtree_host_uri, especially where host-specific and host-less routes share overlapping paths.
5. Test Data Plane configuration, metrics, and service-registry reporting with multiple gateway groups and confirm that cross-group identifiers are rejected or ignored.
6. Exercise Developer Portal encoded-path cases, application usage visibility, required 2FA, webhooks, and dynamic client registration in a staging environment.
7. Review every custom plugin package and verify that its schema remains declarative and completes within the parser budget.
8. Enable PAR, DPoP, or LDAP Auth Advanced only after validating identity-provider compatibility, certificate trust, consumer mapping, failure behavior, and rollback.

Make Authority Explicit at Every Boundary

API Gateway security is not only about authenticating the first request. It is about carrying verified authority through configuration namespaces, operational data, URL parsing, extension loading, identity exchange, portal actions, and upgrade transitions.

API7 Gateway 3.10.5 makes those relationships more explicit. Gateway-group scope comes from authenticated connections. Portal data comes from application ownership. Privileged parsers receive less capability. OAuth tokens can be tied to a key. Secure transport and encrypted configuration fail visibly when trust or version requirements are not met.

That gives platform teams a clear adoption model: map every sensitive action to the identity that authorizes it, validate the exact representation the downstream component will use, and test failure paths across tenant and version boundaries. Read the complete API7 Gateway 3.10.5 release notes, then turn each applicable change into a staging assertion before the production rollout.