Practice & Assessment
Test your understanding of Security Hardening
Multiple Choice Questions
6An attacker uses a botnet of 10,000 IPs to brute-force a login endpoint, sending one request per IP. Which rate limiting strategy stops this?
Which of the following requests is NOT protected by SameSite=Lax on a session cookie?
Why should you reject passwords longer than 1000 characters on a bcrypt-based auth system?
What does the X-Content-Type-Options: nosniff header prevent?
A verification token is generated with Math.random() instead of crypto.randomBytes. What is the security risk?
Which Helmet.js header specifically prevents your login page from being embedded in an iframe on a malicious site?
Coding Challenges
1Add layered rate limiting to a login route
Extend an existing Express login route with two layers of rate limiting. Layer 1: use express-rate-limit to limit to 20 requests per IP per 15-minute window, skipping successful requests. Layer 2: implement a manual per-email counter using a JavaScript Map (no Redis needed) that locks an email for 15 minutes after 5 consecutive failures, resetting on success. The locked-out response must include a Retry-After header. Input: POST /auth/login with email and password. Output: 200 on success, 401 on wrong credentials, 429 with Retry-After on rate limit. Constraint: use module-level Map for storage, no database required. Estimated time: 20–25 minutes.
Mini Project
Hardened Auth API Security Audit and Fixes
Take the session-based auth system from Module 2 and apply all security hardening from this module. Checklist: add Helmet.js with a custom CSP that blocks inline scripts; add express-rate-limit with per-IP limiting on all auth routes; implement per-email rate limiting using Redis (or a Map mock) with lockout after 5 failures; add express-validator on register and login routes with clear error messages; add CSRF token generation and validation on the login route; implement email verification with crypto.randomBytes tokens stored in the database and a /verify endpoint. Document each change and the attack it prevents in a SECURITY.md file.