🎯 Recommended Merge Targets

Based on JIRA ticket TT-17585: [Innersource] Create custom key API doesn't respect default minimum token length

Fix Version: Tyk 5.8.15

Required:

• release-5.8.15 - Exact version branch for Tyk 5.8.15 - specific patch release
• release-5.8 - Minor version branch for 5.8.x patches - required for creating Tyk 5.8.15
• master - Main development branch - ensures fix is in all future releases

Fix Version: Tyk 5.13.1

Required:

• release-5.13.1 - Exact version branch for Tyk 5.13.1 - specific patch release
• release-5.13 - Minor version branch for 5.13.x patches - required for creating Tyk 5.13.1
• master - Main development branch - ensures fix is in all future releases

Fix Version: Tyk 5.14.0

Required:

• release-5.14.0 - Exact version branch for Tyk 5.14.0 - specific patch release
• master - Main development branch - ensures fix is in all future releases

Recommended:

• release-5.14 - Minor version branch for 5.14.x releases

📋 Workflow

1. Merge this PR to master first

2. Cherry-pick to release branches by commenting on the merged PR:

   • /release to release-5.8.15
   • /release to release-5.8
   • /release to release-5.13.1
   • /release to release-5.13
   • /release to release-5.14.0
   • /release to release-5.14

3. Automated backport - The bot will automatically create backport PRs to the specified release branches

This pull request addresses a bug where the gateway would accept custom API keys shorter than the default minimum length of 3 characters during creation, only for them to be unusable at authentication time. The fix introduces a consistent validation floor of 3 characters for token length at both creation and authentication, preventing the creation of invalid keys.

Files Changed Analysis

The changes are localized to three files within the gateway component:

• gateway/middleware.go: Introduces a new constant defaultMinTokenLength and a helper function effectiveMinTokenLength. This function centralizes the logic for determining the minimum token length, returning the configured value or the default of 3 if unset. The existing authentication logic in CheckSessionAndIdentityForValidKey is refactored to use this new helper, maintaining its behavior while improving code clarity.
• gateway/api.go: The key creation handler handleAddOrUpdate is updated to use effectiveMinTokenLength. This enforces the minimum length check when custom keys are created, aligning its validation logic with the authentication middleware.
• gateway/api_test.go: A new test, TestKeyHandler_DefaultMinTokenLengthFloorOnCreate, is added to verify the fix. It confirms that creating a key with an ID shorter than 3 is rejected, while an ID of length 3 is accepted when min_token_length is not configured.

Architecture & Impact Assessment

• What this PR accomplishes: It resolves an inconsistency in API key validation by ensuring the default minimum token length is enforced at key creation time, not just at authentication time. This prevents users from creating keys that are silently rejected during use.

• Key technical changes introduced:

  • Centralization of the minimum token length logic into a single function, effectiveMinTokenLength.
  • Application of this unified logic to both the key creation endpoint and the authentication middleware.

• Affected system components:

  • Gateway API Key Creation: The POST /tyk/keys/{key} endpoint now rejects custom key IDs shorter than 3 characters by default.
  • Gateway Authentication Middleware: The logic is refactored for consistency, but the effective authentication behavior is unchanged.

Validation Flow

The following diagram illustrates how the new shared function ensures consistent validation across both key creation and authentication.

graph TD
    subgraph "Shared Logic (middleware.go)"
        A[effectiveMinTokenLength] --> B{Is min_token_length configured?};
        B -- No (is 0) --> C[Return default: 3];
        B -- Yes --> D[Return configured value];
    end

    subgraph "Key Creation (api.go)"
        E[POST /tyk/keys/{custom_id}] --> F[handleAddOrUpdate];
        F --> G[Call effectiveMinTokenLength];
        G --> H{Is len(custom_id) < result?};
        H -- Yes --> I["Reject (400 Bad Request)"];
        H -- No --> J[Create Key];
    end

    subgraph "Key Authentication (middleware.go)"
        K[API Request with token] --> L[CheckSessionAndIdentityForValidKey];
        L --> M[Call effectiveMinTokenLength];
        M --> N{Is len(token) < result?};
        N -- Yes --> O["Reject (401/403)"];
        N -- No --> P[Continue Auth];
    end

Scope Discovery & Context Expansion

The impact of this change is confined to the gateway's API key management functionality.

• Creation Scope: The change affects the KeyHandler in gateway/api.go, which serves the /tyk/keys/ and /tyk/hashed-keys/ endpoints. Any client, including the Tyk Dashboard or automated scripts, that uses these Gateway Admin API endpoints to create keys will now be subject to this stricter validation.

• Authentication Scope: The refactoring touches CheckSessionAndIdentityForValidKey, a core function called by all token-based authentication middleware in the gateway. While the behavior here is unchanged, the centralization of logic reduces the risk of future configuration drift between the creation and authentication paths.

Powered by Visor from Probelabs

Last updated: 2026-06-25T13:35:44.154Z | Triggered by: pr_updated | Commit: 4c50912

💡 TIP: You can chat with Visor using /visor ask <your question>

✅ Security Check Passed

No security issues found – changes LGTM.

✅ Security Check Passed

No security issues found – changes LGTM.

✅ Architecture Check Passed

No architecture issues found – changes LGTM.

✅ Performance Check Passed

No performance issues found – changes LGTM.

Powered by Visor from Probelabs

Last updated: 2026-06-25T13:35:31.850Z | Triggered by: pr_updated | Commit: 4c50912

💡 TIP: You can chat with Visor using /visor ask <your question>

SentinelOne CNS Hardcoded Secret Detector
✅ Congratulations, your code is safe

SentinelOne CNS is a cloud-agnostic, agentless CSPM & CWPP solution that continuously detects and prevents vulnerabilities that have the highest probability of being exploited in Azure, AWS, Google Cloud, and Kubernetes.

🚨 Jira Linter Failed

Commit: 4c50912
Failed at: 2026-06-25 13:34:33 UTC

The Jira linter failed to validate your PR. Please check the error details below:

failed to get Jira issue: failed to fetch Jira issue TT-17585: Issue does not exist or you do not have permission to see it.: request failed. Please analyze the request body for more details. Status code: 404

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

This comment will be automatically deleted once the linter passes.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud