Files
michaelschiemer/docs/deployment/PRODUCTION-SECURITY-UPDATES.md
Michael Schiemer 5050c7d73a docs: consolidate documentation into organized structure
- Move 12 markdown files from root to docs/ subdirectories
- Organize documentation by category:
  • docs/troubleshooting/ (1 file)  - Technical troubleshooting guides
  • docs/deployment/      (4 files) - Deployment and security documentation
  • docs/guides/          (3 files) - Feature-specific guides
  • docs/planning/        (4 files) - Planning and improvement proposals

Root directory cleanup:
- Reduced from 16 to 4 markdown files in root
- Only essential project files remain:
  • CLAUDE.md (AI instructions)
  • README.md (Main project readme)
  • CLEANUP_PLAN.md (Current cleanup plan)
  • SRC_STRUCTURE_IMPROVEMENTS.md (Structure improvements)

This improves:
 Documentation discoverability
 Logical organization by purpose
 Clean root directory
 Better maintainability
2025-10-05 11:05:04 +02:00

134 lines
4.9 KiB
Markdown

# Production Security Configuration Updates
## Overview
Updated the production security configuration for michaelschiemer.de using a SINGLE docker-compose.yml approach with environment-based configuration.
## Critical Security Fixes Applied
### 1. Performance Debug Information
- **Issue**: Performance debug information was visible on production
- **Fix**: Updated `PerformanceServiceInitializer.php` to strictly check both `APP_ENV=production` AND `APP_DEBUG=false`
- **Result**: Debug performance tracking disabled in production (`ANALYTICS_TRACK_PERFORMANCE=false` in `.env.production`)
### 2. Session Debug Data Exposure
- **Issue**: Session debug data was exposed in production
- **Fix**: Performance service now disables detailed reports in production
- **Result**: Session info and debug data hidden when `APP_ENV=production`
### 3. Admin Routes Security
- **Issue**: Admin routes were not properly secured
- **Fix**: Added `ProductionSecurityMiddleware` to middleware stack (priority #2 - early execution)
- **Result**: Admin/debug routes return 404 in production, IP-restricted routes require whitelist
## Files Updated
### 1. `/src/Framework/Http/MiddlewareManager.php`
- Added `ProductionSecurityMiddleware` to middleware stack (position #2 for early execution)
- Updated middleware numbering to maintain proper order
### 2. `/deploy.sh`
- Changed deployment to copy `.env.production` to `.env` instead of using `.env.example`
- Added production configuration validation step
- Added security endpoint testing during deployment
### 3. `/.env.production`
- Added `ADMIN_ALLOWED_IPS=127.0.0.1,::1` for IP whitelisting
- Set `ANALYTICS_TRACK_PERFORMANCE=false` to disable debug performance tracking
- Confirmed `XDEBUG_MODE=off` for production
### 4. Created `/test-security.sh`
- Comprehensive security testing script for local validation
- Tests blocked routes, IP-restricted routes, and environment configuration
## Security Middleware Configuration
### ProductionSecurityMiddleware Behavior
**Blocked Routes in Production** (returns 404):
- `/admin/discovery`
- `/admin/routes`
- `/admin/performance`
- `/admin/environment`
- `/debug`
- `/performance`
- `/api/debug`
**IP-Restricted Routes in Production** (requires whitelist):
- `/admin`
- `/analytics`
- `/health`
- `/metrics`
**Allowed IPs** (configurable via `ADMIN_ALLOWED_IPS` environment variable):
- `127.0.0.1` (localhost IPv4)
- `::1` (localhost IPv6)
- Additional IPs can be added as comma-separated values
## Environment-Based Configuration
### Single docker-compose.yml Approach
- Uses `APP_ENV` environment variable to control behavior
- Dockerfile uses `ENV` build argument for environment-specific builds
- Same containers work for both development and production
### Environment Variable Control
- **Development**: `APP_ENV=development`, `APP_DEBUG=true`
- Full debug information visible
- All routes accessible
- Performance tracking enabled
- **Production**: `APP_ENV=production`, `APP_DEBUG=false`
- Debug information hidden
- Admin/debug routes blocked
- Performance tracking disabled
- IP restrictions enforced
## Validation & Testing
### Local Testing Commands
```bash
# Test security configuration
./test-security.sh
# Test with production environment locally
docker exec php bash -c "cp .env.production .env && php test-production-config.php"
# Restore development environment
docker exec php cp .env.production.backup .env
```
### Deployment Validation
The deployment script now automatically:
1. Validates `APP_ENV=production` and `APP_DEBUG=false`
2. Tests that debug routes return 404
3. Confirms environment is properly configured
### Manual Production Testing
After deployment, verify from external IP:
```bash
# Should return 404
curl -H "User-Agent: Mozilla/5.0" https://michaelschiemer.de/debug
curl -H "User-Agent: Mozilla/5.0" https://michaelschiemer.de/admin/discovery
# Should return 403 (unless your IP is whitelisted)
curl -H "User-Agent: Mozilla/5.0" https://michaelschiemer.de/admin
curl -H "User-Agent: Mozilla/5.0" https://michaelschiemer.de/health
```
## Key Security Improvements
1. **Zero Debug Information Leakage**: No performance data, session info, or debug details in production
2. **Route-Level Security**: Admin and debug routes completely blocked (404 response)
3. **IP-Based Access Control**: Critical routes restricted to whitelisted IPs
4. **Environment Validation**: Automatic validation during deployment
5. **Single Configuration**: One docker-compose.yml handles both dev and prod modes
## Deployment Process
1. **Pre-deployment**: Local testing with production environment simulation
2. **Deployment**: Automatic copy of `.env.production` to `.env`
3. **Validation**: Automatic environment and security testing
4. **Verification**: Manual testing of critical security endpoints
The system now provides robust production security while maintaining development flexibility through environment-based configuration.