Skip to content

Security: Marlinsk/nodejs-authentication-backend

Security

SECURITY.md

Security Updates and Improvements

This document outlines the security improvements implemented in version 2.1.0 of the Node.js Authentication Backend.

πŸ”’ Security Enhancements

1. HTTP Security Headers (Helmet)

  • Implemented helmet middleware to set secure HTTP headers
  • Protection against common web vulnerabilities (XSS, clickjacking, etc.)
  • Helps enforce HTTPS and prevent MIME-type sniffing

2. Rate Limiting

  • General Rate Limit: 100 requests per 15 minutes per IP
  • Authentication Rate Limit: 5 login attempts per 15 minutes per IP
    • Applied to: /login, /register, /password/*
    • Prevents brute force attacks
    • Skips counting successful requests

3. Enhanced CORS Configuration

  • Development: Open CORS for easier local development
  • Production: Whitelist-based CORS
    • Configure allowed origins via ALLOWED_ORIGINS environment variable
    • Supports credentials
    • Restricted HTTP methods and headers

4. Request Body Size Limiting

  • Maximum request body size: 10KB
  • Prevents DoS attacks via large payloads

5. Stronger Password Requirements

  • Minimum 8 characters (previously 6)
  • Must contain:
    • At least one uppercase letter
    • At least one lowercase letter
    • At least one number
    • At least one special character (@$!%*?&#)

6. Improved Bcrypt Salt Rounds

  • Increased from 8 to 12 rounds
  • Stronger protection against brute force attacks
  • Industry-standard security level

7. Input Validation and Sanitization

  • Implemented express-validator for all endpoints
  • Validators for:
    • User registration and authentication
    • Password reset requests
    • Two-factor authentication
    • OAuth flows
  • Prevents injection attacks (SQL, NoSQL, XSS)
  • Normalizes and sanitizes email inputs
  • Validates data types, lengths, and formats

8. OAuth CSRF Protection

  • Implemented state parameter validation
  • State tokens stored server-side with expiration (10 minutes)
  • One-time use tokens (removed after validation)
  • Automatic cleanup of expired states
  • Protection against CSRF attacks in OAuth flow

9. Enhanced Error Handling

  • Stack traces only shown in development mode
  • Production mode hides internal error details
  • Structured error logging for debugging
  • No sensitive information leaked to clients

10. JWT Secret Security

  • Updated .env.example with strong secret generation instructions
  • Recommends using openssl rand -base64 32
  • Warns against weak secrets

πŸ›‘οΈ Security Best Practices

Environment Variables

Always set strong, random values for:

  • JWT_SECRET - At least 32 characters, cryptographically random
  • ALLOWED_ORIGINS - Comma-separated list of allowed domains in production
  • NODE_ENV - Set to "production" in production environments

Password Policy

Users must create passwords that:

  • Are at least 8 characters long
  • Include uppercase and lowercase letters
  • Include at least one number
  • Include at least one special character

Rate Limiting Configuration

Adjust rate limits based on your use case:

// In src/infrastructure/http/app.ts
const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100, // Adjust based on expected traffic
});

const authLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5, // Adjust based on security requirements
});

Production Deployment Checklist

  • Set NODE_ENV=production
  • Generate strong JWT_SECRET (minimum 32 characters)
  • Configure ALLOWED_ORIGINS with your frontend domains
  • Enable HTTPS/TLS
  • Review and adjust rate limiting based on traffic
  • Enable logging to monitor suspicious activities
  • Keep dependencies updated regularly
  • Implement proper database security (encryption at rest, secure connections)
  • Use environment-specific configurations
  • Set up monitoring and alerting for security events

πŸ” OWASP Top 10 Protection

This implementation addresses the OWASP Top 10 security risks:

  1. Broken Access Control - JWT authentication, role-based access (if implemented)
  2. Cryptographic Failures - Bcrypt with 12 salt rounds, strong password requirements
  3. Injection - Input validation and sanitization with express-validator
  4. Insecure Design - Secure architecture with Clean Architecture + DDD
  5. Security Misconfiguration - Helmet headers, secure CORS, environment-based configs
  6. Vulnerable Components - Regular dependency updates recommended
  7. Authentication Failures - Rate limiting, strong passwords, 2FA support, secure JWT
  8. Software and Data Integrity Failures - No eval(), proper error handling
  9. Security Logging Failures - Winston logging system with structured logs
  10. Server-Side Request Forgery - OAuth state validation, input validation

πŸ“ Validation Rules

User Registration

  • Name: 2-100 characters, letters and spaces only
  • Username: 3-30 characters, alphanumeric and underscores only
  • Email: Valid email format, normalized
  • Password: Strong password requirements

Authentication

  • Email: Valid email format
  • Password: Required (no validation on login to prevent information disclosure)

Password Reset

  • Token: 32-128 characters
  • New Password: Strong password requirements

Two-Factor Authentication

  • TOTP Token: Exactly 6 digits
  • Backup Code: 8-12 characters

OAuth

  • Provider: Must be one of: github, google, facebook
  • Code: Required authorization code
  • State: 32-128 characters, validated against stored states

🚨 Security Incident Response

If you discover a security vulnerability, please:

  1. Do NOT open a public issue
  2. Email the maintainer with details
  3. Allow time for a fix before public disclosure

πŸ“š References

There aren’t any published security advisories