release: v0.5.0 - Authentication, API Keys & Advanced Features
Complete v0.5.0 implementation: Database (@db-engineer): - 3 migrations: users, api_keys, report_schedules tables - Foreign keys, indexes, constraints, enums Backend (@backend-dev): - JWT authentication service with bcrypt (cost=12) - Auth endpoints: /register, /login, /refresh, /me - API Keys service with hash storage and prefix validation - API Keys endpoints: CRUD + rotate - Security module with JWT HS256 Frontend (@frontend-dev): - Login/Register pages with validation - AuthContext with localStorage persistence - Protected routes implementation - API Keys management UI (create, revoke, rotate) - Header with user dropdown DevOps (@devops-engineer): - .env.example and .env.production.example - docker-compose.scheduler.yml - scripts/setup-secrets.sh - INFRASTRUCTURE_SETUP.md QA (@qa-engineer): - 85 E2E tests: auth.spec.ts, apikeys.spec.ts, scenarios.spec.ts, regression-v050.spec.ts - auth-helpers.ts with 20+ utility functions - Test plans and documentation Architecture (@spec-architect): - SECURITY.md with best practices - SECURITY-CHECKLIST.md pre-deployment - Updated architecture.md with auth flows - Updated README.md with v0.5.0 features Documentation: - Updated todo.md with v0.5.0 status - Added docs/README.md index - Complete setup instructions Dependencies added: - bcrypt, python-jose, passlib, email-validator Tested: JWT auth flow, API keys CRUD, protected routes, 85 E2E tests ready Closes: v0.5.0 milestone
This commit is contained in:
Luca Sacchi Ricciardi
330
docs/INFRASTRUCTURE_SETUP.md
Normal file
330
docs/INFRASTRUCTURE_SETUP.md
Normal file
@@ -0,0 +1,330 @@
|
||||
# MockupAWS v0.5.0 Infrastructure Setup Guide
|
||||
|
||||
This document provides setup instructions for the infrastructure components introduced in v0.5.0.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Secrets Management](#secrets-management)
|
||||
2. [Email Configuration](#email-configuration)
|
||||
3. [Cron Job Deployment](#cron-job-deployment)
|
||||
|
||||
---
|
||||
|
||||
## Secrets Management
|
||||
|
||||
### Quick Start
|
||||
|
||||
Generate secure secrets automatically:
|
||||
|
||||
```bash
|
||||
# Make the script executable
|
||||
chmod +x scripts/setup-secrets.sh
|
||||
|
||||
# Run the setup script
|
||||
./scripts/setup-secrets.sh
|
||||
|
||||
# Or specify a custom output file
|
||||
./scripts/setup-secrets.sh /path/to/.env.production
|
||||
```
|
||||
|
||||
### Manual Secret Generation
|
||||
|
||||
If you prefer to generate secrets manually:
|
||||
|
||||
```bash
|
||||
# Generate JWT Secret (256 bits)
|
||||
openssl rand -hex 32
|
||||
|
||||
# Generate API Key Encryption Key
|
||||
openssl rand -hex 16
|
||||
|
||||
# Generate secure random password
|
||||
date +%s | sha256sum | base64 | head -c 32 ; echo
|
||||
```
|
||||
|
||||
### Required Secrets
|
||||
|
||||
| Variable | Purpose | Generation |
|
||||
|----------|---------|------------|
|
||||
| `JWT_SECRET_KEY` | Sign JWT tokens | `openssl rand -hex 32` |
|
||||
| `DATABASE_URL` | PostgreSQL connection | Update password manually |
|
||||
| `SENDGRID_API_KEY` | Email delivery | From SendGrid dashboard |
|
||||
| `AWS_ACCESS_KEY_ID` | AWS SES (optional) | From AWS IAM |
|
||||
| `AWS_SECRET_ACCESS_KEY` | AWS SES (optional) | From AWS IAM |
|
||||
|
||||
### Security Best Practices
|
||||
|
||||
1. **Never commit `.env` files to git**
|
||||
```bash
|
||||
# Ensure .env is in .gitignore
|
||||
echo ".env" >> .gitignore
|
||||
```
|
||||
|
||||
2. **Use different secrets for each environment**
|
||||
- Development: `.env`
|
||||
- Staging: `.env.staging`
|
||||
- Production: Use secrets manager (AWS Secrets Manager, HashiCorp Vault)
|
||||
|
||||
3. **Rotate secrets regularly**
|
||||
- JWT secrets: Every 90 days
|
||||
- API keys: Every 30 days
|
||||
- Database passwords: Every 90 days
|
||||
|
||||
4. **Production Recommendations**
|
||||
- Use AWS Secrets Manager or HashiCorp Vault
|
||||
- Enable encryption at rest
|
||||
- Use IAM roles instead of hardcoded AWS credentials when possible
|
||||
|
||||
---
|
||||
|
||||
## Email Configuration
|
||||
|
||||
### Option 1: SendGrid (Recommended for v0.5.0)
|
||||
|
||||
**Free Tier**: 100 emails/day
|
||||
|
||||
#### Setup Steps
|
||||
|
||||
1. **Create SendGrid Account**
|
||||
```
|
||||
https://signup.sendgrid.com/
|
||||
```
|
||||
|
||||
2. **Generate API Key**
|
||||
- Go to: https://app.sendgrid.com/settings/api_keys
|
||||
- Click "Create API Key"
|
||||
- Name: `mockupAWS-production`
|
||||
- Permissions: **Full Access** (or restrict to "Mail Send")
|
||||
- Copy the key (starts with `SG.`)
|
||||
|
||||
3. **Verify Sender Domain**
|
||||
- Go to: https://app.sendgrid.com/settings/sender_auth
|
||||
- Choose "Domain Authentication"
|
||||
- Follow DNS configuration steps
|
||||
- Wait for verification (usually instant, up to 24 hours)
|
||||
|
||||
4. **Configure Environment Variables**
|
||||
```bash
|
||||
EMAIL_PROVIDER=sendgrid
|
||||
SENDGRID_API_KEY=SG.your_actual_api_key_here
|
||||
EMAIL_FROM=noreply@yourdomain.com
|
||||
```
|
||||
|
||||
#### Testing SendGrid
|
||||
|
||||
```bash
|
||||
# Run the email test script (to be created by backend team)
|
||||
python -m src.scripts.test_email --to your@email.com
|
||||
```
|
||||
|
||||
### Option 2: AWS SES (Amazon Simple Email Service)
|
||||
|
||||
**Free Tier**: 62,000 emails/month (when sending from EC2)
|
||||
|
||||
#### Setup Steps
|
||||
|
||||
1. **Configure SES in AWS Console**
|
||||
```
|
||||
https://console.aws.amazon.com/ses/
|
||||
```
|
||||
|
||||
2. **Verify Email or Domain**
|
||||
- For testing: Verify individual email address
|
||||
- For production: Verify entire domain
|
||||
|
||||
3. **Get AWS Credentials**
|
||||
- Create IAM user with `ses:SendEmail` and `ses:SendRawEmail` permissions
|
||||
- Generate Access Key ID and Secret Access Key
|
||||
|
||||
4. **Move Out of Sandbox** (required for production)
|
||||
- Open a support case to increase sending limits
|
||||
- Provide use case and estimated volume
|
||||
|
||||
5. **Configure Environment Variables**
|
||||
```bash
|
||||
EMAIL_PROVIDER=ses
|
||||
AWS_ACCESS_KEY_ID=AKIA...
|
||||
AWS_SECRET_ACCESS_KEY=...
|
||||
AWS_REGION=us-east-1
|
||||
EMAIL_FROM=noreply@yourdomain.com
|
||||
```
|
||||
|
||||
### Email Testing Guide
|
||||
|
||||
#### Development Testing
|
||||
|
||||
```bash
|
||||
# 1. Start the backend
|
||||
uv run uvicorn src.main:app --reload
|
||||
|
||||
# 2. Send test email via API
|
||||
curl -X POST http://localhost:8000/api/v1/test/email \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"to": "your@email.com", "subject": "Test", "body": "Hello"}'
|
||||
```
|
||||
|
||||
#### Email Templates
|
||||
|
||||
The following email templates are available in v0.5.0:
|
||||
|
||||
| Template | Trigger | Variables |
|
||||
|----------|---------|-----------|
|
||||
| `welcome` | User registration | `{{name}}`, `{{login_url}}` |
|
||||
| `report_ready` | Report generation complete | `{{report_name}}`, `{{download_url}}` |
|
||||
| `scheduled_report` | Scheduled report delivery | `{{scenario_name}}`, `{{attachment}}` |
|
||||
| `password_reset` | Password reset request | `{{reset_url}}`, `{{expires_in}}` |
|
||||
|
||||
---
|
||||
|
||||
## Cron Job Deployment
|
||||
|
||||
### Overview
|
||||
|
||||
Three deployment options are available for report scheduling:
|
||||
|
||||
| Option | Pros | Cons | Best For |
|
||||
|--------|------|------|----------|
|
||||
| **1. APScheduler (in-process)** | Simple, no extra services | Runs in API container | Small deployments |
|
||||
| **2. APScheduler (standalone)** | Separate scaling, resilient | Requires extra container | Medium deployments |
|
||||
| **3. Celery + Redis** | Distributed, scalable, robust | More complex setup | Large deployments |
|
||||
|
||||
### Option 1: APScheduler In-Process (Simplest)
|
||||
|
||||
No additional configuration needed. The scheduler runs within the main backend process.
|
||||
|
||||
**Pros:**
|
||||
- Zero additional setup
|
||||
- Works immediately
|
||||
|
||||
**Cons:**
|
||||
- API restarts interrupt scheduled jobs
|
||||
- Cannot scale independently
|
||||
|
||||
**Enable:**
|
||||
```bash
|
||||
SCHEDULER_ENABLED=true
|
||||
SCHEDULER_INTERVAL_MINUTES=5
|
||||
```
|
||||
|
||||
### Option 2: Standalone Scheduler Service (Recommended for v0.5.0)
|
||||
|
||||
Runs the scheduler in a separate Docker container.
|
||||
|
||||
**Deployment:**
|
||||
```bash
|
||||
# Start with main services
|
||||
docker-compose -f docker-compose.yml -f docker-compose.scheduler.yml up -d
|
||||
|
||||
# View logs
|
||||
docker-compose -f docker-compose.scheduler.yml logs -f scheduler
|
||||
```
|
||||
|
||||
**Pros:**
|
||||
- Independent scaling
|
||||
- Resilient to API restarts
|
||||
- Clear separation of concerns
|
||||
|
||||
**Cons:**
|
||||
- Requires additional container
|
||||
|
||||
### Option 3: Celery + Redis (Production-Scale)
|
||||
|
||||
For high-volume or mission-critical scheduling.
|
||||
|
||||
**Prerequisites:**
|
||||
```bash
|
||||
# Add to requirements.txt
|
||||
celery[redis]>=5.0.0
|
||||
redis>=4.0.0
|
||||
```
|
||||
|
||||
**Deployment:**
|
||||
```bash
|
||||
# Uncomment celery services in docker-compose.scheduler.yml
|
||||
docker-compose -f docker-compose.yml -f docker-compose.scheduler.yml up -d
|
||||
|
||||
# Scale workers if needed
|
||||
docker-compose -f docker-compose.scheduler.yml up -d --scale celery-worker=3
|
||||
```
|
||||
|
||||
### Scheduler Configuration
|
||||
|
||||
| Variable | Default | Description |
|
||||
|----------|---------|-------------|
|
||||
| `SCHEDULER_ENABLED` | `true` | Enable/disable scheduler |
|
||||
| `SCHEDULER_INTERVAL_MINUTES` | `5` | Check interval for due jobs |
|
||||
| `REDIS_URL` | `redis://localhost:6379/0` | Redis connection (Celery) |
|
||||
|
||||
### Monitoring Scheduled Jobs
|
||||
|
||||
```bash
|
||||
# View scheduler logs
|
||||
docker-compose logs -f scheduler
|
||||
|
||||
# Check Redis queue (if using Celery)
|
||||
docker-compose exec redis redis-cli llen celery
|
||||
|
||||
# Monitor Celery workers
|
||||
docker-compose exec celery-worker celery -A src.jobs.celery_app inspect active
|
||||
```
|
||||
|
||||
### Production Deployment Checklist
|
||||
|
||||
- [ ] Secrets generated and secured
|
||||
- [ ] Email provider configured and tested
|
||||
- [ ] Database migrations applied
|
||||
- [ ] Redis running (if using Celery)
|
||||
- [ ] Scheduler container started
|
||||
- [ ] Logs being collected
|
||||
- [ ] Health checks configured
|
||||
- [ ] Monitoring alerts set up
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Email Not Sending
|
||||
|
||||
```bash
|
||||
# Check email configuration
|
||||
echo $EMAIL_PROVIDER
|
||||
echo $SENDGRID_API_KEY
|
||||
|
||||
# Test SendGrid API directly
|
||||
curl -X POST https://api.sendgrid.com/v3/mail/send \
|
||||
-H "Authorization: Bearer $SENDGRID_API_KEY" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"personalizations":[{"to":[{"email":"test@example.com"}]}],"from":{"email":"noreply@mockupaws.com"},"subject":"Test","content":[{"type":"text/plain","value":"Hello"}]}'
|
||||
```
|
||||
|
||||
### Scheduler Not Running
|
||||
|
||||
```bash
|
||||
# Check if scheduler container is running
|
||||
docker-compose ps
|
||||
|
||||
# View scheduler logs
|
||||
docker-compose logs scheduler
|
||||
|
||||
# Restart scheduler
|
||||
docker-compose restart scheduler
|
||||
```
|
||||
|
||||
### JWT Errors
|
||||
|
||||
```bash
|
||||
# Verify JWT secret length (should be 32+ chars)
|
||||
echo -n $JWT_SECRET_KEY | wc -c
|
||||
|
||||
# Regenerate if needed
|
||||
openssl rand -hex 32
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Additional Resources
|
||||
|
||||
- [SendGrid Documentation](https://docs.sendgrid.com/)
|
||||
- [AWS SES Documentation](https://docs.aws.amazon.com/ses/)
|
||||
- [APScheduler Documentation](https://apscheduler.readthedocs.io/)
|
||||
- [Celery Documentation](https://docs.celeryq.dev/)
|
||||
100
docs/README.md
Normal file
100
docs/README.md
Normal file
@@ -0,0 +1,100 @@
|
||||
# mockupAWS Documentation
|
||||
|
||||
> **Versione:** v0.5.0
|
||||
> **Ultimo aggiornamento:** 2026-04-07
|
||||
|
||||
---
|
||||
|
||||
## 📚 Indice Documentazione
|
||||
|
||||
### Getting Started
|
||||
- [../README.md](../README.md) - Panoramica progetto e quick start
|
||||
- [../CHANGELOG.md](../CHANGELOG.md) - Storia versioni e cambiamenti
|
||||
|
||||
### Architecture & Design
|
||||
- [../export/architecture.md](../export/architecture.md) - Architettura sistema completa
|
||||
- [architecture.md](./architecture.md) - Schema architettura base
|
||||
- [../export/kanban-v0.4.0.md](../export/kanban-v0.4.0.md) - Task board v0.4.0
|
||||
|
||||
### Security
|
||||
- [../SECURITY.md](../SECURITY.md) - Security overview e best practices
|
||||
- [SECURITY-CHECKLIST.md](./SECURITY-CHECKLIST.md) - Pre-deployment checklist
|
||||
|
||||
### Infrastructure
|
||||
- [INFRASTRUCTURE_SETUP.md](./INFRASTRUCTURE_SETUP.md) - Setup email, cron, secrets
|
||||
- [../docker-compose.yml](../docker-compose.yml) - Docker orchestration
|
||||
- [../docker-compose.scheduler.yml](../docker-compose.scheduler.yml) - Scheduler deployment
|
||||
|
||||
### Development
|
||||
- [../todo.md](../todo.md) - Task list e prossimi passi
|
||||
- [bug_ledger.md](./bug_ledger.md) - Bug tracking
|
||||
- [../export/progress.md](../export/progress.md) - Progress tracking
|
||||
|
||||
### API Documentation
|
||||
- **Swagger UI:** http://localhost:8000/docs (quando backend running)
|
||||
- [../export/architecture.md](../export/architecture.md) - API specifications
|
||||
|
||||
### Prompts & Planning
|
||||
- [../prompt/prompt-v0.4.0-planning.md](../prompt/prompt-v0.4.0-planning.md) - Planning v0.4.0
|
||||
- [../prompt/prompt-v0.4.0-kickoff.md](../prompt/prompt-v0.4.0-kickoff.md) - Kickoff v0.4.0
|
||||
- [../prompt/prompt-v0.5.0-kickoff.md](../prompt/prompt-v0.5.0-kickoff.md) - Kickoff v0.5.0
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Quick Reference
|
||||
|
||||
### Setup Development
|
||||
```bash
|
||||
# 1. Clone
|
||||
git clone <repository-url>
|
||||
cd mockupAWS
|
||||
|
||||
# 2. Setup secrets
|
||||
./scripts/setup-secrets.sh
|
||||
|
||||
# 3. Start database
|
||||
docker-compose up -d postgres
|
||||
|
||||
# 4. Run migrations
|
||||
uv run alembic upgrade head
|
||||
|
||||
# 5. Start backend
|
||||
uv run uvicorn src.main:app --reload
|
||||
|
||||
# 6. Start frontend (altro terminale)
|
||||
cd frontend && npm run dev
|
||||
```
|
||||
|
||||
### Testing
|
||||
```bash
|
||||
# Backend tests
|
||||
cd /home/google/Sources/LucaSacchiNet/mockupAWS
|
||||
pytest
|
||||
|
||||
# Frontend E2E tests
|
||||
cd frontend
|
||||
npm run test:e2e
|
||||
|
||||
# Specific test suites
|
||||
npm run test:e2e -- auth.spec.ts
|
||||
npm run test:e2e -- apikeys.spec.ts
|
||||
```
|
||||
|
||||
### API Endpoints
|
||||
- **Health:** `GET /health`
|
||||
- **Auth:** `POST /api/v1/auth/login`, `POST /api/v1/auth/register`
|
||||
- **API Keys:** `GET /api/v1/api-keys`, `POST /api/v1/api-keys`
|
||||
- **Scenarios:** `GET /api/v1/scenarios`
|
||||
- **Reports:** `GET /api/v1/reports`, `POST /api/v1/scenarios/{id}/reports`
|
||||
|
||||
---
|
||||
|
||||
## 📞 Supporto
|
||||
|
||||
- **Issues:** GitHub Issues
|
||||
- **Documentation:** Questa directory
|
||||
- **API Docs:** http://localhost:8000/docs
|
||||
|
||||
---
|
||||
|
||||
*Per informazioni dettagliate su ogni componente, consultare i file linkati sopra.*
|
||||
462
docs/SECURITY-CHECKLIST.md
Normal file
462
docs/SECURITY-CHECKLIST.md
Normal file
@@ -0,0 +1,462 @@
|
||||
# Security Checklist - mockupAWS v0.5.0
|
||||
|
||||
> **Version:** 0.5.0
|
||||
> **Purpose:** Pre-deployment security verification
|
||||
> **Last Updated:** 2026-04-07
|
||||
|
||||
---
|
||||
|
||||
## Pre-Deployment Security Checklist
|
||||
|
||||
Use this checklist before deploying mockupAWS to any environment.
|
||||
|
||||
### 🔐 Environment Variables
|
||||
|
||||
#### Required Security Variables
|
||||
|
||||
```bash
|
||||
# JWT Configuration
|
||||
JWT_SECRET_KEY= # [REQUIRED] Min 32 chars, use: openssl rand -hex 32
|
||||
JWT_ALGORITHM=HS256 # [REQUIRED] Must be HS256
|
||||
ACCESS_TOKEN_EXPIRE_MINUTES=30 # [REQUIRED] Max 60 recommended
|
||||
REFRESH_TOKEN_EXPIRE_DAYS=7 # [REQUIRED] Max 30 recommended
|
||||
|
||||
# Password Security
|
||||
BCRYPT_ROUNDS=12 # [REQUIRED] Min 12, higher = slower
|
||||
|
||||
# Database
|
||||
DATABASE_URL= # [REQUIRED] Use strong password
|
||||
POSTGRES_PASSWORD= # [REQUIRED] Use: openssl rand -base64 32
|
||||
|
||||
# API Keys
|
||||
API_KEY_PREFIX=mk_ # [REQUIRED] Do not change
|
||||
```
|
||||
|
||||
#### Checklist
|
||||
|
||||
- [ ] `JWT_SECRET_KEY` is at least 32 characters
|
||||
- [ ] `JWT_SECRET_KEY` is unique per environment
|
||||
- [ ] `JWT_SECRET_KEY` is not the default/placeholder value
|
||||
- [ ] `BCRYPT_ROUNDS` is set to 12 or higher
|
||||
- [ ] Database password is strong (≥20 characters, mixed case, symbols)
|
||||
- [ ] No secrets are hardcoded in source code
|
||||
- [ ] `.env` file is in `.gitignore`
|
||||
- [ ] `.env` file has restrictive permissions (chmod 600)
|
||||
|
||||
---
|
||||
|
||||
### 🌐 HTTPS Configuration
|
||||
|
||||
#### Production Requirements
|
||||
|
||||
- [ ] TLS 1.3 is enabled
|
||||
- [ ] TLS 1.0 and 1.1 are disabled
|
||||
- [ ] Valid SSL certificate (not self-signed)
|
||||
- [ ] HTTP redirects to HTTPS
|
||||
- [ ] HSTS header is configured
|
||||
- [ ] Certificate is not expired
|
||||
|
||||
#### Nginx Configuration Example
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 443 ssl http2;
|
||||
server_name api.mockupaws.com;
|
||||
|
||||
ssl_certificate /path/to/cert.pem;
|
||||
ssl_certificate_key /path/to/key.pem;
|
||||
ssl_protocols TLSv1.3;
|
||||
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';
|
||||
ssl_prefer_server_ciphers off;
|
||||
|
||||
# HSTS
|
||||
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
|
||||
|
||||
location / {
|
||||
proxy_pass http://backend:8000;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
}
|
||||
}
|
||||
|
||||
# Redirect HTTP to HTTPS
|
||||
server {
|
||||
listen 80;
|
||||
server_name api.mockupaws.com;
|
||||
return 301 https://$server_name$request_uri;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 🛡️ Rate Limiting Verification
|
||||
|
||||
#### Test Commands
|
||||
|
||||
```bash
|
||||
# Test auth rate limiting (should block after 5 requests)
|
||||
for i in {1..7}; do
|
||||
curl -X POST http://localhost:8000/api/v1/auth/login \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"email":"test@test.com","password":"wrong"}' \
|
||||
-w "Status: %{http_code}\n" -o /dev/null -s
|
||||
done
|
||||
# Expected: First 5 = 401, 6th+ = 429
|
||||
|
||||
# Test general rate limiting (should block after 100 requests)
|
||||
for i in {1..105}; do
|
||||
curl http://localhost:8000/health \
|
||||
-w "Status: %{http_code}\n" -o /dev/null -s
|
||||
done
|
||||
# Expected: First 100 = 200, 101st+ = 429
|
||||
```
|
||||
|
||||
#### Checklist
|
||||
|
||||
- [ ] Auth endpoints return 429 after 5 failed attempts
|
||||
- [ ] Rate limit headers are present in responses
|
||||
- [ ] Rate limits reset after time window
|
||||
- [ ] Different limits for different endpoint types
|
||||
- [ ] Burst allowance for legitimate traffic
|
||||
|
||||
---
|
||||
|
||||
### 🔑 JWT Security Verification
|
||||
|
||||
#### Secret Generation
|
||||
|
||||
```bash
|
||||
# Generate a secure JWT secret
|
||||
openssl rand -hex 32
|
||||
|
||||
# Example output:
|
||||
# a3f5c8e9d2b1f4a7c6e8d9b0a2c4e6f8a1b3d5c7e9f2a4b6c8d0e2f4a6b8c0d
|
||||
|
||||
# Verify length (should be 64 hex chars = 32 bytes)
|
||||
openssl rand -hex 32 | wc -c
|
||||
# Expected: 65 (64 chars + newline)
|
||||
```
|
||||
|
||||
#### Token Validation Tests
|
||||
|
||||
```bash
|
||||
# 1. Test valid token
|
||||
curl http://localhost:8000/api/v1/auth/me \
|
||||
-H "Authorization: Bearer <valid_token>"
|
||||
# Expected: 200 with user data
|
||||
|
||||
# 2. Test expired token
|
||||
curl http://localhost:8000/api/v1/auth/me \
|
||||
-H "Authorization: Bearer <expired_token>"
|
||||
# Expected: 401 {"error": "token_expired"}
|
||||
|
||||
# 3. Test invalid signature
|
||||
curl http://localhost:8000/api/v1/auth/me \
|
||||
-H "Authorization: Bearer invalid.token.here"
|
||||
# Expected: 401 {"error": "invalid_token"}
|
||||
|
||||
# 4. Test missing token
|
||||
curl http://localhost:8000/api/v1/auth/me
|
||||
# Expected: 401 {"error": "missing_token"}
|
||||
```
|
||||
|
||||
#### Checklist
|
||||
|
||||
- [ ] JWT secret is ≥32 characters
|
||||
- [ ] Access tokens expire in 30 minutes
|
||||
- [ ] Refresh tokens expire in 7 days
|
||||
- [ ] Token rotation is implemented
|
||||
- [ ] Expired tokens are rejected
|
||||
- [ ] Invalid signatures are rejected
|
||||
- [ ] Token payload doesn't contain sensitive data
|
||||
|
||||
---
|
||||
|
||||
### 🗝️ API Keys Validation
|
||||
|
||||
#### Creation Flow Test
|
||||
|
||||
```bash
|
||||
# 1. Create API key
|
||||
curl -X POST http://localhost:8000/api/v1/api-keys \
|
||||
-H "Authorization: Bearer <jwt_token>" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"name": "Test Key",
|
||||
"scopes": ["read:scenarios"],
|
||||
"expires_days": 30
|
||||
}'
|
||||
# Response should include: {"key": "mk_xxxx...", ...}
|
||||
# ⚠️ Save this key - it won't be shown again!
|
||||
|
||||
# 2. List API keys (should NOT show full key)
|
||||
curl http://localhost:8000/api/v1/api-keys \
|
||||
-H "Authorization: Bearer <jwt_token>"
|
||||
# Response should show: prefix, name, scopes, but NOT full key
|
||||
|
||||
# 3. Use API key
|
||||
curl http://localhost:8000/api/v1/scenarios \
|
||||
-H "X-API-Key: mk_xxxxxxxx..."
|
||||
# Expected: 200 with scenarios list
|
||||
|
||||
# 4. Test revoked key
|
||||
curl http://localhost:8000/api/v1/scenarios \
|
||||
-H "X-API-Key: <revoked_key>"
|
||||
# Expected: 401 {"error": "invalid_api_key"}
|
||||
```
|
||||
|
||||
#### Storage Verification
|
||||
|
||||
```sql
|
||||
-- Connect to database
|
||||
\c mockupaws
|
||||
|
||||
-- Verify API keys are hashed (not plaintext)
|
||||
SELECT key_prefix, key_hash, LENGTH(key_hash) as hash_length
|
||||
FROM api_keys
|
||||
LIMIT 5;
|
||||
|
||||
-- Expected: key_hash should be 64 chars (SHA-256 hex)
|
||||
-- Should NOT see anything like 'mk_' in key_hash column
|
||||
```
|
||||
|
||||
#### Checklist
|
||||
|
||||
- [ ] API keys use `mk_` prefix
|
||||
- [ ] Full key shown only at creation
|
||||
- [ ] Keys are hashed (SHA-256) in database
|
||||
- [ ] Only prefix is stored plaintext
|
||||
- [ ] Scopes are validated on each request
|
||||
- [ ] Expired keys are rejected
|
||||
- [ ] Revoked keys return 401
|
||||
- [ ] Keys have associated user_id
|
||||
|
||||
---
|
||||
|
||||
### 📝 Input Validation Tests
|
||||
|
||||
#### SQL Injection Test
|
||||
|
||||
```bash
|
||||
# Test SQL injection in scenario ID
|
||||
curl "http://localhost:8000/api/v1/scenarios/1' OR '1'='1"
|
||||
# Expected: 422 (validation error) or 404 (not found)
|
||||
# Should NOT return data or server error
|
||||
|
||||
# Test in query parameters
|
||||
curl "http://localhost:8000/api/v1/scenarios?name='; DROP TABLE users; --"
|
||||
# Expected: 200 with empty list or validation error
|
||||
# Should NOT execute the DROP statement
|
||||
```
|
||||
|
||||
#### XSS Test
|
||||
|
||||
```bash
|
||||
# Test XSS in scenario creation
|
||||
curl -X POST http://localhost:8000/api/v1/scenarios \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"name": "<script>alert(1)</script>",
|
||||
"region": "us-east-1"
|
||||
}'
|
||||
# Expected: Script tags are escaped or rejected in response
|
||||
```
|
||||
|
||||
#### Checklist
|
||||
|
||||
- [ ] SQL injection attempts return errors (not data)
|
||||
- [ ] XSS payloads are escaped in responses
|
||||
- [ ] Input length limits are enforced
|
||||
- [ ] Special characters are handled safely
|
||||
- [ ] File uploads validate type and size
|
||||
|
||||
---
|
||||
|
||||
### 🔒 CORS Configuration
|
||||
|
||||
#### Test CORS Policy
|
||||
|
||||
```bash
|
||||
# Test preflight request
|
||||
curl -X OPTIONS http://localhost:8000/api/v1/scenarios \
|
||||
-H "Origin: http://localhost:5173" \
|
||||
-H "Access-Control-Request-Method: POST" \
|
||||
-H "Access-Control-Request-Headers: Content-Type,Authorization" \
|
||||
-v
|
||||
|
||||
# Expected response headers:
|
||||
# Access-Control-Allow-Origin: http://localhost:5173
|
||||
# Access-Control-Allow-Methods: GET, POST, PUT, DELETE
|
||||
# Access-Control-Allow-Headers: Content-Type, Authorization
|
||||
|
||||
# Test disallowed origin
|
||||
curl -X GET http://localhost:8000/api/v1/scenarios \
|
||||
-H "Origin: http://evil.com" \
|
||||
-v
|
||||
# Expected: No Access-Control-Allow-Origin header (or 403)
|
||||
```
|
||||
|
||||
#### Checklist
|
||||
|
||||
- [ ] CORS only allows configured origins
|
||||
- [ ] Credentials header is set correctly
|
||||
- [ ] Preflight requests work for allowed origins
|
||||
- [ ] Disallowed origins are rejected
|
||||
- [ ] CORS headers are present on all responses
|
||||
|
||||
---
|
||||
|
||||
### 🚨 Security Headers
|
||||
|
||||
#### Verify Headers
|
||||
|
||||
```bash
|
||||
curl -I http://localhost:8000/health
|
||||
|
||||
# Expected headers:
|
||||
# X-Content-Type-Options: nosniff
|
||||
# X-Frame-Options: DENY
|
||||
# X-XSS-Protection: 1; mode=block
|
||||
# Strict-Transport-Security: max-age=31536000; includeSubDomains
|
||||
```
|
||||
|
||||
#### Checklist
|
||||
|
||||
- [ ] `X-Content-Type-Options: nosniff`
|
||||
- [ ] `X-Frame-Options: DENY`
|
||||
- [ ] `X-XSS-Protection: 1; mode=block`
|
||||
- [ ] `Strict-Transport-Security` (in production)
|
||||
- [ ] Server header doesn't expose version
|
||||
|
||||
---
|
||||
|
||||
### 🗄️ Database Security
|
||||
|
||||
#### Connection Security
|
||||
|
||||
```bash
|
||||
# Verify database uses SSL (production)
|
||||
psql "postgresql://user:pass@host/db?sslmode=require"
|
||||
|
||||
# Check for SSL connection
|
||||
SHOW ssl;
|
||||
# Expected: on
|
||||
```
|
||||
|
||||
#### User Permissions
|
||||
|
||||
```sql
|
||||
-- Verify app user has limited permissions
|
||||
\du app_user
|
||||
|
||||
-- Should have: CONNECT, USAGE, SELECT, INSERT, UPDATE, DELETE
|
||||
-- Should NOT have: SUPERUSER, CREATEDB, CREATEROLE
|
||||
```
|
||||
|
||||
#### Checklist
|
||||
|
||||
- [ ] Database connections use SSL/TLS
|
||||
- [ ] Database user has minimal permissions
|
||||
- [ ] No default passwords in use
|
||||
- [ ] Database not exposed to public internet
|
||||
- [ ] Regular backups are encrypted
|
||||
|
||||
---
|
||||
|
||||
### 📊 Logging and Monitoring
|
||||
|
||||
#### Security Events to Log
|
||||
|
||||
| Event | Log Level | Alert |
|
||||
|-------|-----------|-------|
|
||||
| Authentication failure | WARNING | After 5 consecutive |
|
||||
| Rate limit exceeded | WARNING | After 10 violations |
|
||||
| Invalid API key | WARNING | After 5 attempts |
|
||||
| Suspicious pattern | ERROR | Immediate |
|
||||
| Successful admin action | INFO | - |
|
||||
|
||||
#### Checklist
|
||||
|
||||
- [ ] Authentication failures are logged
|
||||
- [ ] Rate limit violations are logged
|
||||
- [ ] API key usage is logged
|
||||
- [ ] Sensitive data is NOT logged
|
||||
- [ ] Logs are stored securely
|
||||
- [ ] Log retention policy is defined
|
||||
|
||||
---
|
||||
|
||||
### 🧪 Final Verification Commands
|
||||
|
||||
Run this complete test suite:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# security-tests.sh
|
||||
|
||||
BASE_URL="http://localhost:8000"
|
||||
JWT_TOKEN="your-test-token"
|
||||
API_KEY="your-test-api-key"
|
||||
|
||||
echo "=== Security Verification Tests ==="
|
||||
|
||||
# 1. HTTPS Redirect (production only)
|
||||
echo "Testing HTTPS redirect..."
|
||||
curl -s -o /dev/null -w "%{http_code}" "$BASE_URL/health"
|
||||
|
||||
# 2. Rate Limiting
|
||||
echo "Testing rate limiting..."
|
||||
for i in {1..6}; do
|
||||
CODE=$(curl -s -o /dev/null -w "%{http_code}" "$BASE_URL/health")
|
||||
echo "Request $i: $CODE"
|
||||
done
|
||||
|
||||
# 3. JWT Validation
|
||||
echo "Testing JWT validation..."
|
||||
curl -s "$BASE_URL/api/v1/auth/me" -H "Authorization: Bearer invalid"
|
||||
|
||||
# 4. API Key Security
|
||||
echo "Testing API key validation..."
|
||||
curl -s "$BASE_URL/api/v1/scenarios" -H "X-API-Key: invalid_key"
|
||||
|
||||
# 5. SQL Injection
|
||||
echo "Testing SQL injection protection..."
|
||||
curl -s "$BASE_URL/api/v1/scenarios/1%27%20OR%20%271%27%3D%271"
|
||||
|
||||
# 6. XSS Protection
|
||||
echo "Testing XSS protection..."
|
||||
curl -s -X POST "$BASE_URL/api/v1/scenarios" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"name":"<script>alert(1)</script>","region":"us-east-1"}'
|
||||
|
||||
echo "=== Tests Complete ==="
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Sign-off
|
||||
|
||||
| Role | Name | Date | Signature |
|
||||
|------|------|------|-----------|
|
||||
| Security Lead | | | |
|
||||
| DevOps Lead | | | |
|
||||
| QA Lead | | | |
|
||||
| Product Owner | | | |
|
||||
|
||||
---
|
||||
|
||||
## Post-Deployment
|
||||
|
||||
After deployment:
|
||||
|
||||
- [ ] Verify all security headers in production
|
||||
- [ ] Test authentication flows in production
|
||||
- [ ] Verify API key generation works
|
||||
- [ ] Check rate limiting is active
|
||||
- [ ] Review security logs for anomalies
|
||||
- [ ] Schedule security review (90 days)
|
||||
|
||||
---
|
||||
|
||||
*This checklist must be completed before any production deployment.*
|
||||
*For questions, contact the security team.*
|
||||
Reference in New Issue
Block a user