A public parks FAQ site calls an Azure Function HTTP API. What exposure practice is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Public parks FAQ still needs a polite bouncer: tight CORS and least-privilege auth—not master keys in the browser.
Full Explanation
A public parks FAQ site calling an Azure Function HTTP API should use least-privilege authentication and tight CORS restricted to the parks origin. Residents get answers without exposing admin-level keys or allowing arbitrary websites to invoke the municipal FAQ backend.
Enabling wildcard CORS with anonymous admin-level function keys on the internet invites abuse and cross-site calling of privileged operations. Requiring on-prem VPN for every resident phone blocks the public service the FAQ exists to provide. Publishing the Function master key in client-side JavaScript hands attackers host-level control of the Function app.
Exam caveat: public HTTP Function endpoints need defense-in-depth—CORS is browser-enforced only; still use limited keys, Easy Auth, or API Management plus rate limits. Never place master/host keys in front-end code; prefer scoped function keys or anonymous only for truly public read-only operations with throttling.
Operational check: configure CORS for the parks domain only, deploy a scoped key or Entra for the FAQ API (as designed), attempt calls from a disallowed origin and with the master key removed from JS, and verify browsers block bad origins while legitimate FAQ traffic succeeds without host-key exposure.