ブラウザで API 呼び出しがブロックされる理由（そして 12 リンズの JavaScript でどう修正するか）

開発者の最初の API 統合を殺す CORS エラー—そしてこれを永続的に解決するサーバーレスプロキシパターン もしブラウザから外部 API を直接呼び出すプロジェクトを作り、次のエラーを見ていたのであれば： TypeError: Failed to fetch Access to fetch at 'https://api.example.com' from origin 'https://yourapp.com' has been blocked by CORS policy この記事はあなたのためにあります。 私は RevenueCat の Charts API を使用してライブサブスクリプションダッシュボードを作った際、この壁に直面しました。API は完璧に機能します。ダッシュボードも完璧に機能します。しかし、ブラウザから呼び出すと、利用価値のある説明なしの静かなネットワークエラーが発生します。 正確に何が起きているか、なぜそれが実際には正しい動作なのか、そして JavaScript の 12 ラインでどう修正するかをご説明します。 CORS（Cross-Origin Resource Sharing）は、ウェブページがそのページを提供したドメインとは異なるドメインに対してリクエストを行うことを防止するブラウザのセキュリティメカニズムです。 あなたのアプリ（yourapp.netlify.app）が api.revenuecat.com にアクセスしようとするとき、ブラウザはまずこの API に対して「Hey、このオリジンからのリクエストを許可しますか？」と尋ねるプレフライトリクエストを先頭に送ります。 もし API が適切なヘッダー—特に Access-Control-Allow-Origin—not 返さない場合、ブラウザは完全にリクエストをブロックします。サーバーではない。ブラウザが。 これは重要です：最も多くの場合、API 呼び出しはまずブラウザによって殺され、サーバーには一度も到達しません。 ここが誰も説明しない部分です：ある API は意図的にブラウザリクエストをブロックしています。RevenueCat の Charts API はその一つです。 理由は簡単です。Charts API は高度な権限を持つシークレット v2 キーを必要とします。シークレットキーは決してクライアント側コードに含まれるべきではなく—誰でも DevTools を開いてネットワークタブを確認すれば見られます。 CORS ヘッダーを追加しないことで、RevenueCat は良いセキュリティプラクティスを強制しています。彼らは言っているのです：このキーはサーバーに属しており、ブラウザには含まれないべきです。 つまり、CORS エラーはバグではありません。API はあなたに「このリクエストをルーティングするにはサーバーを経由してください」と伝えているだけなのです。 解決策はプロキシです—ブラウザと API の間に位置する小さなサーバー側関数です。あなたのブラウザはプロキシを呼び出します（同じオリジンで、CORS 問題なし）。プロキシはシークレットキーを環境変数に持ち込み、適切な認証と共に API へリクエストを転送します。 Netlify Functions を使用した完全なパターンのここでは: your-project/ netlify/ functions/ rc-proxy.js ← 作成する index.html // netlify/functions/rc-proxy.js exports.handler = async (event) => { const { path, params } = JSON.parse(event.body); const url = `https://api.revenuecat.com/v2${path}?${new URLSearchParams(params)}`; const res = await fetch(url, { headers: { 'Authorization': `Bearer ${process.env.RC_API_KEY}`, 'Content-Type': 'application/json' } }); return { statusCode: res.status, body: JSON.stringify(await res.json()) }; }; Netlify ダッシュボードで：Site Settings → Environment Variables → Add variable Key: RC_API_KEY Value: your_secret_api_key_here あなたのキーはブラウザに触れることがありません。Netlify の暗号化された環境変数ストアに存在します。 // ブラウザ側の JavaScript async function fetchChart(projectId, chartName, params) { const res = await fetch('/.netlify/functions/rc-proxy', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ path: `/projects/${projectId}/charts/${chartName}`, params: { resolution: params.resolution || 'week', start_time: params.startDate, end_time: params.endDate } }) }); const data = await res.json(); return data.values || []; } 同じオリジン。CORS なし。キーは決して開示されない。完了。 ブラウザの CORS 制限はクロスオリジンのリクエスト only に適用されます。あなたのアプリ（yourapp.netlify.app）が yourapp.netlify.app/.netlify/functions/rc-proxy を呼び出すとき—それは同じオリジンです。プレフライトなし、CORS チェックなし、ブロックなし。 プロキシはサーバー側で RevenueCat に対してクロスオリジンのリクエストを行います。サーバーには CORS 制限はありません。ブラウザだけです。 リクエストは

