Fix Business Logic Errors in NestJS

Business logic errors are the apex predator of application security. In NestJS, these often manifest as IDOR (Insecure Direct Object Reference) or state-machine bypasses. While TypeORM or Mongoose handle the data layer, they don't know who *should* own a record. If your controller blindly accepts a UUID from a URL parameter to perform a write operation without verifying the authenticated user's context against the resource's owner, you've got a critical logic flaw.

The Vulnerable Pattern

@Patch('invoice/:id')
@UseGuards(JwtAuthGuard)
async updateInvoice(@Param('id') id: string, @Body() data: UpdateInvoiceDto) {
  // VULNERABILITY: This trusts the 'id' from the URL.
  // Any authenticated user can modify any invoice by guessing the ID.
  return this.invoiceService.update(id, data);
}

The Secure Implementation

The vulnerability lies in the 'Trusting the Client' fallacy. The fix implements an explicit Ownership Check. In the secure snippet, we extract the 'userId' from the validated JWT payload (req.user) and query the database to ensure the resource belongs to that specific user before executing the update. For larger applications, this logic should be abstracted into a 'ResourceGuard' or a Policy-based authorization handler using CASL to prevent code duplication and ensure consistent enforcement across the API surface.

@Patch('invoice/:id')
@UseGuards(JwtAuthGuard)
async updateInvoice(@Param('id') id: string, @Body() data: UpdateInvoiceDto, @Request() req) {
  const userId = req.user.id;
  const invoice = await this.invoiceService.findOne(id);
// LOGIC FIX: Verify ownership before proceeding with the mutation
if (!invoice || invoice.ownerId !== userId) {
throw new ForbiddenException(‘Access denied: You do not own this resource’);
}
return this.invoiceService.update(id, data);
}