fixes

SECURITY.md

@@ -9,7 +9,9 @@ The security of generated projects is a top priority. This document outlines the
 ### 1. Application Security
 
 #### HTTP Security Headers
+
 All responses include security headers:
+
 - `X-Content-Type-Options: nosniff` - Prevents MIME sniffing
 - `X-Frame-Options: DENY` - Prevents clickjacking
 - `X-XSS-Protection: 1; mode=block` - XSS protection for legacy browsers
@@ -19,25 +21,29 @@ All responses include security headers:
 - `Strict-Transport-Security` (production) - Forces HTTPS
 
 #### Input Validation
+
 - Project name validation prevents path traversal
 - Request body size limits (4MB default)
 - Query parameter validation
 - Path parameter sanitization
 
 #### SQL Injection Prevention
+
 - Parameterized queries enforced via `database/sql`
 - Context-based timeouts
 - Connection pool limits
 - Prepared statement support
 
 #### Authentication & Authorization
+
 - Ready for JWT/OAuth2 integration
 - Request ID tracking for audit trails
 - Structured logging for security events
 
 ### 2. Infrastructure Security
 
 #### Docker Security
+
 - **Non-root user**: Containers run as UID 1000
 - **Read-only filesystem**: Root filesystem is read-only
 - **Minimal base image**: Alpine Linux (smallest attack surface)
@@ -46,13 +52,15 @@ All responses include security headers:
 - **Health checks**: Automatic container health monitoring
 
 #### Database Security
+
 - Connection pooling with limits (prevents exhaustion)
 - Connection timeouts (prevents hanging)
 - SSL/TLS support ready (set `sslmode=require`)
 - Secrets via environment variables (never hardcoded)
 - Parameterized queries only
 
 #### Redis Security
+
 - Connection pooling with resource limits
 - Authentication ready (set password in URL)
 - TLS support ready (use `rediss://` scheme)
@@ -62,25 +70,29 @@ All responses include security headers:
 ### 3. Operational Security
 
 #### Logging
+
 - **No sensitive data**: Credentials never logged
 - **Structured JSON**: Machine-parseable logs
 - **Correlation IDs**: Request tracking
 - **Stack traces**: Error debugging without exposure
 - **Sanitized paths**: Query strings removed
 
 #### Secrets Management
+
 - `.env` files in `.gitignore`
 - `.env.example` for documentation only
 - Environment variable validation
 - No default production credentials
 
 #### Error Handling
+
 - Panic recovery middleware
 - Generic error messages to clients
 - Detailed errors in logs (with request ID)
 - No stack traces exposed to users
 
 #### Graceful Shutdown
+
 - SIGTERM/SIGINT handling
 - Connection draining (30s timeout)
 - Database connection cleanup
@@ -89,6 +101,7 @@ All responses include security headers:
 ### 4. Dependency Security
 
 Generated projects use:
+
 - **go.sum**: Dependency checksums verified
 - **Minimal dependencies**: Only essential packages
 - **High-quality dependencies**:
@@ -102,6 +115,7 @@ Generated projects use:
 Before deploying, ensure you:
 
 ### Required
+
 - [ ] Change default database credentials
 - [ ] Set strong passwords (min 20 characters)
 - [ ] Enable SSL/TLS for database (`sslmode=require`)
@@ -114,6 +128,7 @@ Before deploying, ensure you:
 - [ ] Review security headers for your use case
 
 ### Recommended
+
 - [ ] Implement rate limiting
 - [ ] Add authentication middleware
 - [ ] Enable database audit logging
@@ -126,6 +141,7 @@ Before deploying, ensure you:
 - [ ] Add API key validation
 
 ### Advanced
+
 - [ ] Enable mutual TLS (mTLS)
 - [ ] Implement database encryption at rest
 - [ ] Use Redis ACLs to limit commands
@@ -142,12 +158,15 @@ Before deploying, ensure you:
 If you discover a security vulnerability in:
 
 ### The Generator Tool (`goforge`)
+
 Please report via:
-- Email: security@yourproject.com
+
+- Email: sharmavivek1709@gmail.com
 - GitHub Security Advisory: Create a draft security advisory
 - Do NOT create a public issue
 
 ### Generated Projects
+
 Security of generated projects is the responsibility of the project owner. However, if you find a vulnerability in the generated code templates, please report it as above.
 
 ## 📋 Vulnerability Response
@@ -162,34 +181,36 @@ We follow this process:
 
 ### Severity Levels
 
-| Severity | Response Time | Examples |
-|----------|---------------|----------|
-| **Critical** | 24 hours | RCE, SQL injection in templates |
-| **High** | 3 days | Authentication bypass, XSS |
-| **Medium** | 7 days | Information disclosure |
-| **Low** | 14 days | Minor misconfigurations |
+| Severity     | Response Time | Examples                        |
+| ------------ | ------------- | ------------------------------- |
+| **Critical** | 24 hours      | RCE, SQL injection in templates |
+| **High**     | 3 days        | Authentication bypass, XSS      |
+| **Medium**   | 7 days        | Information disclosure          |
+| **Low**      | 14 days       | Minor misconfigurations         |
 
 ## 🛠️ Security Updates
 
 ### Version Support
 
-| Version | Supported |
-|---------|-----------|
-| Latest  | ✅ Yes    |
-| < Latest| ❌ No     |
+| Version  | Supported |
+| -------- | --------- |
+| Latest   | ✅ Yes    |
+| < Latest | ❌ No     |
 
 Always use the latest version: `go install github.com/viveksharma/goforge@latest`
 
 ### Security Advisories
 
 Subscribe to security advisories:
+
 - GitHub Watch → Custom → Security alerts
 - Check releases for security fixes
 - Star the repo to stay updated
 
 ## 🔐 Security Best Practices
 
 ### Development
+
 1. Never commit `.env` files
 2. Use separate credentials for dev/staging/prod
 3. Rotate credentials regularly (90 days)
@@ -198,6 +219,7 @@ Subscribe to security advisories:
 6. Keep dependencies updated
 
 ### Production
+
 1. Use secrets manager (never env vars in orchestrator)
 2. Enable all TLS/SSL connections
 3. Use network segmentation
@@ -210,6 +232,7 @@ Subscribe to security advisories:
 10. Have an incident response plan
 
 ### Docker
+
 1. Scan images for vulnerabilities
 2. Use specific image tags (not `latest`)
 3. Keep base images updated