Skip to content

Security

This document outlines known security considerations and planned enhancements for Pulse MQTT. We believe in transparency and want users to make informed decisions when implementing MQTT in production environments.

Current Status

Pulse is actively maintained and used in production at Zomato. While the library provides robust connection management and messaging capabilities, there are security enhancements planned for future releases.

Planned Security Enhancements

The following security features are currently not implemented but are planned for future versions. We recommend evaluating these considerations based on your security requirements.

1. SSL/TLS Certificate Validation

Status: ⚠️ Not Currently Implemented

Issue:

The library currently does not provide comprehensive SSL/TLS certificate validation configuration. The connection setup accepts the default certificate validation behavior, which may include:

  • Self-signed certificates
  • Expired certificates
  • Certificates with hostname mismatches

Security Impact:

This behavior could potentially allow Man-in-the-Middle (MITM) attacks when using secure protocols (wss:// or ssl:// connections). An attacker could intercept encrypted traffic by presenting a fraudulent certificate.

2. Resource Limits and DoS Protection

Status: ⚠️ Not Currently Implemented

Issue:

The library currently does not enforce limits on:

  • Maximum number of subscriptions - No upper bound on how many topics can be subscribed simultaneously
  • Pending command queue size - No limit on the number of queued commands awaiting execution

Security Impact:

Without these limits, applications could be vulnerable to:

  • Memory exhaustion from excessive subscriptions
  • Resource starvation from unbounded command queues
  • Denial of Service (DoS) scenarios in multi-tenant environments

3. Type-Safe Deserialization

Status: ⚠️ Partial Implementation

Issue:

Message deserialization in MqttMessageTypeManager.kt uses GSON's fromJson() without explicit type token verification. While basic error handling exists, this approach has limitations:

  • No validation of nested generic types at runtime
  • Potential for type confusion with polymorphic payloads
  • Limited protection against malicious payloads crafted to exploit type system

Security Impact:

In certain scenarios, this could lead to:

  • Type confusion vulnerabilities if malicious payloads are crafted to match expected structure
  • Unexpected runtime behavior from improperly typed nested objects
  • Deserialization attacks if custom serializers are used without validation

Acknowledgments

We appreciate the community's feedback and contributions toward making Pulse MQTT more secure. If you have suggestions for security improvements, please reach out through our contribution guidelines.