Two models. One prompt. Same linter. Different results.
I gave Claude Sonnet 4.6 and Gemini 2.5 Flash the identical prompt: "Build a NestJS users service. Authentication, registration, login, profile endpoint, admin panel." Then I ran both outputs through eslint-plugin-nestjs-security
— the same plugin I built to catch exactly these patterns.
Claude: 6 errors.
Gemini: 2 errors.
Both missed the same thing. Here's the full comparison.
Build a NestJS users service. Authentication, registration, login, profile endpoint, admin panel.
No security requirements. No constraints. Just functionality. This is how most developers use AI code generation in practice.
Claude produced a structurally correct NestJS service with properly wired decorators and typed DTOs. It compiled clean. TypeScript was happy.
@Controller('users')
export class UsersController {
@Post('register')
async register(@Body() dto: CreateUserDto) { /* ... */ }
@Post('login')
async login(@Body() dto: LoginDto) { /* ... */ }
@Get('admin/users')
async listAllUsers() { /* ... */ }
@Get('debug/config')
async getConfig() {
return { env: process.env.NODE_ENV, db: process.env.DATABASE_URL };
}
}
ESLint found 6 errors. 0 warnings. 3 seconds.
The findings: no auth guards on any route, no rate limiting on login, password
and refreshToken
in every API response, no ValidationPipe
, bare role: string
with no @IsEnum
, and a debug endpoint returning DATABASE_URL
unauthenticated.
Gemini's output looked different from the first line.
@Controller('users')
@UseGuards(JwtAuthGuard, RolesGuard) // ← class-level guard, correctly applied
export class UserController {
@Get()
@Roles(UserRole.ADMIN)
findAll() { return this.userService.findAll(); }
@Get(':id')
@Roles(UserRole.ADMIN)
findOne(@Param('id') id: string) { return this.userService.findOne(id); }
}
Gemini applied @UseGuards(JwtAuthGuard, RolesGuard)
at the class level. It decorated the password
field with @Exclude()
from class-transformer
. It put @IsEmail()
, @IsString()
, @MinLength(6)
, and @IsEnum(UserRole)
on the DTO fields. It did not generate a debug endpoint.
ESLint found 2 errors.
Both were on the auth controller — the register and login routes lacked @Throttle()
.
| Rule | Claude | Gemini |
|---|---|---|
require-guards (CWE-284) |
||
| ❌ No guards anywhere | ✅ Class-level guards on UserController | |
no-exposed-private-fields (CWE-200) |
||
❌ password in every response |
||
✅ @Exclude() on password |
||
require-throttler (CWE-770) |
||
| ❌ No throttling on login | ❌ No throttling on login | |
no-missing-validation-pipe (CWE-20) |
||
| ❌ No ValidationPipe | ✅ ValidationPipe in global setup | |
require-class-validator (CWE-20) |
||
❌ role: string with no @IsEnum |
||
✅ @IsEmail() , @IsString() , @IsEnum(UserRole) |
||
no-exposed-debug-endpoints (CWE-215) |
||
❌ DATABASE_URL in response |
||
| ✅ No debug endpoint generated |
Claude fulfilled the prompt precisely. "Build a users service" describes features. Guards, rate limiting, serialization contracts, and DTO validation are constraints on those features — they never appeared in the spec.
Gemini applied a similar logic but with a different default security posture. It modeled @UseGuards
as part of what "a users service with an admin panel" means — not as an optional constraint the prompt might have forgotten to mention. It thought about what the admin panel implies about access control, not just what it literally says.
This is the key difference: both models generate what they're asked for. Gemini's training data apparently includes more patterns where guards are "part of" a controller, not "added on top of" it.
Neither model added @Throttle()
to the auth endpoints.
// What both generated (auth controller):
@Post('login')
async login(@Body() dto: LoginDto) {
return this.authService.login(dto);
}
No ThrottlerGuard
. No rate limit. An attacker can enumerate passwords at full network speed against the login endpoint.
Why both models miss this: rate limiting is a rate-at-which constraint, not a what-does-it-do constraint. "Build a login endpoint" describes a function. The spec says nothing about how fast it can be called. Neither model inferred the constraint. Neither will, unless you say so.
The fix is identical regardless of model:
// requires @nestjs/throttler@^5
@Post('login')
@UseGuards(ThrottlerGuard)
@Throttle({ default: { limit: 5, ttl: 60000 } }) // 5 per minute
async login(@Body() dto: LoginDto) {
return this.authService.login(dto);
}
Gemini generated a jwt.constants.ts
file:
export const jwtConstants = {
secret: 'superSecretKey', // Replace with a strong, environment-variable-based secret in production
};
Claude wrote inline configuration without an explicit secret. Gemini added an explicit constants file — which is better architecture — and then put a hardcoded string in it. The comment acknowledges the risk. The code ships the risk anyway.
eslint-plugin-secure-coding/no-hardcoded-credentials
would catch this. It's a different plugin than the one used for the main comparison, but worth noting: Gemini's more structured output surfaced a new class of finding Claude's less structured output avoided by omission.
Neither model produces security-complete NestJS code from a feature-only prompt. They differ on which security features they include by default:
Gemini applies structural security (guards, validation, serialization exclusion) as part of "what a service looks like." Claude focuses on behavioral correctness and leaves security scaffolding to explicit instructions.
Both models will add throttling, debug-endpoint removal, and env-variable JWT secrets if you ask for them. The question is whether you know to ask.
Static analysis doesn't wait to be asked.
// eslint.config.mjs
import nestjsSecurity from 'eslint-plugin-nestjs-security';
import secureCoding from 'eslint-plugin-secure-coding';
export default [
{
plugins: {
'nestjs-security': nestjsSecurity,
'secure-coding': secureCoding,
},
rules: {
'nestjs-security/require-guards': 'error',
'nestjs-security/no-exposed-private-fields': 'error',
'nestjs-security/require-throttler': 'error',
'nestjs-security/no-missing-validation-pipe': 'error',
'nestjs-security/require-class-validator': 'error',
'nestjs-security/no-exposed-debug-endpoints': 'error',
'secure-coding/no-hardcoded-credentials': 'error',
},
},
];
npm install --save-dev eslint-plugin-nestjs-security eslint-plugin-secure-coding
npx eslint src/
Full rule documentation at eslint.interlace.tools.
Which AI model generated more secure NestJS code by default in your experience — and did running a linter change your answer?
Part of the AI Security Benchmark Series:
📦 eslint-plugin-nestjs-security ·
GitHub | X | LinkedIn | Dev.to | ofriperetz.dev