Analytics beacons on a city portal accept POSTed events from browsers. What security concern must designers address?
Select an answer to reveal the explanation.
Short Explanation
An open beacon is a mailbox with no lock—spammers will stuff it. Validate, rate-limit, and design so junk cannot poison civic metrics. Hardening the collection edge protects both the pipeline and the decisions that trust it.
Full Explanation
Beacon endpoints that accept POSTed portal events must be hardened so they do not become open spam or fake-traffic injectors poisoning civic metrics. Rate limits, validation, abuse detection, and careful auth patterns protect both the pipeline and decisions that trust it. Collection security is a Cap. 10 requirement for municipalities, not an optional IT flourish.
Leaving collection URLs fully open with no rate limits, auth checks, or validation invites metric pollution and cost attacks. Publishing write credentials for the analytics topic in client-side JavaScript comments exposes the bus to anyone viewing source. Trusting every POST body as a verified resident identity without validation confuses telemetry with authentication on a public portal.
Exam caveat: fully locking beacons like private APIs can be tricky in browsers—use layered controls (origin checks, tokens that are not powerful topic credentials, anomaly detection) rather than a single brittle trick. Operational check: flood a staging beacon with nonsense payloads, confirm rejection or quarantine counters rise, and verify production dashboards do not absorb the junk as citizen traffic. Document the verified decision in the municipal architecture runbook so future on-call and audit staff inherit the same standard.