區域網路存取權，讓你正視呼叫API的方法

作者： -
區域網路存取權，阻擋跨域API

為什麼 API 權限全開，還是會封鎖連線？

開發前後端分離架構，或是串接不同環境 API 時，常發生一種情況：後端已設定 Access-Control-Allow-Origin: *（允許所有網域存取），且 Postman 測試正常，但從瀏覽器環境透過 JavaScript 發送請求給內網或私有環境的 API 伺服器時，Chrome 卻強制阻擋連線。

這是 Chrome 實施「區域網路存取權」（Local Network Access, LNA）規範所致，目的是為了保護使用者免於跨網站要求偽造 (CSRF) 攻擊。

使用者在初次進入網站時，可能會看到這2種提示訊息視窗（也可能不會看到就自動封鎖）：

區域網路存取權限視窗 區域網路存取權限視窗

這會帶來什麼影響？

這項安全機制會導致即使後端 API 權限全開，瀏覽器仍攔截請求。具體的錯誤訊息如下： 

Access to fetch at 'https://api.example.com/apiName' from origin 'https://www.example.com' has been blocked by CORS policy: Permission was denied for this request to access the `unknown` address space.

net::ERR_FAILED

看到 Permission was denied for this request to access the ... address space 關鍵字，即代表觸發區域網路存取限制。瀏覽器判定來源（如 www.example.com）位於公網，而目標解析後位於私有網路或無法判定的位址空間，直接封鎖。

技術債的償還：API 呼叫的正規做法

遇到此問題時，有些網站管理者會教使用者如何解除封鎖，並叫他們點擊「允許」：

  1. 點擊網址左邊的icon。
  2. 開啟存取權。
  3. 重新整理頁面。
  4. 跳出提示視窗時點擊允許。
使用者手動解除封鎖的方法


但從架構安全的角度來看，前端直接呼叫私有 API 或第三方服務，本質上就是一種「技術債」，就算寫在 .env 裡面有心人也有辦法翻出來。API 呼叫的最佳實踐本來就該是 Server-to-Server（伺服器對伺服器）。

以串接 HubSpot API 為例，正常情況下，不會有人直接在前端 JavaScript 呼叫 API，因為這會導致 API Key 直接暴露在瀏覽器的原始碼或 Network Tab 中，讓任何人都能竊取並濫用。同理，企業內部的 API 即使位於內網，若依賴前端直接存取，不僅受限於瀏覽器的 CORS 與 LNA 政策，更暴露了內部網路架構細節。

Chrome 的這項限制，實則是強迫開發者修正架構，改用後端 Proxy 來處理跨網域或跨安全層級的資料請求。

解決方案：建立後端 Proxy

透過與前端同網域（或公網可存取）的後端伺服器轉發請求，將流程轉為 S2S。後端伺服器不受瀏覽器安全限制，可自由存取目標 API，同時隱藏敏感資訊（如 Token 或真實 IP）。

程式範例

1. 前端直接呼叫（技術債寫法，會失敗）

以下寫法除了觸發 Chrome 錯誤，若包含機敏參數也極不安全。

// ❌ 前端直接呼叫，觸發 LNA 限制且暴露架構
const targetApi = 'https://api.example.com/apiName';

fetch(targetApi)
  .then(response => response.json())
  .catch(error => {
    // Console 顯示 access the `unknown` address space 錯誤
    console.error('被 Chrome 封鎖:', error);
  });

2. 前端改呼叫 Proxy（正規寫法）

前端不再接觸目標 API，僅呼叫自己的中介層。

// ✅ 呼叫同網域後端，安全且合規
// 假設您的後端 Proxy 檔案位於同網域下
const proxyUrl = '/proxy.php';

fetch(proxyUrl)
  .then(response => {
    if (!response.ok) throw new Error('Proxy error');
    return response.json();
  })
  .then(data => {
    console.log('成功取得資料:', data);
  })
  .catch(error => {
    console.error('連線錯誤:', error);
  });

3. 後端 Proxy 實作範例 (PHP)

由後端代為發送請求，這是最穩健的 API 介接方式。

<?php
// proxy.php


// 舊專案 PHP 5.6 version
// 1) 驗證請求來源 host（允許 localhost / 127.0.0.1 任意 port 或正式網域）
// 2) 僅接受 POST（並處理 OPTIONS 預檢）
// 3) 以 server-side 呼叫 jwt API (https://api.example/m/login)
// 4) 將 upstream 回應與狀態回傳給前端，並處理錯誤

// (1) 基本設定
// $allowed_hosts = array('127.0.0.1', 'localhost'); // 開發用，包含任意 port
$allowed_hosts = array('www.example.com.tw');
$API_KEY = '777777777';
$upstream_url = 'https://api.example.com/m/login';

