LLM API Security
LLM-APIs sind Einfallstore für Angriffe — ohne Security können API-Keys gestohlen werden und Requests manipuliert werden. Vier Kontrollen: Key Management, Request Authentication, Gateway Hardening und Rate Limiting.
Was ist LLM API Security? Einfach erklärt
LLM API Security ist wie ein Türsteuer für KI-Modelle: es kontrolliert, wer auf die API zugreifen darf und wie. API Key Management generiert sichere Schlüssel und rotiert sie regelmäßig. Request Authentication prüft, ob der Request legitim ist (JWT, mTLS, API Keys). API Gateway Hardening blockiert bösartige Requests (WAF, Input Validation). Rate Limiting verhindert Überlastung und Missbrauch. Ohne diese Kontrollen können Angreifer API-Keys stehlen, Requests fälschen oder das System überlasten.
↓ Springe zu 4 API-Security-Kontrollen und FAQ
4 API-Security-Kontrollen
Securely manage API keys for LLM access. Use short-lived tokens, key rotation, and secure storage to prevent unauthorised access.
# Moltbot API key management:
api_key_management:
enabled: true
# Key generation:
key_generation:
algorithm: "AES-256-GCM"
key_length: 256
# Generate cryptographically secure keys
# Key expiration:
expiration:
default_ttl_hours: 24
max_ttl_hours: 168 # 7 days max
# Keys must be rotated regularly
# Key storage:
storage:
# Never store keys in plaintext
# Use: HashiCorp Vault, AWS Secrets Manager, or encrypted database
encryption: true
encryption_algorithm: "AES-256-GCM"
# Hash keys for verification (one-way hash)
hash_for_verification: true
# Key rotation:
rotation:
enabled: true
auto_rotate: true
rotation_interval_days: 30
# Rotate keys every 30 days
notify_before_rotation_days: 7
# Key revocation:
revocation:
enabled: true
# Allow immediate revocation of compromised keys
revoke_on: security_event, user_request, key_expiryAuthenticate all LLM API requests. Use JWT tokens, mTLS, or API keys with proper validation.
# Moltbot request authentication:
authentication:
enabled: true
# Authentication methods:
methods:
# 1. JWT tokens
jwt:
enabled: true
issuer: "https://clawguru.org"
audience: "moltbot-api"
algorithm: "RS256"
# Validate JWT signature, issuer, audience, expiration
# 2. API keys
api_key:
enabled: true
header_name: "X-API-Key"
# Validate against hashed keys in database
# 3. mTLS
mtls:
enabled: true
# Require valid client certificate
validate_cert_chain: true
validate_cert_expiry: true
# Multi-factor authentication:
mfa:
enabled: false
# For high-security use cases, require MFA
# Example: JWT + API key required together
# Authentication middleware:
middleware:
# Apply authentication to all API endpoints
except_health_check: true
# Health check endpoint may be exemptedHarden your API gateway to protect LLM endpoints. Enable WAF, input validation, and request/response filtering.
# Moltbot API gateway hardening:
gateway_hardening:
enabled: true
# Web Application Firewall (WAF):
waf:
enabled: true
# Block common attack patterns:
# - SQL injection
# - XSS
# - Command injection
# - Path traversal
rules: "OWASP ModSecurity Core Rule Set"
# Input validation:
input_validation:
enabled: true
# Validate all request parameters:
# - Type checking (string, integer, boolean)
# - Length limits
# - Format validation (email, URL, UUID)
# - Allowlist for enum values
# Request size limits:
request_limits:
max_request_size_bytes: 1048576 # 1MB
max_header_size_bytes: 8192 # 8KB
# Reject oversized requests
# Response filtering:
response_filtering:
enabled: true
# Remove sensitive data from responses:
# - Internal error messages
# - Stack traces
# - System information
# - Debug dataRate limit API requests to prevent abuse and control costs. Use token-based or request-based rate limiting.
# Moltbot API rate limiting:
api_rate_limiting:
enabled: true
# Rate limiting strategies:
strategies:
# 1. Token-based rate limiting
token_based:
enabled: true
# Rate limit based on API key
per_key_per_minute: 100
per_key_per_hour: 1000
# 2. IP-based rate limiting
ip_based:
enabled: true
# Rate limit per IP address
per_ip_per_minute: 50
per_ip_per_hour: 500
# 3. User-based rate limiting
user_based:
enabled: true
# Rate limit per user ID
per_user_per_minute: 100
per_user_per_hour: 1000
# Enforcement:
enforcement:
action: throttle # Options: block, throttle, queue
throttle_factor: 0.5 # Reduce speed to 50% when over quota
block_message: "Rate limit exceeded. Please wait."
# Burst allowance:
burst:
enabled: true
burst_multiplier: 2 # Allow 2x quota for short bursts
burst_duration_seconds: 30Häufige Fragen
What is the difference between API key management and request authentication?
API key management is about securely generating, storing, rotating, and revoking the keys themselves. It includes: key generation with cryptographic algorithms, secure storage (encrypted at rest), key rotation policies, and key revocation procedures. Request authentication is about validating that an incoming request is authorised using the credentials presented. It includes: validating JWT tokens, checking API keys against a database, verifying mTLS certificates, and enforcing authentication middleware. Both are necessary: secure key management ensures keys cannot be stolen, while request authentication ensures only valid requests are processed.
How do I implement secure API key storage?
Secure API key storage requires: 1) Never store keys in plaintext in code, config files, or environment variables. 2) Use a secrets manager: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager. 3) Encrypt keys at rest using AES-256-GCM or similar. 4) Hash keys for verification — store a one-way hash of the key, compare hashes during authentication. 5) Use short-lived tokens — keys expire after a set time (24 hours recommended). 6) Implement key rotation — automatically rotate keys every 30 days. 7) Log all key access for audit trails.
What are the best practices for API gateway hardening?
API gateway hardening best practices: 1) Enable WAF — use OWASP ModSecurity Core Rule Set to block common attack patterns. 2) Input validation — validate all request parameters for type, length, format, and allowlist. 3) Request size limits — reject oversized requests to prevent DoS. 4) Response filtering — remove sensitive data (stack traces, debug info) from responses. 5) Enable TLS 1.3 — encrypt all traffic in transit. 6) Enable CORS with strict origin validation. 7) Enable security headers: HSTS, X-Frame-Options, X-Content-Type-Options. 8) Monitor gateway logs for suspicious activity.
How do I choose between token-based and request-based rate limiting?
Token-based rate limiting limits based on the API key or JWT token. It is user-specific and fair — each user gets their own quota. It prevents token sharing by limiting per-key usage. Request-based rate limiting limits based on the number of HTTP requests. It is simpler but less fair — a single user with many requests can exhaust the quota. Recommendation: use token-based rate limiting for authenticated APIs (LLM APIs are typically authenticated). Use request-based rate limiting only for public endpoints or as a secondary layer of defense. Token-based rate limiting is more accurate for controlling costs and preventing abuse.