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

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. 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. 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. The function accepts a key identifier, maximum requests, and window duration in seconds.

Applying rate limiting to a new API route:

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:

// 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 and checkRateLimit in 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 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 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 for authentication-specific throttling, and 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}