# Security Policy

## Security Best Practices

### Authentication

- User passwords are hashed using SHA-256 with a salt
- Session tokens are generated using cryptographically secure random bytes
- Sessions expire after the configured TTL (default: 12 hours)
- Session cookies use `HttpOnly`, `Secure`, and `SameSite` flags

### Data Protection

- All API endpoints validate and sanitize input
- SQL queries use parameterized statements to prevent injection
- Sensitive data is never logged or exposed in error messages
- Environment variables contain all sensitive configuration

### CORS & Origin

- CORS headers are properly configured
- API requests require proper origin validation
- Credentials are included in cross-origin requests appropriately

## Environment Security

### Required Configuration Changes Before Production

1. **Default Credentials**
   ```env
   DEFAULT_ADMIN_EMAIL=your-admin@example.com
   DEFAULT_ADMIN_PASSWORD=YourStrongPassword123!@#
   ```
   
   **NEVER use default credentials in production**

2. **Session Security**
   - Adjust `SESSION_TTL_HOURS` based on security requirements
   - For sensitive applications, use shorter TTLs (e.g., 1-2 hours)

3. **Database Path**
   - Ensure database file has restrictive permissions (600)
   - Store on encrypted filesystem if possible

### Deployment Security

1. **HTTPS/SSL**
   - Always use HTTPS in production
   - Enable `Secure` flag in cookie configuration
   - Use valid SSL certificates

2. **Environment Variables**
   - Never commit `.env` files
   - Use `.env.example` as template
   - Rotate credentials regularly

3. **Database**
   - Regular backups with encryption
   - Restricted file permissions
   - Consider PostgreSQL for production deployments

4. **Access Control**
   - Implement firewall rules
   - Use rate limiting on API endpoints
   - Monitor for suspicious activity

## Session Management

### Session Security Features

- **HttpOnly Cookies**: Prevents client-side JavaScript from accessing session tokens
- **SameSite Attribute**: Protects against CSRF attacks
- **Session Expiration**: Automatic logout after TTL
- **Secure Transmission**: Cookies only sent over HTTPS in production

### Session Best Practices

- Log out inactive users
- Invalidate sessions on password change
- Clear sessions on logout
- Monitor for concurrent sessions per user

## Password Policy

### Requirements

- Minimum 8 characters
- Include uppercase, lowercase, numbers, and special characters
- Never stored in plain text
- Hashed with salt before database storage

### Implementation

Update the registration validation to enforce these requirements in `register.html` and `server.js`.

## Reporting Security Vulnerabilities

If you discover a security vulnerability, please email security@cdeis-lab.com instead of using the issue tracker.

Include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix if available

We will:
- Acknowledge receipt within 24 hours
- Begin investigation immediately
- Work with you on a fix
- Credit you in the security advisory (unless you prefer anonymity)

## Security Update Policy

Security updates are released as soon as vulnerabilities are patched. Critical security updates may be released outside normal release cycles.

## Audit Logging

### Recommended Implementation

Track these events in production:
- User registration and login attempts
- Failed authentication attempts
- Application approvals/rejections
- Payment transactions
- Admin configuration changes

## Third-Party Dependencies

- Regularly update Node.js and npm packages
- Use `npm audit` to identify vulnerabilities
- Pin dependency versions for reproducible deployments
- Review dependencies for security advisories

## Additional Resources

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [Node.js Security Best Practices](https://nodejs.org/en/docs/guides/security/)
- [SQLite Security](https://www.sqlite.org/security.html)