This document outlines security considerations, best practices, and vulnerability reporting procedures for the StepGuide project.

• Always use environment variables for sensitive data (API keys, secrets, credentials)
• Use different credentials for development, staging, and production environments
• Rotate secrets regularly (at least every 90 days)
• Use strong, randomly generated secrets for cookie signature keys (minimum 32 characters)
• Store production secrets in secure secret management systems (Google Secret Manager, AWS Secrets Manager, HashiCorp Vault)

• Never commit .env files to version control
• Never hardcode secrets in source code
• Never share API keys in public channels (GitHub issues, Discord, etc.)
• Never use development credentials in production
• Never log sensitive information (API keys, passwords, tokens)

• Enable Multi-Factor Authentication (MFA) for production users
• Implement rate limiting on authentication endpoints
• Use strong password requirements (minimum 8 characters, complexity requirements)
• Implement account lockout policies after failed login attempts
• Monitor for suspicious authentication patterns

• Implement strict Firestore Security Rules if using Firestore
• Use server-side verification for sensitive operations
• Never trust client-side data validation alone
• Regularly review and audit Firebase security rules

• Protect admin SDK credentials with strict access controls
• Use service accounts with minimal required permissions
• Never expose admin credentials to client-side code
• Store private keys securely (use Secret Manager in production)

• Restrict API key permissions to minimum required scope
• Use separate API keys for different environments
• Monitor API usage for anomalies
• Implement request validation and sanitization
• Set up rate limiting to prevent abuse

• Monitor token usage to prevent unexpected costs
• Implement input validation to prevent prompt injection
• Set context length limits to control costs
• Use quota management to cap spending
• Consider implementing a content moderation layer

• Always use HTTPS in production (not HTTP)
• Use WSS (WebSocket Secure) for WebSocket connections
• Implement TLS 1.2 or higher
• Use valid SSL/TLS certificates (Let's Encrypt, etc.)

• Configure restrictive CORS policies
• Only allow trusted origins
• Don't use wildcards (*) in production
• Specify allowed methods and headers explicitly

• Implement rate limiting on all public endpoints
• Use IP-based throttling to prevent abuse
• Consider user-based rate limiting for authenticated endpoints
• Monitor for DDoS patterns

• Use httpOnly cookies to prevent XSS attacks
• Set secure flag in production (requires HTTPS)
• Use sameSite: 'lax' or 'strict' to prevent CSRF
• Implement cookie rotation strategy
• Set appropriate cookie expiration times

• Implement session invalidation on logout
• Support concurrent session management
• Detect and handle session hijacking attempts
• Use short-lived tokens where appropriate

• Validate all user inputs on both client and server
• Sanitize inputs to prevent XSS attacks
• Implement size limits for file uploads
• Validate file types before processing
• Use parameterized queries to prevent injection attacks

• Scan uploaded files for malware
• Implement file size limits (prevent DoS)
• Validate file types and extensions
• Sanitize file names before storage
• Store files in isolated storage (not in web root)
• Consider using virus scanning services

• Keep dependencies up to date (npm, pip packages)
• Monitor for security advisories (GitHub Dependabot, Snyk)
• Use npm audit and pip-audit regularly
• Subscribe to security mailing lists for critical dependencies

# Node.js/npm
npm audit
npm audit fix

# Python
pip install pip-audit
pip-audit

# Or use uv
uv pip install pip-audit

Risk: If .env files are committed, API keys could be exposed.

Mitigation:

• Ensure .gitignore includes all .env* files
• Use git-secrets or similar tools to prevent accidental commits
• Regularly scan repository history for leaked secrets
• Rotate keys immediately if exposure is detected

Risk: Firebase config (API keys) are visible in client-side code.

Note: This is normal for Firebase. These are public identifiers, not secrets. Security is enforced through:

• Firebase Security Rules
• Domain restrictions in Firebase Console
• Server-side validation

Still recommended:

• Restrict API key usage in Google Cloud Console
• Enable Firebase App Check for additional protection
• Implement proper Firebase Security Rules

Risk: User-generated content could execute malicious scripts.

Mitigation:

• React automatically escapes content (but be careful with dangerouslySetInnerHTML)
• Sanitize user inputs before storage
• Use Content Security Policy (CSP) headers
• Implement proper output encoding

Risk: Malicious users could manipulate AI prompts to bypass restrictions.

Mitigation:

• Validate and sanitize user inputs
• Implement content filtering
• Use system prompts to set boundaries
• Monitor for suspicious patterns
• Consider implementing a moderation layer

Risk: Excessive API usage could lead to unexpected costs.

Mitigation:

• Set up billing alerts in Google Cloud Console and Pinecone
• Implement rate limiting per user
• Set quota limits on API usage
• Monitor usage patterns regularly
• Implement circuit breakers for runaway costs

Risk: Sensitive user data could be stored insecurely.

Mitigation:

• Don't store unnecessary personal information
• Encrypt sensitive data at rest and in transit
• Implement data retention policies
• Comply with GDPR, CCPA, and other regulations
• Provide data export and deletion capabilities
• Document data handling in Privacy Policy

• All .env files are in .gitignore
• No API keys or secrets in source code
• .env.example files have placeholder values only
• All dependencies are up to date
• npm audit and pip-audit show no critical vulnerabilities
• HTTPS is enforced in production
• Secure cookies are enabled (USE_SECURE_COOKIES=true)
• CORS is properly configured (no wildcards)
• Rate limiting is implemented
• Input validation is implemented
• Firebase Security Rules are in place
• File upload restrictions are implemented
• Error messages don't leak sensitive information
• Logging doesn't include sensitive data
• Billing alerts are configured
• Security headers are set (CSP, X-Frame-Options, etc.)

If you discover a security vulnerability, please report it responsibly:

1. DO NOT create a public GitHub issue
2. Email: [ashwinkrishna979@gmail.com] with:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if any)
3. Allow time for a fix before public disclosure

