mediumLogins, sessions and access

Login Endpoint Without Rate Limiting

Authentication endpoints can be called without limit.

Why it matters

Login and reset endpoints are the ones attackers hit with lists of leaked passwords. A limit of a few attempts per minute per address stops that outright and is invisible to real users. NestJS ships a throttler module; it is one import and one decorator.

What it looks like

This is the shape of code that triggers the rule. AI tools produce it because it works, and nothing tells them it is unsafe.

Login handler with no throttling
@Controller('auth')
export class AuthController {
  @Post('login')
  login(@Body() dto: LoginDto) {
    return this.auth.login(dto);
  }
}

The smallest fix

minimal patch
// app.module.ts
ThrottlerModule.forRoot([{ ttl: 60000, limit: 10 }]),
providers: [{ provide: APP_GUARD, useClass: ThrottlerGuard }],

// auth.controller.ts
@Throttle({ default: { limit: 5, ttl: 60000 } })
@Post('login')
login(@Body() dto: LoginDto) { ... }

The better fix

If you have a few more minutes, this is the approach that holds up as the app grows.

safe alternative
// Add a per-account lockout or backoff after repeated failures, and
// log failed attempts so brute-force attempts are visible.

Let your AI tool fix it

When the scanner finds this in your project, it fills in the file and line for you. This is the prompt it gives you to paste into Claude Code, Cursor or whatever you use.

In [the file] at line [the line number] an authentication endpoint has no rate limit: [the flagged code]. Add @nestjs/throttler with ThrottlerModule.forRoot and ThrottlerGuard as APP_GUARD, and put a tighter @Throttle on the login, register, reset and OTP handlers.

How to check the fix worked

1. Send 20 login requests in quick succession and confirm the later
   ones return 429.
2. Confirm a normal login still succeeds.

Further reading