Chapter 10 — Auth & Security

The why

Authentication without authorization means any logged-in user can do anything. Authorization without authentication is meaningless because you don't know who's asking.

People mix these up constantly. Learn the difference now.

• Authentication = "Who are you?" → Are you a real user with a valid login?
• Authorization = "What are you allowed to do?" → Even if you're logged in, can you approve this order?

JWT — How login works in this project

JWT rules — every one of these matters

1. Use two separate secrets

JWT_ACCESS_SECRET=a_long_random_string_minimum_32_chars
JWT_REFRESH_SECRET=a_completely_different_long_string

If you use one secret for both, a stolen refresh token could be used to forge an access token.

2. Short access token TTL (15 minutes)

JWTs cannot be revoked once issued (unless you build a blocklist). If an access token is stolen, the attacker has it until it expires. 15 minutes limits the damage window.

3. Server-tracked refresh tokens

Store a hash of the refresh token in the database. On every refresh:

• Verify the token exists in the DB
• Invalidate the old one
• Issue a new one (rotation)

Logout = delete the DB row. The refresh token is now invalid everywhere.

4. Never put sensitive data in the JWT payload

The JWT payload is base64-encoded, not encrypted. Anyone who has the token can decode and read it. Safe to put: user_id, role. NOT safe to put: phone numbers, email, account balance.

5. Re-verify user state on sensitive operations

A JWT says "this person was valid 10 minutes ago." Before approving a payment, check the DB:

const user = await this.userModel.findByPk(jwtPayload.sub);
if (!user || !user.is_active || user.is_blocked) {
  throw new UnauthorizedException('

Role-based authorization

export enum Role {
  Admin    = 'admin',
  Maker    = 'maker',
  Checker  = 'checker',
  SuperChecker = 'super-checker',
}
 
// On a controller method
@UseGuards(JwtGuard

For finer-grained rules (e.g. "only the maker who created this order, or any admin"), do the check inside the service:

async approve(user: AuthUser, orderId: string) {
  const order = await this.orderModel.findByPk(orderId);
 
  // Only the assigned checker or any admin can approve
  if (order.checker_id

Password security

Never store plain text passwords

// ❌ Extremely dangerous
await User.create({ password: dto.password });
 
// ✅ Always hash with bcrypt before storing
const hash = await bcrypt.hash(dto.password, 12);

The number 12 is the cost factor — it makes bcrypt intentionally slow. Brute-forcing would take years.

Verifying a password on login

const user = await this.userModel.findOne({ where: { username: dto.username } });
if (!user) throw new UnauthorizedException('Invalid credentials');
 
const

Generating tokens securely

// ❌ Math.random() is NOT cryptographically secure
const resetToken = Math.random().toString(36);
 
// ✅ Use Node's crypto module
import { randomBytes } from 'crypto';
const resetToken = randomBytes(32).toString(

CORS — Cross-Origin Resource Sharing

CORS controls which websites can call your API from a browser.

// ❌ This defeats CORS entirely — any website can call your API
app.enableCors({ origin: true, credentials: true });
 
// ✅ Explicit allowlist
app.enableCors({
  origin: [
    'https://app.quickbite.com',
    'https://admin.quickbite.com',
    '

Helmet — Secure HTTP headers

Add this in main.ts once and forget about it:

import helmet from 'helmet';
app.use(helmet());

Helmet automatically sets headers that protect against common attacks:

SQL Injection — understand it, prevent it

// ❌ Vulnerable — if email = "x' OR '1'='1"
const result = await sequelize.query(
  `SELECT * FROM users WHERE email = '${email}'`
);
// Executes: SELECT * FROM users WHERE email = 'x' OR '1'='1'
// Returns ALL users!
 
// ✅ Safe — parameterized query
const result = await sequelize

Sequelize's model methods (.findAll, .findOne, .create) are parameterized by default — they're safe. The only dangerous place is raw SQL via sequelize.query(). When you must use raw SQL, always use bind parameters.

Never log sensitive data

// ❌ Logs the entire config including JWT_SECRET and DB_PASSWORD
this.logger.log(`Starting with config: ${JSON.stringify(config)}`);
 
// ✅ Log only what's safe
this.logger.log('Application starting', { node_env

Security checklist for every new endpoint

Before you mark an endpoint as done:

• Is @UseGuards(JwtGuard) applied?
• Is the user's permission to access THIS resource checked? (not just "are you logged in")
• Are all inputs validated by a DTO with class-validator?
• Does the output DTO strip sensitive fields?
• Are any raw SQL queries parameterized?
• Are Idempotency keys supported for POST endpoints that create business state?
• Is the Swagger docs updated?

One thing to remember