Security: Enforce max limits and rate limiting on public \/api/prompts\ endpoints

[aniruddhaadak80]

Problem Description

Currently, the public Next.js API endpoints (such as the \GET\ route in \src/app/api/prompts/route.ts) lack essential upper limits on pagination bounds. The \perPage\ query parameter is parsed natively and passed directly to Prisma's \ ake\ mapping without capping.

Without a \Math.min(perPage, 100)\ constraint, any unauthenticated attacker could query /api/prompts?perPage=999999\ resulting in the entire relational dataset being dumped to application memory. This will systematically crash the Next.js Node container (OOM Error) leading to subsequent 500 downtime.

Coupled with a complete absence of rate-limiting middleware, self-hosting environments are extremely vulnerable to scrapers causing DB connection exhaustion.

Proposed Solution

1. Enforce Hard Bounds: Modify \perPage\ to logically default and cap at a maximum threshold:
   \const perPage = Math.min(parseInt(searchParams.get('perPage') || '24'), 100);\
2. Implement Rate Limiting: Introduce Upstash Redis or a standard
   equest-ip\ based map inside a generic API Middleware to limit queries to typical browsing profiles (e.g. 60 requests/minute).

Impact

Significantly hardens server reliability against automated attacks, database bill spikes, and infinite-scroll misconfigurations.