# Which Parts of DeskcommCRM Are Not Yet Rate-Limited: A Complete Security Audit

> Discover which DeskcommCRM components lack rate limiting. Our security audit reveals exposed internal APIs and CRUD handlers vulnerable to abuse. Understand your risk.

- Repository: [Rafael Melgaço/DeskcommCRM](https://github.com/melgarafael/DeskcommCRM)
- Tags: security-audit
- Published: 2026-09-12

---

**Only authentication endpoints, webhook intake points, and select public API routes implement rate limiting, leaving cron jobs, MCP internal APIs, and most CRUD REST handlers exposed to high-frequency request abuse.**

DeskcommCRM is an open-source customer relationship management platform with a TypeScript-based architecture. While the codebase enforces request throttling for critical entry points, significant portions of the API surface remain unprotected against automated abuse. Understanding exactly which parts of DeskcommCRM are not yet rate-limited is essential for developers deploying this CRM in production environments.

## Currently Protected Surfaces

### Authentication Endpoints

The authentication surface—including **login**, **signup**, **password-reset**, and **invite-accept** flows—enforces rate limiting through [`lib/auth/rate-limit.ts`](https://github.com/melgarafael/DeskcommCRM/blob/main/lib/auth/rate-limit.ts). This module exports the `authRateLimited()` function, which wraps sensitive credential operations to prevent brute-force attacks.

### Webhook Intake and AI Dispatcher

Incoming webhooks and the **AI dispatcher** utilize `checkRateLimit` from [`lib/ai/dispatcher/rate-limit.ts`](https://github.com/melgarafael/DeskcommCRM/blob/main/lib/ai/dispatcher/rate-limit.ts). This generic bucket limiter protects the webhook intake pipeline from being overwhelmed by external event floods.

### Select Public API Routes

Individual routes such as **logo upload** and **WAHA inbound** manually import and invoke `checkRateLimit`. These implementations follow an opt-in pattern rather than applying global middleware across all endpoints.

## Unprotected Endpoints in DeskcommCRM

### Cron Job Handlers (`app/api/v1/cron/*`)

The cron job directory contains scheduled task handlers that execute without any `checkRateLimit` or `authRateLimited` invocations. These endpoints run with request-throttling completely disabled, making them susceptible to manual triggering abuse if cron secrets are exposed.

### MCP Internal Routes (`app/api/internal/**` and `app/api/mcp/**`)

MCP (Model Context Protocol) internal endpoints rely solely on authentication guards. Despite restricting access to authenticated users, routes in `app/api/internal/**` and `app/api/mcp/**` do not invoke any rate-limit logic, allowing unlimited requests against internal APIs.

### Standard CRUD REST Handlers (`app/api/v1/*`)

Most REST handlers in `app/api/v1/*` follow a predictable pattern: **Zod validation** → **RBAC authorization** → **database query** → **response** via `ok()` or `fail()`. None of these standard CRUD implementations embed rate-limit checks, leaving the primary data API exposed to high-frequency automation.

### Background Workers (`workers/*`)

Worker processes execute asynchronously without exposing a public HTTP surface. While not applicable to HTTP rate limiting, these processors in `workers/*` also lack internal throttling mechanisms for job execution frequency.

## Implementing Rate Limits on Missing Surfaces

Developers can secure unprotected routes using the existing `checkRateLimit` utility from [`lib/ai/dispatcher/rate-limit.ts`](https://github.com/melgarafael/DeskcommCRM/blob/main/lib/ai/dispatcher/rate-limit.ts). The function accepts a key identifier, maximum requests, and window duration in seconds.

**Applying rate limiting to a new API route:**

```typescript
import { checkRateLimit } from "@/lib/ai/dispatcher/rate-limit";

export async function GET(request: Request) {
  // 30 calls per minute per authenticated organization
  const orgId = await getOrganizationIdFromRequest(request);
  const rl = await checkRateLimit(`org:${orgId}:my-endpoint`, 30, 60);
  if (!rl.allowed) {
    return fail("RATE_LIMIT_EXCEEDED", "Muitas requisições, tente novamente mais tarde", 429);
  }

  // …rest of handler logic…
}

```

**Adding rate limiting to a cron job:**

```typescript
// app/api/v1/cron/sync-leads/route.ts
import { checkRateLimit } from "@/lib/ai/dispatcher/rate-limit";

export async function POST() {
  // Limit cron executions to 1 run per 5 minutes per tenant
  const orgId = process.env.CRON_TENANT_ID!;
  const rl = await checkRateLimit(`cron:${orgId}:sync-leads`, 1, 300);
  if (!rl.allowed) return fail("RATE_LIMIT_EXCEEDED", "Cron acionado demais", 429);

  // …cron work…
}

```

## Summary

- **Authentication and webhooks**: Protected by `authRateLimited()` in [`lib/auth/rate-limit.ts`](https://github.com/melgarafael/DeskcommCRM/blob/main/lib/auth/rate-limit.ts) and `checkRateLimit` in [`lib/ai/dispatcher/rate-limit.ts`](https://github.com/melgarafael/DeskcommCRM/blob/main/lib/ai/dispatcher/rate-limit.ts).
- **Cron jobs**: Located in `app/api/v1/cron/*`, currently execute without any rate-limit protection.
- **MCP internal APIs**: Routes in `app/api/internal/**` and `app/api/mcp/**` lack throttling despite authentication requirements.
- **Standard CRUD**: Most `app/api/v1/*` handlers follow validation-RBAC-query patterns without embedding rate-limit checks.
- **Remediation**: Import `checkRateLimit` from [`lib/ai/dispatcher/rate-limit.ts`](https://github.com/melgarafael/DeskcommCRM/blob/main/lib/ai/dispatcher/rate-limit.ts) to add protection to unprotected surfaces.

## Frequently Asked Questions

### Is the DeskcommCRM authentication system rate-limited?

Yes. The authentication surface—including login, password reset, and signup endpoints—implements strict rate limiting via [`lib/auth/rate-limit.ts`](https://github.com/melgarafael/DeskcommCRM/blob/main/lib/auth/rate-limit.ts) and the `authRateLimited()` function to prevent credential stuffing and brute-force attacks.

### Why are cron jobs in DeskcommCRM not rate-limited?

Cron jobs in `app/api/v1/cron/*` are designed for internal server-to-server communication and currently lack `checkRateLimit` invocations. While this reduces complexity for scheduled tasks, exposed cron endpoints remain vulnerable to manual abuse if trigger URLs are discovered.

### Which file contains the main rate-limiting logic?

The primary rate-limiting implementations reside in two locations: [`lib/auth/rate-limit.ts`](https://github.com/melgarafael/DeskcommCRM/blob/main/lib/auth/rate-limit.ts) for authentication-specific throttling, and [`lib/ai/dispatcher/rate-limit.ts`](https://github.com/melgarafael/DeskcommCRM/blob/main/lib/ai/dispatcher/rate-limit.ts) for the generic `checkRateLimit` function used by webhooks and API routes.

### How can I protect a new API endpoint in DeskcommCRM?

Import `checkRateLimit` from `@/lib/ai/dispatcher/rate-limit` and invoke it at the beginning of your route handler. Pass a unique key (such as `org:${orgId}:endpoint-name`), a maximum request count, and a time window in seconds to enforce limits before processing business logic.