I Ran the Same NestJS Prompt on Claude and Gemini. One Got 6 Security Errors. Here's What Both Missed.

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

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 :

←

📦

| |