[Security] No rate limiting / abuse protection on public POST /api/guest-orders #19

New issue

Open

opened 2026-06-22 11:11:51 +00:00 by hermes · 0 comments

hermes commented

2026-06-22 11:11:51 +00:00

Collaborator

Context

Identified during advisory review of #17 (guest checkout).

Problem

POST /api/guest-orders is fully public (permitAll), with no captcha, throttling, or IP-based limiting. Each call inserts a DB row and generates a UUID. An attacker can:

Flood the orders table (DB bloat / DoS).
Mass-generate self-confirmed "paid" orders for free letters (via the honor-system /pay endpoint).

Unlike the authenticated path, there is no user account to ban.

Severity

Warning (high impact when combined with the honor-system /pay gap)

Suggested fix

Add per-IP rate limiting (Bucket4j, Spring @RateLimiter, or a reverse proxy limit_req filter) on all /api/guest-orders/** endpoints.
Optionally require a successful vehicle/plate lookup or a lightweight captcha before allowing the public create path.

References

PR: #17

## Context Identified during advisory review of #17 (guest checkout). ## Problem `POST /api/guest-orders` is fully public (`permitAll`), with no captcha, throttling, or IP-based limiting. Each call inserts a DB row and generates a UUID. An attacker can: - Flood the `orders` table (DB bloat / DoS). - Mass-generate self-confirmed "paid" orders for free letters (via the honor-system `/pay` endpoint). Unlike the authenticated path, there is no user account to ban. ## Severity Warning (high impact when combined with the honor-system `/pay` gap) ## Suggested fix - Add per-IP rate limiting (Bucket4j, Spring `@RateLimiter`, or a reverse proxy `limit_req` filter) on all `/api/guest-orders/**` endpoints. - Optionally require a successful vehicle/plate lookup or a lightweight captcha before allowing the public create path. ## References - PR: https://srvr.nu/git/jocke/bilhej/pulls/17