> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/nats-io/nats-server/llms.txt
> Use this file to discover all available pages before exploring further.

# Security Overview

> NATS Server security architecture, threat model, and best practices

## 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:

<Info>
  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](https://github.com/trailofbits/publications/blob/master/reviews/2025-04-ostif-nats-securityreview.pdf) is publicly available.
</Info>

## 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:

1. **Network Layer**: TLS encryption with optional mTLS
2. **Authentication Layer**: Multiple methods (NKeys, JWT, tokens)
3. **Authorization Layer**: Subject-level permissions
4. **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

1. Server sends a random nonce to the client
2. Client signs the nonce with its private key
3. Server verifies the signature using the client's public key
4. No passwords are ever transmitted

### Configuration Example

```hocon theme={null}
authorization {
  users = [
    {nkey: "UCKASD5KPQQYHB6KYD7RC62VZQN7VRU5NN2BKL7UFBQ3UBYAJQPVNHSQ"}
  ]
}
```

<Warning>
  Never commit or share private NKeys. Store them securely and rotate them regularly.
</Warning>

## Password Security

When using username/password authentication:

### BCrypt Hashing

Always use bcrypt-hashed passwords in configuration files:

```hocon theme={null}
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
```

<Tip>
  Generate bcrypt hashes using: `nats server passwd`
</Tip>

## Security Best Practices

### 1. Always Use TLS in Production

```hocon theme={null}
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:

```hocon theme={null}
accounts {
  PROD: {
    users: [{nkey: "PROD_USER_NKEY"}]
  }
  DEV: {
    users: [{nkey: "DEV_USER_NKEY"}]
  }
}
```

### 4. Implement Least Privilege

Grant only necessary permissions:

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

### 5. Enable Monitoring with Authentication

Protect monitoring endpoints:

```hocon theme={null}
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:

```hocon theme={null}
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:

```hocon theme={null}
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:

```hocon theme={null}
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:

<Warning>
  Do not open public GitHub issues for security vulnerabilities.
</Warning>

Report security issues to: **[security@nats.io](mailto:security@nats.io)**

## Related Topics

* [Authentication Methods](/operations/authentication)
* [Authorization & Permissions](/operations/authorization)
* [TLS Configuration](/operations/tls)
* [Monitoring Endpoints](/operations/monitoring-endpoints)