Claude's API now supports CORS requests, enabling client-side applications

Original Article ↗ Hacker News Discussion ↗

Client-side Claude API & CORS

  • Many welcome CORS support because it finally enables direct browser use (extensions, small tools) without custom proxies.
  • Some note this was always technically possible via a simple proxy, but native CORS still removes friction.
  • A few mention prior breakage when Anthropic SDKs blocked browser use; this change reverses that.

Security & API Keys in the Browser

  • Strong recurring warning: never ship your own production API keys to the client; they will be discoverable and abusable.
  • Some think it’s acceptable for internal tools or trusted coworkers; others argue the leak/audit risk is still too high.
  • Concern that normalizing “paste your secret into random webpages” trains users into bad security habits and aids phishing.

“Bring Your Own Key” (BYOK) Pattern

  • Many hobby/indie devs like BYOK: zero infra cost, no key custody, simple static apps, and low maintenance.
  • UX downside: confusing for non-technical users; better suited to a niche of power users.
  • Security concerns remain: users must trust that the app (and its hosting) won’t exfiltrate their keys, even if client-only and open source.
  • Suggestions: provider features like per-key spending caps, app-specific/limited keys, or budgeted keys to reduce blast radius.

OAuth2, JWTs, and Alternative Auth Models

  • Multiple comments argue OAuth2 (or similar) is a better fit: users authorize apps without sharing keys directly; scopes and limits can be fine-grained.
  • Others push back that OAuth adds complexity, can be awkward for headless/automation use, and that many devs barely understand existing token systems.
  • Proposals include JWT-based user-scoped keys, “Login with {AI provider}” flows, and even revenue sharing/app-store-style models.

CORS, Same-Origin Policy & Web Security Debate

  • Long subthread explains CORS as a compatibility layer over the same-origin policy, mostly controlling who can read responses, not who can send requests.
  • Discussion covers cookies, CSRF, intranet access, preflights, and “simple requests,” with disagreement over how much CORS actually improves security vs being messy “security theater.”
  • Some suggest alternative designs (e.g., no third-party cookies, credential-free cross-origin fetches) but acknowledge existing web compatibility constraints.