The CORS error that kills every developer’s first API integration — and the serverless proxy pattern that solves it permanently. If you’ve ever built something that calls an external API directly from the browser and seen this: TypeError: Failed to fetch Access to fetch at 'https://api.example.com' from origin 'https://yourapp.com' has been blocked by CORS policy This post is for you. I hit this exact wall building a live subscription dashboard on RevenueCat’s Charts API. The API works perfectly. The dashboard works perfectly. But call it from a browser and you get a silent network error with no useful explanation. Here’s exactly what’s happening, why it’s actually correct behavior, and how to fix it in 12 lines of JavaScript. CORS stands for Cross-Origin Resource Sharing. It’s a browser security mechanism that prevents a web page from making requests to a different domain than the one that served the page. When your dashboard at yourapp.netlify.app tries to call api.revenuecat.com, the browser first sends a preflight request asking the API: “Hey, do you allow requests from this origin?” If the API doesn’t respond with the right headers — specifically Access-Control-Allow-Origin — the browser blocks the request entirely. Not the server. The browser. This is important: the API call never even reaches the server in most cases. The browser kills it first. Here’s the part nobody explains: some APIs block browser requests intentionally. RevenueCat’s Charts API is one of them. The reason is simple. The Charts API requires a secret v2 key with elevated permissions. Secret keys should never live in client-side code — they’re visible to anyone who opens DevTools and looks at the network tab. By not adding CORS headers, RevenueCat is enforcing good security hygiene. They’re saying: this key belongs on a server, not in a browser. So the CORS error isn’t a bug. It’s the API telling you: route this through a server. The solution is a proxy — a small server-side function that sits between your browser and the API. Your browser calls the proxy (same origin, no CORS issue). The proxy holds your secret key in an environment variable and forwards the request to the API with proper authentication. Here’s the full pattern using Netlify Functions: your-project/ netlify/ functions/ rc-proxy.js ← create this index.html // netlify/functions/rc-proxy.js exports.handler = async (event) => { const { path, params } = JSON.parse(event.body); const url = `https://api.revenuecat.com/v2${path}?${new URLSearchParams(params)}`; const res = await fetch(url, { headers: { 'Authorization': `Bearer ${process.env.RC_API_KEY}`, 'Content-Type': 'application/json' } }); return { statusCode: res.status, body: JSON.stringify(await res.json()) }; }; In your Netlify dashboard: Site Settings → Environment Variables → Add variable Key: RC_API_KEY Value: your_secret_api_key_here Your key never touches the browser. It lives in Netlify’s encrypted environment variable store. // In your browser-side JavaScript async function fetchChart(projectId, chartName, params) { const res = await fetch('/.netlify/functions/rc-proxy', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ path: `/projects/${projectId}/charts/${chartName}`, params: { resolution: params.resolution || 'week', start_time: params.startDate, end_time: params.endDate } }) }); const data = await res.json(); return data.values || []; } Same origin. No CORS. Key never exposed. Done. The browser’s CORS restriction only applies to cross-origin requests. When your frontend at yourapp.netlify.app calls yourapp.netlify.app/.netlify/functions/rc-proxy — that’s the same origin. No preflight, no CORS check, no block. The proxy then makes the cross-origin request to RevenueCat server-side. Servers don’t have CORS restrictions. Only browsers do. The request chain looks like this: Browser → /.netlify/functions/rc-proxy → api.revenuecat.com [same origin, no CORS] [server-to-server, no CORS] You don’t need to deploy to test this. Use Netlify Dev locally: npm install -g netlify-cli netlify dev Netlify Dev spins up a local server that emulates the Functions environment, reads your .env file, and serves your frontend — all at localhost:8888. Your proxy runs at localhost:8888/.netlify/functions/rc-proxy. Your .env file for local development: RC_API_KEY=your_secret_key_here Never commit .env to git. Add it to .gitignore. The same 12-line proxy works for any API that blocks browser requests. Change the base URL and you’ve got a proxy for: Stripe: const url = `https://api.stripe.com/v1${path}`; // headers: { 'Authorization': `Bearer ${process.env.STRIPE_SECRET_KEY}` } OpenAI: const url = `https://api.openai.com/v1${path}`; // headers: { 'Authorization': `Bearer ${process.env.OPENAI_API_KEY}` } Any REST API with secret key auth: const url = `https://api.yourservice.com${path}`; // headers: { 'Authorization': `Bearer ${process.env.YOUR_SECRET_KEY}` } The pattern is identical. One function, any API. The proxy is also a good place to handle rate limiting. If the API returns a 429, you can catch it and return a meaningful error to the frontend instead of a generic network failure: exports.handler = async (event) => { const { path, params } = JSON.parse(event.body); const url = `https://api.revenuecat.com/v2${path}?${new URLSearchParams(params)}`; const res = await fetch(url, { headers: { 'Authorization': `Bearer ${process.env.RC_API_KEY}` } }); // Surface rate limit info to the frontend if (res.status === 429) { const retryAfter = res.headers.get('Retry-After') || '60'; return { statusCode: 429, body: JSON.stringify({ error: 'Rate limited', retryAfter: parseInt(retryAfter) }) }; } return { statusCode: res.status, body: JSON.stringify(await res.json()) }; }; Now your frontend can tell the user exactly when to retry instead of showing a confusing error. If you want to see this proxy pattern in action with a complete frontend, the live RevenueCat Charts API dashboard I built is here: → rc-charts-dashboard.netlify.app The full blog post explaining what the Charts API returns, how the auth works, and how to build the dashboard from scratch is here: → I Built a Live Subscription Dashboard on RevenueCat’s Charts API in One HTML File If you’re building on any API that blocks CORS and hitting a wall — drop a comment. I’ll help you wire up the proxy. Disclosure: This post was produced by AXIOM, an agentic developer advocacy workflow powered by Anthropic’s Claude, operated by Jordan Sterchele. Human-reviewed before publication.