// (2) 取出 Origin（優先）或 Referer 作為來源參考
$origin_header = '';
if (!empty($_SERVER['HTTP_ORIGIN'])) {
  $origin_header = $_SERVER['HTTP_ORIGIN']; // e.g. http://127.0.0.1:53721
} elseif (!empty($_SERVER['HTTP_REFERER'])) {
  // 取 referer 的 scheme+host+port（若有）
  $origin_header = preg_replace('#^(https?://[^/]+).*$#', '$1', $_SERVER['HTTP_REFERER']);
}

// (3) 解析 host（不含 port）以比對允許清單
$origin_host = '';
if ($origin_header) {
  $parts = parse_url($origin_header);
  if ($parts !== false && isset($parts['host'])) {
    $origin_host = strtolower($parts['host']);
  }
}

// (4) 檢查來源是否在允許清單
if (!in_array($origin_host, $allowed_hosts)) {
  header('HTTP/2 403 Forbidden');
  header('Content-Type: application/json; charset=utf-8');
  echo json_encode(array('Success' => false, 'ErrorMsg' => 'Forbidden: invalid origin', 'origin' => $origin_header));
  exit;
}

// (5) CORS header：只對合法 origin 回傳 Access-Control-Allow-Origin 原樣值（含 port）
if ($origin_header) {
  header('Access-Control-Allow-Origin: ' . $origin_header);
} else {
  // 保險起見，若無 origin header 也拒絕（已在上面判斷過）
  header('HTTP/2 403 Forbidden');
  header('Content-Type: application/json; charset=utf-8');
  echo json_encode(array('Success' => false, 'ErrorMsg' => 'No origin header'));
  exit;
}

header('Access-Control-Allow-Methods: POST, OPTIONS');
header('Access-Control-Allow-Headers: Content-Type, Authorization');
header('Content-Type: application/json; charset=utf-8');

// (6) 預檢請求直接回應 (OPTIONS)
if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
  // 可以回 204 或 200
  http_response_code(204);
  exit;
}

// (7) 嚴格要求 POST 方法
if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
  header('HTTP/2 405 Method Not Allowed');
  header('Allow: POST, OPTIONS');
  echo json_encode(array('Success' => false, 'ErrorMsg' => 'Only POST method is allowed'));
  exit;
}

// (8) 準備向 upstream 發出請求
$payload = array(
  'system' => 'm',
  'apiKey' => $API_KEY
);
$payload_json = json_encode($payload);

// 初始化 cURL
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $upstream_url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $payload_json);
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: application/json', 'Content-Length: ' . strlen($payload_json)));
curl_setopt($ch, CURLOPT_TIMEOUT, 15); // 整體 timeout
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10); // 連線 timeout

// 若你的環境需要，請勿關閉 SSL 驗證；下列為預設安全行為（不用設定 CURLOPT_SSL_VERIFYPEER=false）
// curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);

// (9) 執行 cURL 並取得回應、HTTP status
$response = curl_exec($ch);
$curl_errno = curl_errno($ch);
$curl_err = curl_error($ch);
$http_status = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);

// (10) 錯誤處理：cURL 錯誤視為 502 Bad Gateway 回傳
if ($curl_errno) {
  http_response_code(502);
  echo json_encode(array('Success' => false, 'ErrorMsg' => 'cURL error: ' . $curl_err, 'ErrorNo' => $curl_errno));
  exit;
}

// (11) 若 upstream 回傳非 2xx，將 upstream 的原始回應與狀態回傳（方便前端 debug）
if ($http_status < 200 || $http_status >= 300) {
  http_response_code(502);
  // 嘗試解析 upstream 回應為 JSON，若不是則以 raw string 包裝
  $up = json_decode($response, true);
  if ($up === null) {
    echo json_encode(array('Success' => false, 'ErrorMsg' => 'Upstream returned HTTP ' . $http_status, 'RawResponse' => $response));
  } else {
    // 若 upstream 自帶 Success 欄位，直接轉發
    echo json_encode($up);
  }
  exit;
}

// (12) 成功：直接把 upstream 的回應原封不動回傳（假設為 JSON）
echo $response;
exit;
?>

結語

當 Console 出現 access the unknown address space 錯誤時，代表 Chrome 擋下了不安全的跨層級連線。這不單是瀏覽器設定問題，更是架構設計的警訊。

解決此問題的正確途徑，並非尋找繞過瀏覽器檢查的偏門方法，而是償還技術債，建立後端 Proxy。這不僅解決了連線問題，更確保了 API Key 與內部架構的安全性。

留言

張貼留言

這個網誌中的熱門文章

如何產生醒目顯示文字的連結？讓使用者一目瞭然的功能(Scroll to Text Fragment)

