Overview
Aurora implements defense-in-depth security with multiple layers of protection:- Authentication & Authorization: User identity verification and access control
- Secrets Management: HashiCorp Vault for sensitive credentials
- Network Security: TLS encryption and CORS protection
- Data Protection: Row-Level Security and encryption
- Input Validation: Protection against injection attacks
- Rate Limiting: DDoS and abuse prevention
Authentication
Password-Based Authentication
Aurora uses bcrypt for secure password hashing:- Minimum 8 characters password requirement
- bcrypt hashing with automatic salt generation
- Work factor: Default bcrypt cost parameter (10-12 rounds)
- Constant-time comparison to prevent timing attacks
- No password storage: Only hashed values stored in database
Session Management
Flask session cookies with secure configuration:- Secure cookies in production (HTTPS)
- HttpOnly flag prevents XSS cookie theft
- SameSite=Lax prevents CSRF attacks
- File-based storage (not memory-based)
- Automatic session cleanup
OAuth 2.0 Integration
Cloud provider authentication via OAuth: GCP OAuth Flow:- State parameter prevents CSRF attacks
- PKCE (optional) for public clients
- Token encryption before storage
- Automatic token refresh
- Scope limitation (principle of least privilege)
Authorization
Row-Level Security (RLS)
PostgreSQL RLS enforces data isolation:chat_sessions: Users can only access their own chatsincidents: Users can only see their incidentsuser_tokens: Users can only access their credentialsllm_usage_tracking: Users can only see their usage- All Kubernetes and monitoring tables
API Authorization
Header-based authentication for API requests:Secrets Management
HashiCorp Vault
Aurora uses Vault for sensitive credential storage: Architecture:Redis Caching
Secrets cached in Redis with TTL:Network Security
TLS/HTTPS
Production Configuration:CORS Configuration
Cross-Origin Resource Sharing protection:Input Validation
SQL Injection Prevention
Always use parameterized queries:XSS Prevention
Frontend sanitization:Command Injection Prevention
Never use shell=True with user input:Path Traversal Prevention
Validate file paths:Rate Limiting
API Rate Limiting
Protect against abuse and DDoS:WebSocket Rate Limiting
Custom rate limiter for WebSocket connections:Data Protection
Encryption at Rest
Database encryption:Encryption in Transit
All network traffic encrypted:- HTTPS for REST API (TLS 1.2+)
- WSS for WebSocket (TLS 1.2+)
- SSL for PostgreSQL connections
- TLS for Redis connections
Data Retention
Soft deletes for user data:Vulnerability Management
Dependency Scanning
Python dependencies:Container Security
Dockerfile best practices:Incident Response
Logging
Security event logging:Monitoring
Security metrics:- Failed authentication attempts
- Rate limit violations
- Unauthorized access attempts
- Abnormal API usage patterns
- Database connection failures
Reporting Security Issues
DO NOT report security vulnerabilities through public GitHub issues. Instead, email: [email protected] Include:- Type of vulnerability
- Affected source files
- Steps to reproduce
- Proof-of-concept (if possible)
- Impact assessment
Security Checklist
Development
- All passwords hashed with bcrypt
- Parameterized SQL queries only
- No shell=True in subprocess calls
- Input validation on all endpoints
- Output sanitization for user-generated content
- Secrets stored in Vault, not environment variables
- Rate limiting on all public endpoints
Deployment
- HTTPS enabled with valid certificates
- Security headers configured
- CORS properly restricted
- Database encryption enabled
- Redis password configured
- Vault sealed/unsealed properly
- Firewall rules configured
- Container images scanned
Operations
- Regular security updates applied
- Dependency vulnerabilities patched
- Audit logs reviewed regularly
- Access logs monitored
- Incident response plan documented
- Backup encryption verified
- Disaster recovery tested