What Could Go Wrong

You built auth. Now defend it.

If you completed the “Authentication with Hectoday HTTP” course, you have a working app with signup, login, sessions, JWTs, and role-based access control. It handles the happy path: users sign up, log in, access their data, and log out.

But an app in production faces adversaries. People will try to break in, abuse your endpoints, and exploit mistakes in your auth logic. This course adds the defenses.

The attacks

Here is what your app is currently vulnerable to, and what we will fix.

Brute-force login

An attacker tries thousands of passwords against a single account. They start with common passwords (“password123”, “qwerty”, “letmein”) and move on to dictionary attacks. Your login endpoint responds to every attempt, and nothing stops them from trying as fast as their connection allows.

What we will build: Rate limiting that caps how many login attempts an IP or email can make per minute. Account lockout that temporarily disables an account after repeated failures.

Credential stuffing

An attacker obtains a list of email/password pairs from a breach of a different service. They try each pair against your login endpoint. Since people reuse passwords, some will work. This is not brute-force (guessing random passwords); it is replaying known credentials at scale.

What we will build: The same rate limiting and lockout defenses. Credential stuffing and brute-force look the same to your server: repeated login failures.

Session hijacking

An attacker steals a user’s session cookie. This can happen through XSS (injecting JavaScript that reads document.cookie), network interception (unencrypted HTTP traffic), or physical access to the user’s browser.

The auth course already mitigated this with HttpOnly (prevents JavaScript access) and the recommendation to use Secure (HTTPS only). In this course, we add more layers: security headers that reduce XSS risk, and session management that limits the damage if a session is stolen.

Cross-site request forgery (CSRF)

An attacker tricks a logged-in user into submitting a request to your app without their knowledge. The browser automatically attaches the session cookie, so the request looks legitimate. The auth course used SameSite=Lax on cookies, which blocks most CSRF vectors. But “most” is not “all.”

What we will build: CSRF tokens for the cases where SameSite=Lax is not sufficient. Custom header verification for API consumers.

Token theft

If a JWT access token is stolen (from localStorage, from a log file, from a network intercept), the attacker can use it until it expires. The auth course’s tokens last 24 hours, which gives an attacker an entire day.

What we will build: Short-lived access tokens (15 minutes) with refresh token rotation. Token revocation for emergency cases.

Password reset abuse

Without a password reset flow, users who forget their password are locked out forever. But a poorly implemented reset flow is worse: it can be used to take over accounts, enumerate which emails are registered, or flood users with reset emails.

What we will build: A secure password reset flow with time-limited, single-use, hashed tokens.

What this course is not

This course hardens authentication. It does not cover:

• Application-level security (SQL injection, XSS prevention in templates, input sanitization). These are important but are separate topics from auth.
• Infrastructure security (firewall configuration, DDoS protection, TLS certificate management). These happen outside your application code.
• Compliance (GDPR, SOC 2, HIPAA). These are organizational and legal concerns, not code patterns.

We focus on what you can do in your auth code to make attacks harder, slower, and less rewarding.

The approach

Every defense in this course follows the same pattern: understand the attack, then write a plain function that prevents it. No security frameworks, no middleware libraries. Just functions you call in your handlers, the same Hectoday pattern you already know.