bleedingdeacons / lifelines / 32045079843

95%

push

github

fix: throttle the public lookup endpoint per client (#49)

The search endpoint is registered for wp_ajax_nopriv and, by design,
takes no nonce — it serves read-only public data and a nonce would go
stale behind full-page caching. Nothing bounded how often it could be
called, and every call runs a LIKE '%term%' scan across every searchable
column, where a leading wildcard means no index helps. Cheap once,
expensive in a loop.

A fixed-window per-IP counter now sits in front of it, checked before
the term is read so a refused caller costs one transient read and never
reaches the scan.

The ceiling is deliberately loose — 300 requests a minute — and every
choice here errs towards letting the request through:

  - This backs a helpline finder. Someone using it may be in a bad way,
    and a lookup that refuses to answer is a worse outcome than a
    database working harder than it needs to.
  - The front end debounces at 200ms, so a continuous minute of typing
    stays far below the cap.
  - clientIp() reads REMOTE_ADDR only, never X-Forwarded-For, which the
    caller controls and could use to mint a fresh bucket per request.
    Behind a CDN that means the edge address, so a whole town may share
    one bucket — the cap is sized assuming it does.

Precise per-visitor limiting belongs at the CDN or WAF, which can see
the real client. This is a floor, not that.

The constructor argument is optional so existing callers are unaffected;
there is one sensible implementation and nothing to configure. The
controller's tests now clear transients between cases, since the
endpoint keeps state per client where it previously kept none.

22 of 24 new or added lines in 2 files covered. (91.67%)

313 of 331 relevant lines covered (94.56%)

3.09 hits per line