Security Overview

NATS Server is designed with security as a core principle, providing multiple layers of authentication, authorization, and encryption to protect your messaging infrastructure.

Security Audit

NATS has undergone professional security audits to ensure the highest standards of security:

A third-party security audit was performed by Trail of Bits following engagement by the Open Source Technology Improvement Fund (OSTIF). The full report from April 2025 is publicly available.

Threat Model

NATS Server security architecture addresses multiple threat vectors:

Network-Level Threats

Man-in-the-Middle Attacks: Mitigated through TLS encryption and certificate verification
Eavesdropping: Protected by mandatory TLS in production environments
Replay Attacks: Prevented through nonce-based authentication mechanisms

Authentication Threats

Unauthorized Access: Blocked through multiple authentication methods (NKeys, JWT, username/password)
Credential Theft: Minimized by using NKeys cryptographic authentication
Brute Force: Rate-limited through connection and authentication timeouts

Authorization Threats

Privilege Escalation: Prevented through account-based isolation
Data Exfiltration: Controlled via subject-level permissions
Cross-Account Access: Blocked through strict account boundaries

Zero-Trust Architecture

NATS implements a zero-trust security model:

Multi-Tenancy Isolation

Accounts provide complete isolation between tenants:

Messages published in one account cannot be received by another account
Subject namespaces are isolated per account
Resource limits are enforced per account

Least Privilege Access

Every connection operates with minimal required permissions:

Publish permissions control which subjects a client can send to
Subscribe permissions control which subjects a client can receive from
Deny rules override allow rules for additional security

Defense in Depth

Multiple security layers work together:

Network Layer: TLS encryption with optional mTLS
Authentication Layer: Multiple methods (NKeys, JWT, tokens)
Authorization Layer: Subject-level permissions
Account Layer: Complete tenant isolation

NKeys Cryptographic Authentication

NKeys provide the most secure authentication method using Ed25519 signatures:

What are NKeys?

NKeys are public-key cryptographic identities based on the Ed25519 signature scheme. They eliminate the need to transmit passwords over the network.

Key Types

User Keys: Identify individual clients
Account Keys: Identify accounts
Operator Keys: Sign account JWTs in operator mode
Server Keys: Identify NATS servers in clusters

Authentication Flow

Server sends a random nonce to the client
Client signs the nonce with its private key
Server verifies the signature using the client’s public key
No passwords are ever transmitted

Configuration Example

authorization {
  users = [
    {nkey: "UCKASD5KPQQYHB6KYD7RC62VZQN7VRU5NN2BKL7UFBQ3UBYAJQPVNHSQ"}
  ]
}

Never commit or share private NKeys. Store them securely and rotate them regularly.

Password Security

When using username/password authentication:

BCrypt Hashing

Always use bcrypt-hashed passwords in configuration files:

authorization {
  users = [
    {
      user: "admin"
      password: "$2a$11$W2zko4z4nZC5z6o7FPNbO.4qGOsQWiPCqQ3O0kJLKLQP5WtHLx4KW"
    }
  ]
}

Plaintext Warning

The server logs warnings when plaintext passwords are detected:

[WRN] Plaintext passwords detected, use nkeys or bcrypt

Generate bcrypt hashes using: nats server passwd

Security Best Practices

1. Always Use TLS in Production

tls {
  cert_file: "/path/to/server-cert.pem"
  key_file: "/path/to/server-key.pem"
  ca_file: "/path/to/ca.pem"
  verify: true
}

2. Prefer NKeys Over Passwords

NKeys provide superior security:

No password transmission
Cryptographic signatures
Resistance to replay attacks

3. Use Account Isolation

Separate tenants, environments, or services into different accounts:

accounts {
  PROD: {
    users: [{nkey: "PROD_USER_NKEY"}]
  }
  DEV: {
    users: [{nkey: "DEV_USER_NKEY"}]
  }
}

4. Implement Least Privilege

Grant only necessary permissions:

authorization {
  users = [
    {
      user: "publisher"
      password: "$2a$11$..."
      permissions: {
        publish: ["events.>"]
        subscribe: []
      }
    }
  ]
}

5. Enable Monitoring with Authentication

Protect monitoring endpoints:

http_port: 8222

# Restrict access to monitoring port via firewall
# or use reverse proxy with authentication

6. Rotate Credentials Regularly

Rotate TLS certificates before expiration
Rotate NKeys and JWTs periodically
Use short-lived JWTs when possible

7. Audit and Monitor

Enable appropriate logging:

log_file: "/var/log/nats-server.log"
log_size_limit: 1GB
max_traced_msg_len: 256

8. Secure Cluster Communications

Use TLS for cluster routes:

cluster {
  name: "production"
  port: 6222
  
  tls {
    cert_file: "/path/to/route-cert.pem"
    key_file: "/path/to/route-key.pem"
    ca_file: "/path/to/ca.pem"
    verify: true
  }
}

9. Limit Connection Rates

Protect against DoS attacks:

max_connections: 10000
max_control_line: 4096
max_payload: 1048576

10. Use Operator Mode for Production

Operator mode with JWT-based authentication provides:

Centralized account management
Dynamic credential updates
Advanced multi-tenancy
Account claims and limits

Vulnerability Reporting

If you discover a security vulnerability in NATS Server:

Do not open public GitHub issues for security vulnerabilities.

Report security issues to: [email protected]

Get Started

Deployment

Architecture

Features

Operations

Configuration

Security Overview