作者： -
圖片
若你在優化任何非網站的網址(Office文件、PDF、留言、Email、Google 我的商家、SERP結構化資料如 FAQ 中的網址)，除了在網址使用 #id (錨點)之外，Scroll to Text Fragment 或許是另一個可以考慮的方式。 URL Scroll to Text Fragment 是什麼？ 它的功能是在網址中設定文字，使用者點擊網址進入網頁後，可以看到被強調的文字，並將畫面移動到該文字處，文字高度在畫面中間。這並不是什麼新功能，早在 chrome 80 以後就出現在以 chrome 為核心的瀏覽器之中了。 如何創建？ 複製醒目顯示文字連結 在 chrome 90 之後的版本，網頁上選取（反白）文字之後按右鍵，就會出現「 複製醒目顯示文字的連結 」的功能，點擊該功能產生的連結，貼到任何除了該連結頁面之外的地方，被點擊後就可以產生上一段文字提到的效果。如果沒有該功能，可能是被設定成關閉，網址列輸入 chrome://flags 並按下enter後，找到 Copy Link To Text 後就能開啟該功能（enabled）。 如何關閉？ 但是，在最新版本的 chrome 中， chrome://flags 已經找不到 Copy Link To Text 這個指令了，換句話說就是沒辦法關閉這個功能，還請注意。 文字反白之後右鍵即可看見該功能   連結的架構與DIY 若不想透過 chrome 附加的功能直接設定使用的話，自己也可以設計出這種特殊網址，方法與錨點類似，不過是加上「 #:~:text= 」 完整結構： https://example.com#:~:text=[prefix-,]textStart[,textEnd][,-suffix] 方法1 整段文字： 只使用 textStart 的話是最簡單的使用方式： #:~:text=文字 ，它會當成要 highlight 的所有文字，就像 {示範連接} 的範例一樣。 方法2 文字區段： 你也可以打上兩段文字： #:~:text=文字1,文字2 ，分別代表開頭和結尾，它會找尋這一區段的文字 highlight，這裡也用 {示範連接} 開新分頁示範一次。 方法3 多段文字： 可以使用「&」區隔： #:~:text=文字1&text=文字2 。但是個人不建議這...
READ THIS »

用CSS的 min max與vw cqw，設計有極限值的RWD響應式文字

作者： -
圖片
你是否有想過，max/min font size 的解法？能不能單靠 CSS 設計出會自動調整大小的 Responsive Font Size？答案是可以的！ 文章目錄： vw 基本運用 極限問題 max()、min()、clamp() Container Queries與cqw/cqi 為何使用 vw？ 在編寫 CSS 的時候，你可能習慣將網頁上的字體大小(font-size)使用 rem、em、px 等單位設定，但在講究 RWD 的情況下，甚至是 Google SEO 著重在手機介面的現在，總是會遇到桌機看起來很舒適，但畫面一變小，標題類的字就又太佔版面。 而使用 viewport width (vw) 當作字體大小的單位，就可以讓字體隨著視窗寬度的不同自動縮放其大小。 各瀏覽器支援 vw 的情況 vw 基本運用： vw 是視窗寬度的百分比，所以 1vw = 1%的視窗寬度。舉例來說，當視窗寬度為 1000px 且 font-size: 1.5vw 的時候，字體的大小就是 1000*1.5% = 15px。 h1,.h1{ font-size: 1.5vw; } 除了直接運用之外，也能搭配 calc 使用： h1,.h1{ font-size: calc(10px + 1.5vw); } 極限問題（max or min font size） 這是不管設計什麼東西都存在且必需要考慮的事情，vw 也不例外。 設計網頁一定會設一個網頁寬度，以此寬度設定做為最大值；而人的視力有限，以 16px 當作最小值。所以，當視窗被拉到極大或極小的時候，以 vw 為單位的字體勢必會變成你不想要的樣子，這時候我們就必需設定最大值和最小值，讓字體在合理的區間變動，而 media query 和 min()、max()就出現在解決辦法的清單之中： 以前的做法：Media Query 下面為使用的例子： h1,.h1{ font-size: 28px; } @media (min-width: 1600px) { h1,.h1{ font-size: 40px; } } @media (max-width: 480px) { h1,.h1{ font-size: 16px; } } ...
READ THIS »

Google Search Console 網頁發現方式多了「參照網頁」

作者： -
圖片
在檢查網址中的「涵蓋範圍」，發現方式新增了參照網頁（Referring page），讓網站管理者知道Google是用哪些方式得知這個頁面。 數據說明 參照網頁可能直接連到該URL，或者是連到該頁面的上一層或更上層。如果不存在任何值，並不意味著不存在任何引用頁面，只是此訊息可能此時對 網址檢查工具 不可用。 也就是說，對於較新的頁面，參照網頁可能不會有數據，這是很正常的。Google 新增這個欄位也顯示出他們是用多種方式來得知網頁的存在並抓取。 什麼是參照網頁？ 其實就是 GA 中的「 參照連結網址 」，意思是使用者進到你的網頁的來源網址，search console 會自動辨識這些流量來自哪裡。通常是連結，當然也有可能會是瀏覽器書籤、最愛、email 或手機app等，這大概也是為什麼不一定會有數據的原因之一吧。 頻繁更新 近期 Google Search Console 一直在更新，說不定是受到 Bing 更新的打擊(x)，例如「涵蓋範圍」也更新成只剩下近3個月的資料、新增「檢索統計資料」等等功能，以及對於 CWVs 的相關更新 ，我們可以期待它的功能和數據將越來越豐富與完整。
READ THIS »