• Acknowledgment: Within 48 hours
• Initial Assessment: Within 1 week
• Fix Timeline: Varies based on severity (critical issues prioritized)
• Credit: Security researchers will be credited (if desired)

• Critical: Remote code execution, authentication bypass, data breach
• High: Privilege escalation, significant data exposure
• Medium: Limited data exposure, denial of service
• Low: Information disclosure, minor issues

• git-secrets: Prevent committing secrets to Git
• Dependabot: Automated dependency updates
• Snyk: Vulnerability scanning for dependencies
• OWASP ZAP: Web application security scanner
• Firebase App Check: Protect backend resources
• Google Cloud Security Command Center: Monitor GCP resources

• OWASP Top 10
• Firebase Security Checklist
• Next.js Security Headers
• Google Cloud Security Best Practices

• Review application logs for suspicious activity
• Check for new dependency vulnerabilities
• Monitor API usage patterns

• Review and update dependencies
• Audit user access and permissions
• Review Firebase Security Rules
• Check billing and usage reports

• Rotate API keys and secrets
• Security audit of code changes
• Review and update security documentation
• Penetration testing (for production systems)

• Comprehensive security audit
• Review compliance with data protection regulations
• Update security policies and procedures
• Security training for team members

1. Contain: Immediately revoke compromised credentials
2. Assess: Determine scope and impact of breach
3. Notify: Inform affected users and authorities as required
4. Fix: Patch vulnerability and deploy fix
5. Document: Record incident details and response
6. Review: Conduct post-mortem and update security measures

• Vercel: For Next.js frontend (built-in security features)
• Google Cloud Run: For FastAPI backends (scalable and secure)
• Railway/Render: Alternative deployment options

• Enable automatic SSL/TLS certificates
• Use environment variable management from platform
• Enable DDoS protection
• Use Web Application Firewall (WAF) if available
• Enable logging and monitoring
• Set up alerting for anomalies

This security policy is provided as-is. The project maintainers make reasonable efforts to ensure security but cannot guarantee complete security. Users deploying this application are responsible for their own security measures and compliance with applicable laws and regulations.

Last Updated: January 2026

For questions or concerns, please contact: ashwinkrishna979@gmail.com