How KrakenD Solves API Gateway Security Vulnerabilities

API Gateways are a prime target for attackers, as highlighted by a recent Trend Micro study on API security vulnerabilities in gateways like APISIX and Kong. The research reveals alarming security gaps, including exposed admin panels, default credentials, unsandboxed script execution, and logging practices that leak sensitive information—issues that lead to severe breaches like Remote Code Execution (RCE) and data exfiltration. These misconfigurations make it easy for attackers to infiltrate, exploit, and compromise entire infrastructures.

KrakenD was built to avoid these critical issues from the ground up, offering a secure-by-default architecture that eliminates the weaknesses found in other gateways. By locking down configuration settings, enforcing strict defaults, and removing exploitable features like admin panels, KrakenD ensures your API gateway is not an open invitation to attackers.

To understand the full extent of the vulnerabilities in other gateways, read the full Trend Micro report.

Let’s now break down how KrakenD stays ahead, addressing the common issues other gateways face and how its design is inherently more secure.

1. Smaller Attack Surface by Default

Many gateways leak sensitive details through common vulnerabilities such as exposed query strings, headers, and status codes, providing attackers with too much information to exploit.

• Query Strings and Headers Blocked by Default: KrakenD prevents the exposure of unnecessary query strings and headers that could serve as injection points for attackers. This significantly reduces the risk of attacks like SQL injection or header manipulation, adhering to the principles of a Zero Trust Architecture, which enforces strict access control and minimizes data exposure by default.
• Obfuscated Status Codes from Internal Services: KrakenD doesn’t leak detailed status codes from internal services. By obfuscating these codes, it further reduces the attack surface, giving attackers less insight into the inner workings of your system.
• Data Sanitization: KrakenD includes thorough data sanitization, preventing attacks like double encoding or multi-encoding. Double encoding, as explained in the OWASP guide on Double Encoding attacks, is a technique where attackers encode malicious payloads multiple times to bypass input filters. KrakenD’s sanitization ensures that double-encoded input is detected and blocked, effectively mitigating this risk and preventing attackers from manipulating data in dangerous ways.

2. Safe Defaults that Prevent Misconfiguration

Misconfigurations, such as exposed admin panels or the use of default passwords, are a frequent source of vulnerabilities in API gateways like APISIX and Kong. KrakenD avoids these issues by enforcing secure defaults and eliminating unnecessary complexity.

• Immutable Configuration: Once KrakenD is deployed, the configuration is locked and cannot be changed. This prevents runtime tampering, where attackers might modify settings to exploit vulnerabilities.
• No Admin Panels or Default Users: KrakenD avoids the need for admin panels or default users entirely, drastically reducing the risk of admin impersonation or brute force attacks. This is a huge advantage over other gateways that have exploitable default credentials or panels.
• Safe Default Configuration for Clients and Triggers: Whether it’s internal clients (HTTP, gRPC, WebSockets, pub/sub) or exposed pipe triggers (server HTTP, async agents), KrakenD comes with safe, preconfigured defaults that minimize potential security gaps.

3. Built-in Protections for Time-Based Attacks

Gateways that don’t enforce strict timeouts can be vulnerable to time-based attacks that exhaust resources by holding connections open indefinitely.

• Small Default Timeouts: KrakenD enforces short default timeouts for operations, connections, and other interactions, which minimizes the potential for time-based attacks like slowloris. This ensures that attackers can’t exhaust resources by keeping connections open too long.
• SQLi Blind Time-based Attacks: SQL Injection (SQLi) Blind Time-based Attacks are a type of SQL injection where attackers send SQL queries that cause a delay, indicating whether a specific payload is correct or not. This type of attack allows attackers to infer database structure without directly accessing the data. KrakenD’s small, configurable timeouts for every operation complicate the timing requirements of these attacks, making it significantly harder for attackers to exploit such vulnerabilities. Details on this type of attack are available in the OWASP article on Blind SQL Injection attacks.

4. Strong Identity and Authorization Management

Centralizing identity providers creates single points of failure (SPOFs) and introduces the risk of authorization breakdowns. KrakenD avoids this by using stateless, distributed identity validation.

• Stateless Identity Validation and Authorization: KrakenD employs stateless identity validation, using methods like OAuth2 and mTLS. This design avoids relying on a single identity provider, which could become a SPOF—a vulnerability in centralized systems like Kong.
• mTLS or OAuth2 Backend Identification: KrakenD can securely identify itself to backend services using mTLS or OAuth2 client credentials. This allows backend services to audit access and reject unauthorized requests, even from potentially compromised internal services.

5. Secure by Default: Cryptography and Logging

Poor cryptography or overly verbose logs can create security vulnerabilities by exposing sensitive information. KrakenD is designed to prevent these common issues.

