Portal has no rate limiting
The external portal (portal-access) authorizes solely on an opaque token
(process_portal_links.token, 32 random bytes hex). There is no rate limiting or
brute-force protection on token submission — nothing throttles or locks out repeated
guesses, and every request runs with the service-role client.
32 random bytes is a large space, so online guessing is impractical if tokens stay random
and secret. But with no throttling, no anomaly detection, and tokens that travel in URLs
(logged by proxies, leaked via Referer, sitting in browser history/email), the lack of a
rate limit removes the last line of defence and makes access-log tampering / enumeration
attempts invisible until after the fact.
Related weaknesses in the same path: otp_required exists on the link but is never
enforced; the submission-notification email is a console.log stub; the "public
consultation" link the UI builds (/consulta/:slug) isn't even routed.
Rebuild implication
Rate-limit and monitor token attempts (per-IP and per-token), support the otp_required
second factor, keep tokens out of referrer-leaking URLs where possible (or make them
single-use / short-lived), and alert on anomalous access-log patterns.