AI Security Auditing, Part 2: Audit Authentication & Sessions With AI

AI Security Auditing series — Part 2 of 5. Part 1: Setup · Part 2: Authentication · Part 3: API & OWASP · Part 4: Injection & XSS · Part 5: Runtime detections

Authentication is where the highest-value attacks land, so it's where most teams should start. If an attacker can take over an account, nothing else in your security model matters. In this part we audit the whole authentication surface with an AI agent, then set up to catch the attacks the code can't prevent.

If you haven't set up your agent yet, do Part 1 first.

The authentication threat surface

"Authentication" is bigger than the login form. A real audit has to cover every path that can end in a session:

• Login — rate limiting, account lockout, credential stuffing and brute-force resistance, username/password enumeration via timing or error messages.
• Sessions — cookie flags (HttpOnly, Secure, SameSite), session fixation, rotation on privilege change, absolute and idle timeouts, revocation.
• Password reset — token entropy, single-use enforcement, expiry, and whether the reset link leaks in referrers or logs.
• Magic links / passwordless — enumeration of valid emails, token brute force on the callback, and inbox-flooding abuse.
• MFA — whether it can be skipped, replayed, or bypassed on a secondary flow.
• Account takeover chains — the combinations: reset + weak MFA, or session fixation + a login CSRF.

Checking all of this by hand, across every route, is exactly the tedious, easy-to-skip work an AI reviewer is good at.

Run the audit

Go to /threat-modeling/authentication and click Copy prompt. Paste it into your agent at the project root.

The prompt maps to OWASP A07 (Identification & Authentication Failures), A01 (Broken Access Control), and API2 (Broken Authentication). It tells the agent to inventory your auth code, enumerate the threats above against your actual implementation, and audit each file.

When it finishes, open threat/authentication/authentication-code-findings.html.

What the findings look like

A typical authentication audit surfaces items like:

• No rate limit on /api/auth/signin — routes/auth.js:42, high severity. Nothing stops an attacker from trying thousands of passwords.
• Session cookie missing SameSite — lib/session.js:18, medium. Opens CSRF and some session-fixation paths.
• Password-reset token is a timestamp-based value — services/reset.js:71, high. Guessable tokens mean anyone can reset anyone's password.
• Magic-link callback accepts unlimited attempts — routes/auth.js:96, high. The verification token can be brute-forced.
• MFA check skipped when remember_device is set — middleware/mfa.js:33, high. A secondary flow bypasses the primary control.

Each points at a real location in your code. Confirm the high-severity ones, apply the fixes, and re-run the audit to verify they're gone.

Code fixes close holes; detection catches attempts

Here's the authentication-specific version of the rule that runs through this whole series: fixing the code is necessary but not sufficient.

You can add a rate limit and rotate to high-entropy reset tokens — and you should — but you still won't know when someone is running a credential-stuffing list against you right now, or slow-brute-forcing one high-value account under your rate limit. That requires runtime detection.

Open the other report, authentication-detection-mitigation.html. It gives you the detection logic in plain terms: flag a single IP flooding the signin endpoint, flag one account seeing failed logins from many IPs (distributed brute force), flag magic-link callback abuse. In Part 5 we turn these into always-on rules with securenow alerts rules create.

If you want to skip ahead on the detection side, these existing walkthroughs pair perfectly with this audit:

• Detecting credential stuffing in Express in 30 lines
• Credential-stuffing detection for the SOC

A concrete example: magic-link abuse

Passwordless login has a specific abuse surface: a single IP hammering the request endpoint to flood a victim's inbox, or hammering the callback to brute-force verification tokens. The audit will flag the missing limits in code; the detection half will hand you a rule that flags any IP making 20+ requests to the auth endpoints in 15 minutes. Together they cover both the "fix it" and the "watch it" sides of the same threat. We build exactly that rule in Part 5.

Checklist before you move on

• Ran the authentication prompt and reviewed authentication-code-findings.html
• Confirmed and fixed all high-severity findings
• Re-ran the audit to verify fixes
• Skimmed authentication-detection-mitigation.html for the rules to add later
• Committed the .md reports to version control

Next

Authentication proves who a user is. Authorization decides what they're allowed to touch — and it's where the single most common API vulnerability lives (BOLA). That's the heart of Part 3.

Continue to Part 3 — Audit your API against the OWASP API Top 10 →