• Secure TLS Versions and Cipher Suites: KrakenD uses secure TLS configurations with modern cipher suites, eliminating the risk of MITM attacks. Weak cryptography is simply not an option.
• No User Data in Logs by Default: Logs are a common place for sensitive information to leak. KrakenD prevents this by ensuring that no user data (such as API keys, payloads from requests or responses, or passwords) is included in logs by default, unlike other gateways which may require manual configuration to achieve this.
• Limited Information in Traces: KrakenD minimizes the amount of data sent in traces by default, ensuring that only essential information is logged. However, users can configure this level depending on their needs.

6. Complete Control: On-Premise and Local License Validation

For many organizations, trusting a cloud-based gateway vendor with sensitive traffic and logs is a non-starter. KrakenD provides full control over deployments with on-premise capabilities.

• On-Premise Deployment: KrakenD allows full on-premise deployment, ensuring that production traffic and logs never leave your infrastructure. This means you don’t need to place undue trust in a third-party vendor for securing your traffic.
• Local License Validation: KrakenD validates licenses locally, preventing any chance of a MITM attack on license validation processes, which could otherwise disrupt deployments or autoscaling.

7. Distributed Rate Limiting Without Bottlenecks

Rate limiting is crucial for managing API traffic, but centralized implementations can become bottlenecks or failure points. KrakenD’s distributed approach scales smoothly.

• Distributed Rate Limiting: KrakenD implements fully distributed rate limiting, which requires no central coordination. This allows for linear scalability and prevents the creation of a SPOF—a significant improvement over centralized rate limiting in gateways like Kong.
• Default Config Encourages Stateless Rate-Limiting: While KrakenD allows for centralized rate limiting if necessary, the system enforces and always encourages a stateless endpoint and cluster rate-limiting by default. KrakenD’s cluster rate limiting approach ensures that rate limiting is both scalable and resilient, allowing distributed rate limits across nodes without introducing centralized points of failure that could bottleneck performance, following the principles outlined in KrakenD’s Cluster Throttling documentation.

8. No Wildcard or Catch-All Exposures

Some gateways unintentionally expose too much by default, allowing attackers to discover internal services that should remain hidden. KrakenD avoids this issue entirely.

• No Wildcard or Catch-All by Default: KrakenD’s configuration doesn’t allow wildcard or catch-all routes by default. This ensures that only explicitly exposed endpoints are available, limiting what external attackers can discover or exploit.

9. Robust Logging and Debugging without Leaks

Debugging is essential in development, but exposing sensitive data during this process is risky, especially in production environments. KrakenD handles this cautiously.

• No Regular Debug Mode in Production: There’s no way for a debug mode to be accidentally enabled in production environments, which could otherwise leak sensitive information. KrakenD prevents this entirely.
• Configurable Log Levels: You can control the level of detail in KrakenD’s logs, ensuring that excessive logging doesn’t fill up disk space or cause node failures due to full disks.

10. Proactive Security Monitoring

To stay ahead of vulnerabilities, KrakenD implements continuous monitoring and scanning of its dependencies, ensuring that it is always secure.

• Monitored and Audited Dependency Chain: KrakenD automatically and periodically scans its dependencies for CVEs and known vulnerabilities. This ensures that no critical vulnerabilities go unnoticed and unpatched.

11. Isolated Request Processing and Secure Execution

Request isolation is critical to ensuring that one bad request doesn’t affect others, and that rule engines and script interpreters don’t introduce vulnerabilities.

• Isolated Request Processing: Each request in KrakenD is processed independently, so one request cannot interfere with another, maintaining overall system stability.
• Isolated VMs for Rule Engines and Script Interpreters: KrakenD separates rule execution into isolated virtual machines, ensuring that one execution can’t compromise the state of others. This adds an extra layer of protection against malicious or faulty scripts.

12. Backend Redirects Handled Securely

Backend redirects are a potential point of data leakage if not handled properly, but KrakenD takes the necessary precautions to secure this process.

• Backend Redirects Followed Internally: KrakenD processes backend redirects internally, which reduces the amount of information about internal services that could be leaked to external actors.
• Sensitive Data Blocked in External Redirects: KrakenD blocks sensitive information, such as cookies and authorization headers, from being passed if a backend redirect sends requests outside the original scope. This prevents data leakage during redirects.

13. Integration with Secret Management Services

Sensitive data like private keys (JWT signer) should never be stored in plain text in configuration files. KrakenD supports integration with secret management solutions to avoid this.

• Secret Management Integration: KrakenD can integrate with secret management services, ensuring that sensitive data is never stored locally in configurations or environment variables. KrakenD’s JWT validation process supports a variety of trusted providers for encrypting payloads, providing flexibility while ensuring secure storage and validation of sensitive tokens, ensuring no plain text secrets are exposed throughout cryptographic operations.

Conclusion

KrakenD doesn’t just outperform other gateways in terms of scalability—it outdoes them in security, too. With secure defaults, immutability, distributed rate limiting, and rigorous request isolation, KrakenD protects your API infrastructure against internal and external threats.

In addition, the KrakenD release life cycle has procedures with rules and automated systems that guarantee the security of the product, highlighting that security is paramount—even more critical than performance or functionality.