You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

如何实现C# Web API仅允许指定域名访问且隐藏允许列表?

Got it, let's break down how to solve this exactly as you need it—no exposed allowed domains in the browser console, and direct browser hits to your API get blocked with a 403. Here's what you can do:

Solution 1: Reverse Proxy Level Validation (Nginx Example)

If you're using a reverse proxy like Nginx (super common for API deployments), you can add server-side checks to block invalid requests before they even reach your API. The key here is not to return any CORS-related response headers—this way, allowed domains never get exposed in the browser console.

Add this configuration to your api.domain.com server block:

server {
    listen 443 ssl;
    server_name api.domain.com;

    # Block requests that don't come from app1 or app2
    # Check Origin header first (modern browsers send this for cross-origin requests)
    if ($http_origin !~* ^https://(app1|app2)\.domain\.com$) {
        return 403 "Forbidden: Access is denied";
    }

    # Fallback to Referer header for older clients or cases where Origin isn't sent
    if ($http_referer !~* ^https://(app1|app2)\.domain\.com/) {
        return 403 "Forbidden: Access is denied";
    }

    # Your existing API proxy configuration goes here
    location / {
        proxy_pass http://your-api-upstream-address;
        # DO NOT add Access-Control-Allow-Origin headers here—we don't want to expose allowed domains
    }
}

How this works:

  • When someone directly visits api.domain.com in their browser, no Origin or valid Referer header is sent, so the server immediately returns a 403.
  • Requests from app1.domain.com or app2.domain.com will send a valid Origin (or Referer) header, so they pass the check and reach your API.
  • Since we never send Access-Control-Allow-Origin headers, the browser console won't show any list of allowed domains.

Solution 2: API-Level Validation (If You Control the API Code)

If you manage the codebase of your Web API, you can add a middleware/filter to validate incoming requests directly. Again, avoid returning CORS headers to keep allowed domains hidden.

Here's an example for a Node.js/Express API:

// Add this middleware before your API routes
app.use((req, res, next) => {
    const allowedDomains = ['https://app1.domain.com', 'https://app2.domain.com'];
    const requestOrigin = req.headers.origin;
    const requestReferer = req.headers.referer;

    // Check if either Origin matches, or Referer starts with an allowed domain
    const isAllowed = allowedDomains.includes(requestOrigin) || 
                      (requestReferer && allowedDomains.some(domain => requestReferer.startsWith(domain)));

    if (!isAllowed) {
        return res.status(403).send('Forbidden: Access is denied');
    }

    // Don't set Access-Control-Allow-Origin headers here
    next();
});

Key Notes for Both Solutions:

  • Avoid CORS headers: Never set Access-Control-Allow-Origin—this is the main reason allowed domains get exposed in the console.
  • Combine Origin and Referer checks: Some clients might not send one of these headers, so using both covers more cases.
  • Optional: Add API keys for extra security: For even stricter control, you can have your apps send a secret API key in the request headers, and validate that alongside the origin check.

内容的提问来源于stack exchange,提问作者aas

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.26 10:44:47