This content originally appeared on DEV Community and was authored by Ofri Peretz
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.
The prompt
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.
What Claude Sonnet 4.6 generated
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.
What Gemini 2.5 Flash generated
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().
Side by side
| 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 |
Why the gap
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.
The finding both got wrong: rate limiting
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's unique finding: hardcoded JWT secret
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.
What this means for prompting
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.
The config (runs on output from either model)
// 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:
← Claude Wrote a NestJS Service. TypeScript Was Happy. ESLint Found 6 Security Holes. | Aggregate Benchmarks Lie →
📦 eslint-plugin-nestjs-security · Rule docs
GitHub | X | LinkedIn | Dev.to | ofriperetz.dev
This content originally appeared on DEV Community and was authored by Ofri Peretz
Ofri Peretz | Sciencx (2026-05-30T01:36:35+00:00) I Ran the Same NestJS Prompt on Claude and Gemini. One Got 6 Security Errors. Here’s What Both Missed.. Retrieved from https://www.scien.cx/2026/05/30/i-ran-the-same-nestjs-prompt-on-claude-and-gemini-one-got-6-security-errors-heres-what-both-missed/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.