We release patches for security vulnerabilities for the following versions:

• Password hashing — bcrypt, cost 12 (configurable via BCRYPT_ROUNDS); comparison is always timing-safe (bcrypt.compare). Failed logins for non-existent accounts burn an equal amount of hashing time to defeat timing-based user enumeration.
• Password policy — minimum 8 characters, enforced server-side on register, reset, and change.
• Sessions — JWTs (HS256, algorithm pinned on sign and verify), 7-day expiry (JWT_EXPIRES_IN), rejected with 401 Token expired by the auth middleware.
• JWT secret — must be provided via JWT_SECRET (≥ 32 chars). The server refuses to boot in production without it; development falls back to a flagged insecure value. The secret is never sent to or referenced by the frontend.
• Email verification — new accounts are unverified and cannot log in until verified (24h signed token). POST /api/auth/resend-verification re-sends; responses are generic to prevent enumeration. In dev (no SMTP) links are printed to the console.
• Password reset — 256-bit CSPRNG token; only its SHA-256 hash is stored; 1-hour expiry; single-use; all of a user's reset tokens are invalidated on any password change. Forgot-password responses are identical for known and unknown addresses, including when mail delivery fails.
• Rate limiting — login / forgot-password / reset-password: 10 requests / 15 min per IP; register / verify / resend: 20 / 15 min; global API: 200 / 15 min (Redis-backed when available, in-memory otherwise). trust proxy is set to 1 hop.
• Monitoring — failed and blocked login attempts are logged with identifier + IP.

• Login/register set an httpOnly studyhub_token cookie — JavaScript cannot read or exfiltrate the session token. SameSite=Lax by default (blocks cross-site POSTs / CSRF); set COOKIE_SAMESITE=None only when the API is on a different site than the client (prefer same-origin proxying instead), and COOKIE_SECURE=true (automatic in production) for HTTPS-only transport.
• The Authorization: Bearer header remains accepted for non-browser clients.
• Logout (POST /api/auth/logout) clears the cookie server-side and the client drops its cached user.

• JWTs are stateless: logout removes the browser's cookie, but a cookie value copied before logout remains valid until expiry — full revocation needs a token-version / denylist mechanism (planned).

We take the security of StudyHub seriously. If you believe you have found a security vulnerability, please report it to us as described below.

• Open a public GitHub issue for security vulnerabilities
• Disclose the vulnerability publicly before it has been addressed

1. Email us directly at: viphacker.100.org@gmail.com (or create a private security advisory on GitHub)
2. Provide detailed information including:
   • Type of vulnerability
   • Full paths of source file(s) related to the vulnerability
   • Location of the affected source code (tag/branch/commit or direct URL)
   • Step-by-step instructions to reproduce the issue
   • Proof-of-concept or exploit code (if possible)
   • Impact of the vulnerability

• Acknowledgment: We will acknowledge receipt of your vulnerability report within 48 hours
• Investigation: We will investigate and validate the vulnerability
• Updates: We will keep you informed about our progress
• Resolution: We will work on a fix and release it as soon as possible
• Credit: We will credit you in our security advisories (unless you prefer to remain anonymous)

1. Change Default Credentials

   • Immediately change the default admin password after installation
   • Use strong, unique passwords

2. Environment Variables

   • Never commit .env files to version control
   • Use strong, random values for JWT_SECRET
   • Rotate secrets regularly

3. Database Security

   • Use strong database passwords
   • Restrict database access to localhost when possible
   • Enable SSL/TLS for database connections in production

4. HTTPS/SSL

   • Always use HTTPS in production
   • Obtain valid SSL certificates (Let's Encrypt recommended)
   • Enable HSTS headers

5. Regular Updates

   • Keep dependencies up to date
   • Run npm audit regularly
   • Apply security patches promptly

6. Backups

   • Implement regular database backups
   • Store backups securely
   • Test backup restoration procedures

1. Input Validation

   • Validate all user inputs on the server side
   • Use parameterized queries to prevent SQL injection
   • Sanitize data before rendering

2. Authentication

   • Never store passwords in plain text
   • Use bcrypt for password hashing
   • Implement proper session management

3. Authorization

   • Verify user permissions for all actions
   • Use role-based access control
   • Implement proper middleware checks

4. File Uploads

   • Validate file types and sizes
   • Scan uploaded files for malware
   • Store files outside the web root when possible

5. Rate Limiting

   • Implement rate limiting on all endpoints
   • Use stricter limits on authentication endpoints
   • Monitor for abuse patterns

6. Dependencies

   • Regularly update npm packages
   • Review dependency security advisories
   • Use npm audit fix to address vulnerabilities

1. Rate Limiting: Implemented on API, auth, and upload endpoints
2. Password Hashing: Using bcrypt with salt rounds
3. JWT Tokens: Secure token-based authentication
4. Input Validation: Server-side validation using express-validator
5. SQL Injection Prevention: Parameterized queries throughout
6. CORS: Configured for specific origins
7. Helmet: Security headers enabled

1. Two-Factor Authentication (2FA): Not yet implemented
2. Content Security Policy (CSP): Can be strengthened
3. Rate Limiting: Consider Redis-based rate limiting for distributed systems
4. File Scanning: Implement virus scanning for uploads
5. Audit Logging: Enhanced logging for security events

The application implements the following security headers via Helmet:

• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY
• X-XSS-Protection: 1; mode=block
• Strict-Transport-Security (when HTTPS is enabled)

1. Day 0: Vulnerability reported
2. Day 1-2: Acknowledgment sent to reporter
3. Day 3-7: Investigation and validation
4. Day 8-30: Patch development and testing
5. Day 31: Public disclosure and patch release

We aim to resolve critical vulnerabilities within 30 days of disclosure.

• Changed default admin password
• Generated strong JWT_SECRET
• Configured HTTPS/SSL
• Set up database backups
• Configured SMTP for email notifications
• Enabled rate limiting
• Configured CORS for production domain
• Set NODE_ENV=production
• Reviewed and secured all environment variables
• Implemented monitoring and logging
• Set up firewall rules
• Disabled unnecessary services
• Configured database access restrictions

StudyHub is designed with privacy and security in mind. However, users are responsible for ensuring compliance with relevant regulations in their jurisdiction, including but not limited to:

• GDPR (General Data Protection Regulation)
• FERPA (Family Educational Rights and Privacy Act)
• COPPA (Children's Online Privacy Protection Act)

For security concerns, please contact:

• Email: viphacker.100.org@gmail.com
• GitHub: Create a private security advisory

We would like to thank the following individuals for responsibly disclosing security vulnerabilities:

(List will be updated as vulnerabilities are reported and resolved)

Last Updated: December 2025
Version: 1.0.0