ਮੁੱਖ ਸਮੱਗਰੀ 'ਤੇ ਜਾਓ

ਸਮਾਨ-ਮੂਲ ਨੀਤੀ ਅਤੇ ਵੈੱਬ ਪ੍ਰੌਕਸੀਜ਼: ਇੱਕ ਤਕਨੀਕੀ ਸੁਰੱਖਿਆ ਵਿਸ਼ਲੇਸ਼ਣ

ਲੇਖਕ
Smith
Smith
ਪੜ੍ਹਨ ਦਾ ਸਮਾਂ
1 ਮਿੰਟ ਪੜ੍ਹਨ ਦਾ ਸਮਾਂ
ਪ੍ਰਕਾਸ਼ਿਤ ਮਿਤੀ
2 ਮਾਰਚ 2026
ਸਮਾਨ-ਮੂਲ ਨੀਤੀ ਅਤੇ ਵੈੱਬ ਪ੍ਰੌਕਸੀਜ਼: ਇੱਕ ਤਕਨੀਕੀ ਸੁਰੱਖਿਆ ਵਿਸ਼ਲੇਸ਼ਣ

ਜਦੋਂ ਅਸੀਂ ProxyOrb ਬਣਾਇਆ, ਤਾਂ ਸਾਨੂੰ ਹਰੇਕ ਡਿਜ਼ਾਈਨ ਫੈਸਲੇ 'ਤੇ ਇੱਕ ਬੁਨਿਆਦੀ ਵਿਰੋਧਾਭਾਸ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ: ਇੱਕ ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਇਹ ਵਿਸ਼ਵਾਸ ਦਿਵਾ ਕੇ ਕੰਮ ਕਰਦੀ ਹੈ ਕਿ ਤੀਜੀ-ਧਿਰ ਦੀ ਸਮੱਗਰੀ ਇੱਕੋ-ਮੂਲ ਸਮੱਗਰੀ ਹੈ। ਅਰਥਾਤ, ਪਰਿਭਾਸ਼ਾ ਦੁਆਰਾ, ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਕੋਰ ਸੁਰੱਖਿਆ ਮਾਡਲ ਨੂੰ ਧੋਖਾ ਦੇਣਾ। ਫਿਰ ਵੀ ਆਧੁਨਿਕ ਬ੍ਰਾਉਜ਼ਰਾਂ ਨੇ ਇਸ ਕਿਸਮ ਦੀ ਮੂਲ ਉਲਝਣ ਦੇ ਵਿਰੁੱਧ ਵਧਦੀ ਆਧੁਨਿਕ ਸੁਰੱਖਿਆ ਨੂੰ ਠੀਕ ਤਰ੍ਹਾਂ ਨਾਲ ਲੇਅਰਿੰਗ ਵਿੱਚ ਪੰਦਰਾਂ ਸਾਲ ਬਿਤਾਏ ਹਨ।

ਇਹ ਲੇਖ ਪਹਿਲੇ ਸਿਧਾਂਤਾਂ ਤੋਂ ਉਸ ਤਣਾਅ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਸੁਰੱਖਿਆ ਖੋਜਕਰਤਾ, ਪ੍ਰਵੇਸ਼ ਟੈਸਟਰ, ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਸੁਰੱਖਿਆ ਇੰਜੀਨੀਅਰ ਹੋ ਜੋ ਇਹ ਸਮਝਣਾ ਚਾਹੁੰਦਾ ਹੈ ਕਿ ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਅਸਲ ਵਿੱਚ ਉਸੇ-ਮੂਲ ਨੀਤੀ ਨਾਲ ਕਿਵੇਂ ਅੰਤਰਕਿਰਿਆ ਕਰਦੇ ਹਨ — ਇੱਕ ਸੰਕਲਪਿਕ ਪੱਧਰ 'ਤੇ ਨਹੀਂ, ਪਰ HTTP ਸਿਰਲੇਖਾਂ, Chromium ਸਰੋਤ ਕੋਡ, ਅਤੇ ਉਤਪਾਦਨ ਇੰਜੀਨੀਅਰਿੰਗ ਟ੍ਰੇਡ-ਆਫ ਦੇ ਪੱਧਰ 'ਤੇ — ਇਹ ਤੁਹਾਡੇ ਲਈ ਹੈ।

ਅਸੀਂ SOP ਫਾਊਂਡੇਸ਼ਨ, URL ਰੀਰਾਈਟਿੰਗ, CORS, CORB/CORP, COEP/COOP, ਸਰਵਿਸ ਵਰਕਰ, iframes, ਅਤੇ ਪ੍ਰੌਕਸੀ ਆਪਰੇਟਰਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸੁਰੱਖਿਆ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਕਵਰ ਕਰਾਂਗੇ।

1. The Same-Origin Policy Foundation

The same-origin policy (SOP) is defined by a three-tuple: scheme + host + port. Two URLs are same-origin only if all three components match exactly. https://example.com:443 and http://example.com:80 are cross-origin despite pointing to the same server.

What is frequently misunderstood is what SOP actually prevents versus what it permits. SOP does not block:

  • Loading images (<img src>) across origins
  • Loading scripts (<script src>) across origins
  • Loading stylesheets (<link rel="stylesheet">) across origins
  • Embedding iframes across origins (though the embedded document's contents are isolated)
  • Sending form submissions (<form action>) across origins

What SOP does prevent is reading the response of cross-origin requests made via fetch() or XMLHttpRequest. The request goes out — the network round-trip happens — but the response body and headers are withheld from JavaScript running in a different origin.

This distinction matters enormously for web proxies. The proxy's entire job is to collapse two origins (the proxy server and the target server) into one, eliminating the cross-origin boundary. Once all resources appear to come from https://proxyorb.com, the browser's SOP-based restrictions on reading responses simply do not apply.

The "legitimate space" that web proxies exploit is URL rewriting: instead of https://example.com/api/data, every request becomes https://proxyorb.com/api/data?__pot=aHR0cHM6Ly9leGFtcGxlLmNvbQ==. From the browser's perspective, this is a same-origin request. The SOP has not been bypassed — it has been rendered irrelevant by changing the apparent origin of all content.

2. ProxyOrb ਦਾ URL ਰੀਰਾਈਟਿੰਗ ਆਰਕੀਟੈਕਚਰ

ਸੁਰੱਖਿਆ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਸਮਝਣ ਲਈ, ਤੁਹਾਨੂੰ ਏਨਕੋਡਿੰਗ ਵਿਧੀ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ। ProxyOrb __pot (ਪ੍ਰੌਕਸੀ ਮੂਲ ਟੋਕਨ) ਨਾਮਕ ਇੱਕ URL ਪੈਰਾਮੀਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਬੇਸ64-ਏਨਕੋਡਡ ਟੀਚਾ ਮੂਲ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ।

__pot ਪੈਰਾਮੀਟਰ

ਪੈਰਾਮੀਟਰ __pot ਹਮੇਸ਼ਾ ਟੀਚੇ ਦੇ ਮੂਲ (ਸਕੀਮ + ਹੋਸਟ, ਕੋਈ ਮਾਰਗ ਨਹੀਂ) ਨੂੰ ਏਨਕੋਡ ਕਰਦਾ ਹੈ, ਪੂਰੇ URL ਨੂੰ ਨਹੀਂ। ਇਸਦਾ ਮਤਲਬ ਹੈ https://example.com/some/deep/path?foo=bar ਅਤੇ https://example.com/other/page ਦੋਵੇਂ ਇੱਕੋ __pot ਮੁੱਲ ਪੈਦਾ ਕਰਦੇ ਹਨ: aHR0cHM6Ly9leGFtcGxlLmNvbQ== (`https://example ਦੀ ਬੇਸ64 ਐਨਕੋਡਿੰਗ)। ਅਸਲ ਮਾਰਗ ਅਤੇ ਪੁੱਛਗਿੱਛ ਸਤਰ ਨੂੰ ਪਰਾਕਸੀ URL ਦੇ ਆਪਣੇ ਮਾਰਗ ਅਤੇ ਪੁੱਛਗਿੱਛ ਸਤਰ ਵਿੱਚ ਸ਼ਬਦਾਵਲੀ ਨਾਲ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ।

ਜਦੋਂ ਕੋਈ ਵਰਤੋਂਕਾਰ https://proxyorb.com/?__pot=aHR0cHM6Ly9leGFtcGxlLmNvbQ== 'ਤੇ ਨੈਵੀਗੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਗੇਟਵੇ ਇਸਨੂੰ ਡੀਕੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਮੂਲ URL ਦਾ ਪੁਨਰਗਠਨ ਕਰਦਾ ਹੈ:

-- Gateway pseudocode: decoding the proxy request

function resolve_original_url(proxy_url):
    pot_value = parse_query_param(proxy_url, "__pot")
    if not pot_value:
        return error("Missing origin token")

    original_origin = base64_decode(pot_value)
    -- e.g. "https://example.com"

    validate_not_private_ip(original_origin)  -- SSRF protection

    -- Replace the proxy host with the target host, keep path/query intact
    original_url = replace_origin(proxy_url, original_origin)
    return original_url

ਗੇਟਵੇ ਫਿਰ ਅਸਲ ਟਾਰਗੇਟ ਸਰਵਰ ਨੂੰ ਬੇਨਤੀ ਨੂੰ ਅੱਗੇ ਭੇਜਦਾ ਹੈ, ਮੂਲ ਸਿਰਲੇਖ ਨੂੰ ਮੁੜ ਲਿਖਦਾ ਹੈ ਤਾਂ ਜੋ ਅੱਪਸਟ੍ਰੀਮ ਸਰਵਰ ਪ੍ਰੌਕਸੀ ਡੋਮੇਨ ਦੀ ਬਜਾਏ ਆਪਣਾ ਡੋਮੇਨ ਵੇਖੇ:

-- Set outbound headers toward the target server

request.headers["Host"]   = target_host
request.headers["Origin"] = target_origin   -- e.g. "https://example.com"
-- Remove all internal proxy headers before forwarding

ਸੇਵਾ ਕਰਮਚਾਰੀ ਦੁਆਰਾ ਕਲਾਇੰਟ-ਸਾਈਡ URL ਰੀਰਾਈਟਿੰਗ

ਗੇਟਵੇ ਸਰਵਰ ਸਾਈਡ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ ਸਾਈਡ — HTML, JavaScript, ਅਤੇ CSS ਜਵਾਬਾਂ ਵਿੱਚ URL ਨੂੰ ਮੁੜ ਲਿਖਣਾ ਤਾਂ ਜੋ ਸਾਰੀਆਂ ਉਪ-ਬੇਨਤੀਆਂ ਪ੍ਰੌਕਸੀ ਦੁਆਰਾ ਜਾਰੀ ਰਹਿਣ — ਇੱਕ ਸਰਵਿਸ ਵਰਕਰ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ।

ਮੁੱਖ ਪਰਿਵਰਤਨ ਪੰਨਾ ਸਮੱਗਰੀ ਵਿੱਚ ਆਏ ਕਿਸੇ ਵੀ URL ਨੂੰ ਪ੍ਰੌਕਸੀ ਫਾਰਮੈਟ ਵਿੱਚ ਬਦਲਦਾ ਹੈ:

-- Service Worker pseudocode: toProxyURL()

function toProxyURL(originalUrl, currentPageUrl):
    if isSameOrigin(originalUrl, currentPageUrl):
        return originalUrl   -- already proxy-origin, no rewrite needed

    -- Extract path/query/hash from the original URL
    -- Build a new URL rooted at the proxy origin
    proxyPath   = extractPathAndQuery(originalUrl)
    potValue    = base64encode(extractOrigin(originalUrl))
    proxyUrl    = proxy_origin + proxyPath + "?__pot=" + potValue

    return proxyUrl

ਉਦਾਹਰਨ ਲਈ, 'https://cdn.example.com/bundle.js` ਨੂੰ ਪ੍ਰੌਕਸੀ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਪੰਨੇ ਦੇ ਅੰਦਰ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ 'https://proxyorb.com/bundle.js?__pot=aHR0cHM6Ly9jZG4uZXhhbXBsZS5jb20=' ਬਣ ਜਾਂਦਾ ਹੈ।

ਇਹ ਰੀਰਾਈਟਿੰਗ ਵਿਆਪਕ ਹੈ: ਇਸ ਵਿੱਚ fetch(), XMLHttpRequest, <script src>, <img src>, WebSocket ਕਨੈਕਸ਼ਨ, ਅਤੇ <link> ਟੈਗ ਸ਼ਾਮਲ ਹਨ। ਜਦੋਂ ਪੰਨੇ ਵਿੱਚ ਹਰ URL ਪ੍ਰੌਕਸੀ ਮੂਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਕਦੇ ਵੀ ਕ੍ਰਾਸ-ਓਰੀਜਨ ਬੇਨਤੀ ਨਹੀਂ ਕਰਦਾ — ਹਰ ਬੇਨਤੀ ਨਿਰਮਾਣ ਦੁਆਰਾ ਇੱਕੋ-ਮੂਲ ਹੁੰਦੀ ਹੈ।

ਪੂਰੀ ਨੈਵੀਗੇਸ਼ਨ ਤੋਂ ਬਿਨਾਂ __ਪਾਟ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨਾ

ਇੱਕ ਸੂਖਮ ਕਿਨਾਰੇ ਵਾਲਾ ਕੇਸ ਉਹਨਾਂ ਬੇਨਤੀਆਂ ਨਾਲ ਪੈਦਾ ਹੁੰਦਾ ਹੈ ਜੋ ਇੱਕ ਪ੍ਰੌਕਸੀਡ ਪੰਨੇ ਦੇ ਅੰਦਰ ਤੋਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ ਪਰ __pot ਪੈਰਾਮੀਟਰ ਦੀ ਘਾਟ ਹੁੰਦੀ ਹੈ — ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਰਿਸ਼ਤੇਦਾਰ fetch('/api/data') ਜੋ ਸੇਵਾ ਕਰਮਚਾਰੀ ਦੁਆਰਾ URL ਨੂੰ ਮੁੜ-ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਫਾਇਰ ਕਰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਡਾਇਨਾਮਿਕਲੀ-ਇੰਜੈਕਟਡ ਸਕ੍ਰਿਪਟ ਦੁਆਰਾ ਜਾਰੀ ਕੀਤੀ ਬੇਨਤੀ ਜੋ URL ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੀ ਹੈ।

ਸਰਵਿਸ ਵਰਕਰ ਗੁੰਮ ਹੋਏ ਟੋਕਨ ਨੂੰ ਕੈਸਕੇਡਿੰਗ ਲੁੱਕਅਪ ਰਾਹੀਂ ਹੱਲ ਕਰਦਾ ਹੈ:

-- Service Worker pseudocode: recovering the origin token

function resolveMissingPot(fetchEvent):
    candidates = [
        getUrlOfControlledTab(fetchEvent.clientId),   -- most reliable
        inferUrlFromFetchEvent(fetchEvent),             -- from clientId / resultingClientId
        fetchEvent.request.referrer,                    -- referrer header
    ]

    for url in candidates:
        pot = extractQueryParam(url, "__pot")
        if pot: return pot

    return null   -- cannot recover; let the gateway handle or reject

ਗੇਟਵੇ ਦਾ ਇੱਕ ਸਮਾਨਾਂਤਰ ਰਿਕਵਰੀ ਪਾਥ ਹੈ: ਜੇਕਰ ਕੋਈ ਬੇਨਤੀ __pot ਤੋਂ ਬਿਨਾਂ ਆਉਂਦੀ ਹੈ ਪਰ ਇੱਕ ਉਸੇ-ਮੂਲ URL ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਇੱਕ ਰੈਫਰਰ ਸਿਰਲੇਖ ਰੱਖਦਾ ਹੈ ਜਿਸ ਵਿੱਚ *'__pot` ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਗੇਟਵੇ ਰੈਫਰਰ ਤੋਂ ਟੋਕਨ ਕੱਢਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਮੌਜੂਦਾ ਬੇਨਤੀ ਨਾਲ ਨੱਥੀ ਕਰਦਾ ਹੈ। ਇਹ ਨੈਵੀਗੇਸ਼ਨ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਜਿੱਥੇ ਗੇਟਵੇ ਨੂੰ ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੰਨੇ ਦੀ ਆਪਣੀ JavaScript ਦੁਆਰਾ ਟੋਕਨ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ।

3. CORS: The Explicit Cross-Origin Permission System

CORS (Cross-Origin Resource Sharing) was designed to let servers opt in to cross-origin access by sending specific response headers. From the proxy's perspective, CORS creates two distinct problems.

Problem 1: CORS Preflight Interception

When JavaScript running on a page makes a fetch() request with non-simple headers (e.g., Authorization, Content-Type: application/json), the browser sends an OPTIONS preflight request first. If the target server's preflight response does not include permissive CORS headers, the real request is blocked.

In ProxyOrb's architecture, the Service Worker intercepts all OPTIONS requests and answers them synthetically — before they even reach the gateway — returning a response that unblocks the real request:

-- Service Worker pseudocode: synthetic CORS preflight

function handlePreflight(request):
    origin = request.headers["Origin"] or "*"

    return Response(status=204, headers={
        "Access-Control-Allow-Origin":      origin,
        "Access-Control-Allow-Methods":     "GET, POST, PUT, DELETE, OPTIONS, PATCH, HEAD",
        "Access-Control-Allow-Headers":     "*",
        "Access-Control-Allow-Credentials": "true",
        "Access-Control-Max-Age":           "86400",
        "Vary":                             "Origin",
    })

At the gateway level, every proxied response receives equivalent CORS headers:

-- Gateway pseudocode: set CORS on outbound response

response.headers["Access-Control-Allow-Origin"]      = original_origin
response.headers["Access-Control-Allow-Headers"]     = "*"
response.headers["Access-Control-Allow-Credentials"] = "true"

Problem 2: Credentialed Requests

The combination of Access-Control-Allow-Credentials: true and a non-wildcard Access-Control-Allow-Origin is significant. CORS requires an explicit origin value (not *) whenever credentials are included. The Service Worker issues all outbound requests with credentials: 'include', so the gateway must echo back the exact requesting origin rather than a wildcard.

This means all cookies stored under proxyorb.com — accumulated from every target site the user has visited through the proxy — are sent on every proxied request. This is intentional (it maintains session state for logged-in sites), but it is also an important security consideration we discuss in Section 8.

The CORS Header Strip-and-Replace Pattern

A proxied response may carry CORS headers from the target server that are wrong from the browser's perspective (they reference the target origin, not the proxy origin). The Service Worker strips and replaces them:

-- Service Worker pseudocode: sanitize response headers

function sanitizeResponseHeaders(response):
    headers = copy(response.headers)

    -- Remove target-site directives that would confuse the browser
    headers.delete("Content-Security-Policy")
    headers.delete("Content-Security-Policy-Report-Only")
    headers.delete("X-Frame-Options")
    headers.delete("X-Content-Type-Options")

    -- Replace with proxy-origin-correct CORS headers
    headers.set("Access-Control-Allow-Origin",      proxy_origin)
    headers.set("Access-Control-Allow-Credentials", "true")
    headers.set("Access-Control-Allow-Headers",     "*")
    headers.set("Vary", "Origin")

    return headers

4. CORB ਅਤੇ CORP: ਕ੍ਰੋਮਿਅਮ ਦੇ ਸਖਤ ਬਚਾਅ

CORS ਸਰਵਰਾਂ ਤੋਂ ਸਪੱਸ਼ਟ ਔਪਟ-ਇਨ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। Chromium ਨੇ ਦੋ ਵਿਧੀਆਂ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਹਨ ਜੋ CORS ਸੰਰਚਨਾ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ, ਮੂਲ ਰੂਪ ਵਿੱਚ ਕਿਰਿਆਸ਼ੀਲ ਹਨ।

ਕ੍ਰਾਸ-ਓਰਿਜਨ ਰੀਡ ਬਲਾਕਿੰਗ (CORB)

CORB ਨੂੰ ਸਪੈਕਟਰ ਮਿਟੀਗੇਸ਼ਨ ਦੇ ਹਿੱਸੇ ਵਜੋਂ Chrome 67 (2018) ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ। ਕੋਰ ਇਨਸਾਈਟ: ਭਾਵੇਂ ਜਾਵਾ ਸਕ੍ਰਿਪਟ ਦੁਆਰਾ ਕ੍ਰਾਸ-ਓਰੀਜਨ ਜਵਾਬ ਦੇ ਸਰੀਰ ਨੂੰ ਕਦੇ ਵੀ ਪੜ੍ਹਿਆ ਨਹੀਂ ਜਾਂਦਾ ਹੈ, ਇਸ ਤੱਥ ਦਾ ਕਿ ਇਸਨੂੰ ਰੈਂਡਰਰ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਅਤੇ ਡੀਕੋਡ ਕੀਤਾ ਗਿਆ ਸੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਉਸ ਪ੍ਰਕਿਰਿਆ ਦੇ ਐਡਰੈੱਸ ਸਪੇਸ ਵਿੱਚ ਮੌਜੂਦ ਹੈ। ਸਪੈਕਟਰ-ਸ਼੍ਰੇਣੀ ਦੇ ਹਮਲੇ ਫਿਰ ਇਸ ਨੂੰ ਸਾਈਡ ਚੈਨਲਾਂ ਰਾਹੀਂ ਕੱਢ ਸਕਦੇ ਹਨ।

CORB ਕੁਝ ਅੰਤਰ-ਮੂਲ ਜਵਾਬਾਂ ਨੂੰ ਕਦੇ ਵੀ ਰੈਂਡਰਰ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਜਦੋਂ ਇੱਕ <script> ਟੈਗ ਜਾਂ <img> ਟੈਗ ਇੱਕ ਕਰਾਸ-ਮੂਲ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ ਜਵਾਬ ਵਿੱਚ ਟੈਕਸਟ/html, ਟੈਕਸਟ/xml, ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ/json ਦੀ ਇੱਕ ਸਮੱਗਰੀ-ਕਿਸਮ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਕ੍ਰੋਮੀਅਮ ਸਰੀਰ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ (ਇੱਕ MIME-ਕਿਸਮ ਦੇ ਸੁੰਘਣ ਵਾਲੇ ਦੀ ਵਰਤੋਂ ਕਰਕੇ CB ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। spec) ਅਤੇ, ਜੇਕਰ ਕਿਸਮ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਤਾਂ ਰੈਂਡਰਰ ਦੁਆਰਾ ਇਸਨੂੰ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਨੂੰ ਖਾਲੀ ਇੱਕ ਨਾਲ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਲਈ, CORB ਘਾਤਕ ਹੋਵੇਗਾ ਜੇਕਰ ਬੇਨਤੀਆਂ ਅਸਲ ਵਿੱਚ ਅੰਤਰ-ਮੂਲ ਸਨ। <script> ਟੈਗ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤਾ ਐਪਲੀਕੇਸ਼ਨ/json ਵਾਪਸ ਕਰਨ ਵਾਲਾ API ਅੰਤਮ ਬਿੰਦੂ ਚੁੱਪਚਾਪ ਖਾਲੀ ਵਾਪਸ ਆਵੇਗਾ। ਹਾਲਾਂਕਿ, ਕਿਉਂਕਿ ProxyOrb ਸਾਰੇ URL ਨੂੰ ਇੱਕੋ-ਮੂਲ ਹੋਣ ਲਈ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ, CORB ਦੀ ਕਰਾਸ-ਓਰੀਜਨ ਸਥਿਤੀ ਕਦੇ ਵੀ ਚਾਲੂ ਨਹੀਂ ਹੁੰਦੀ — ਬ੍ਰਾਊਜ਼ਰ ਕਦੇ ਵੀ ਕਰਾਸ-ਓਰੀਜਨ JSON ਜਵਾਬ ਨਹੀਂ ਦੇਖਦਾ, ਕਿਉਂਕਿ ਇਸਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਸਾਰੇ ਜਵਾਬ proxyorb.com ਤੋਂ ਆਉਂਦੇ ਹਨ।

ਇੱਕ ਕੇਸ ਜਿੱਥੇ CORB ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਸੇਵਾ ਕਰਮਚਾਰੀ ਦੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰਜਿਸਟਰ ਹੋਣ ਅਤੇ ਬੇਨਤੀਆਂ ਨੂੰ ਰੋਕਣ ਤੋਂ ਪਹਿਲਾਂ ਪਰਿਵਰਤਨ ਅਵਧੀ ਦੌਰਾਨ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਬੇਨਤੀ ਉਸ ਵਿੰਡੋ ਦੇ ਦੌਰਾਨ URL ਨੂੰ ਮੁੜ ਲਿਖਣ ਤੋਂ ਬਚ ਜਾਂਦੀ ਹੈ, ਤਾਂ CORB ਇਸਨੂੰ ਬਲੌਕ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਦੌੜ ਦੀ ਸਥਿਤੀ ਇਸ ਲਈ ਹੈ ਕਿ ProxyOrb ਇੱਕ ਮੁੱਖ-ਥ੍ਰੈੱਡ ਇੰਟਰਸੈਪਟਰ ਲੇਅਰ ਨੂੰ ਵੀ ਕਾਇਮ ਰੱਖਦਾ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਪੰਨੇ JavaScript ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ 'XMLHttpRequest', 'fetch', ਅਤੇ DOM ਵਿਸ਼ੇਸ਼ਤਾ ਸੈੱਟਰਾਂ ਨੂੰ ਸਮਕਾਲੀ ਰੂਪ ਵਿੱਚ ਪੈਚ ਕਰਦਾ ਹੈ — ਸਰਵਿਸ ਵਰਕਰ ਸਟਾਰਟਅੱਪ ਦੌਰਾਨ ਇੱਕ ਫਾਲਬੈਕ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ CORB ਨੂੰ ਓਪੇਕ ਰਿਸਪਾਂਸ ਬਲਾਕਿੰਗ (ORB) ਦੁਆਰਾ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਨੂੰ Chromium ਅਪਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹੈ। ORB ਸਪੈਕਟਰ ਸੁਰੱਖਿਆ ਨੂੰ ਕਾਇਮ ਰੱਖਦੇ ਹੋਏ ਝੂਠੇ ਸਕਾਰਾਤਮਕ ਨੂੰ ਘਟਾਉਣ ਲਈ CORB ਨਿਯਮਾਂ ਨੂੰ ਸੋਧਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਅਨੁਕੂਲਤਾ ਪ੍ਰਭਾਵ ਸਮਾਨ ਹਨ।

ਅੰਤਰ-ਮੂਲ ਸਰੋਤ ਨੀਤੀ (CORP)

CORP, Fetch spec ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ, ਸਰਵਰਾਂ ਨੂੰ ਇਹ ਐਲਾਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਦੇ ਸਰੋਤਾਂ ਨੂੰ ਸਿਰਫ਼ ਇੱਕੋ-ਮੂਲ ਜਾਂ ਇੱਕੋ-ਸਾਈਟ ਸੰਦਰਭਾਂ ਦੁਆਰਾ ਲੋਡ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:

Cross-Origin-Resource-Policy: same-origin

ਜਦੋਂ Chromium ਇੱਕ ਕਰਾਸ-ਓਰੀਜਨ ਉਪ-ਸਰੋਤ ਬੇਨਤੀ 'ਤੇ ਇਸ ਸਿਰਲੇਖ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਜਵਾਬ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਲੌਕ ਕਰਦਾ ਹੈ। ਇਹ CORB ਨਾਲੋਂ ਵਧੇਰੇ ਹਮਲਾਵਰ ਹੈ — ਇਹ ਸਮੱਗਰੀ ਦੀ ਕਿਸਮ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਅਤੇ MIME ਸੁੰਘਣ ਦੁਆਰਾ ਇਸ ਨੂੰ ਬਾਈਪਾਸ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਦੁਬਾਰਾ ਫਿਰ, ਕਿਉਂਕਿ ProxyOrb ਦਾ URL ਰੀਰਾਈਟਿੰਗ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਇੱਕੋ-ਮੂਲ ਹਨ, ਟਾਰਗੇਟ ਸਰਵਰਾਂ ਤੋਂ CORP ਸਿਰਲੇਖ ਬਲਾਕਿੰਗ ਨੂੰ ਟਰਿੱਗਰ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਗੇਟਵੇ ਇਹਨਾਂ ਸਿਰਲੇਖਾਂ ਨੂੰ ਜਵਾਬਾਂ ਤੋਂ ਰੱਖਿਆਤਮਕ ਢੰਗ ਨਾਲ ਹਟਾ ਦਿੰਦਾ ਹੈ, ਕਿਸੇ ਵੀ ਕਿਨਾਰੇ ਦੇ ਕੇਸਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਜਿੱਥੇ ਇੱਕ ਬੇਨਤੀ URL ਨੂੰ ਮੁੜ ਲਿਖਣ ਤੋਂ ਬਿਨਾਂ ਖਿਸਕ ਜਾਂਦੀ ਹੈ।

CORP ਨਾਲ ਡੂੰਘੀ ਸਮੱਸਿਆ ਅਸਲ ਵਿੱਚ ਇੱਕ ਅਜਿਹਾ ਮਾਮਲਾ ਹੈ ਜਿੱਥੇ ਪ੍ਰੌਕਸੀ ਆਰਕੀਟੈਕਚਰ _ ਅਨੁਕੂਲਤਾ _ ਮਦਦ ਕਰਦਾ ਹੈ: ਜੇਕਰ https://api.example.com ਅਤੇ https://www.example.com ਦੋਵੇਂ ਪ੍ਰੌਕਸੀ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ, ਤਾਂ ਦੋਵੇਂ ਇੱਕੋ ਪ੍ਰੌਕਸੀ ਮੂਲ ਦੇ ਨਾਲ ਨਕਸ਼ੇ ਹਨ, ਇਸਲਈ ਇੱਕ ਤੋਂ ਦੂਜੇ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੁਣ ਅਸਲ ਵਿੱਚ ਉਹੀ-ਮੂਲ ਹੈ — CORP ਹੁਣ ਉਹਨਾਂ ਵਿਚਕਾਰ ਪਾਬੰਦੀਆਂ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀਆਂ।

5. COEP and COOP: Cross-Origin Isolation

Starting in Chrome 92 (2021), access to SharedArrayBuffer — and by extension, high-resolution timers used for certain performance APIs — was restricted to pages that have opted into cross-origin isolation. This opt-in requires two response headers working in tandem.

Cross-Origin-Embedder-Policy (COEP)

Cross-Origin-Embedder-Policy: require-corp

When a page sends this header, the browser enforces that every sub-resource loaded by that page either:

  1. Is same-origin, OR
  2. Sends Cross-Origin-Resource-Policy: cross-origin explicitly, OR
  3. Has a permissive CORS response for the credentialed fetch

The problem for web proxies: if a target site sends COEP: require-corp on its main document, and that document is served through the proxy with the header preserved, the browser now demands that every sub-resource loaded by that page also opts in. Any resource that doesn't — and most won't — causes a network error.

Cross-Origin-Opener-Policy (COOP)

Cross-Origin-Opener-Policy: same-origin

COOP controls whether a page can share a browsing context group with cross-origin pages. When set to same-origin, a cross-origin navigation opens a new browsing context group, breaking window.opener references and postMessage channels between the page and any cross-origin openers.

For a proxy, COOP is less immediately destructive than COEP, but it still breaks sites that rely on cross-origin postMessage flows (OAuth popup flows being the most common example).

The Proxy Operator's Dilemma

This is the hardest trade-off we face at ProxyOrb:

Option A: Strip COEP and COOP from responses.

  • Pro: Sub-resource loading works normally; the proxied page doesn't apply these restrictions.
  • Con: We are removing security headers that the target site intentionally set. If the site was using cross-origin isolation to protect sensitive data from Spectre-class attacks, stripping these headers re-exposes that risk.

Option B: Preserve COEP and COOP.

  • Pro: The target site's security intent is honored.
  • Con: Any sub-resource that doesn't explicitly set CORP: cross-origin will fail to load, breaking most complex web applications.

ProxyOrb's current strategy is Option A: the gateway strips Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy from responses. This maximizes site compatibility. The security trade-off is consciously made: users of a web proxy are accepting that they are running content in an environment different from its intended deployment context.

Each new browser security mechanism follows a pattern: it is introduced as an opt-in (sites can send the header if they want protection), then gradually made default for new APIs, and eventually considered for mandatory enforcement. COEP followed this path: optional in Chrome 83, required for SharedArrayBuffer in Chrome 91. Sites that embed third-party content without coordination found their content broken. Web proxies compound this problem because they mediate third-party content by definition.

The browser security community is aware of this problem. The emerging Document-Isolation-Policy proposal aims to decouple process isolation from cross-origin isolation requirements, potentially making it possible to get Spectre mitigations without requiring all sub-resources to opt in. When that ships, proxy compatibility with isolation headers may improve.

6. ਬ੍ਰਾਊਜ਼ਰ-ਸਾਈਡ ਟਰੱਸਟ ਲੇਅਰ ਵਜੋਂ ਸਰਵਿਸ ਵਰਕਰ

ਸਰਵਿਸ ਵਰਕਰ ਸਿਰਫ਼ ਇੱਕ ਅਨੁਕੂਲਨ ਨਹੀਂ ਹੈ - ਇਹ ProxyOrb ਦੇ ਸੁਰੱਖਿਆ ਮਾਡਲ ਲਈ ਆਰਕੀਟੈਕਚਰਲ ਤੌਰ 'ਤੇ ਜ਼ਰੂਰੀ ਹੈ। ਇੱਥੇ ਕਿਉਂ ਹੈ।

ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਦਾਇਰਾ ਮੂਲ ਨਾਲ ਜੁੜਦਾ ਹੈ

ਇੱਕ ਸੇਵਾ ਕਰਮਚਾਰੀ ਇੱਕ ਸਕੋਪ ਨਾਲ ਰਜਿਸਟਰ ਹੁੰਦਾ ਹੈ ਜੋ ਹਮੇਸ਼ਾ ਰਜਿਸਟਰ ਕਰਨ ਵਾਲੇ ਪੰਨੇ ਦੇ ਮੂਲ ਦੇ ਅੰਦਰ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ProxyOrb ਆਪਣੇ ਸੇਵਾ ਕਰਮਚਾਰੀ ਨੂੰ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਕੋਪ https://proxyorb.com/ ਹੁੰਦਾ ਹੈ, ਭਾਵ ਇਹ ਉਸ ਮੂਲ ਦੇ ਅਧੀਨ ਕਿਸੇ ਵੀ ਪੰਨੇ ਤੋਂ ਹਰ ਪ੍ਰਾਪਤੀ ਨੂੰ ਰੋਕਦਾ ਹੈ।

ਇਹ ਬੁਨਿਆਦੀ ਕਾਰਨ ਹੈ ਕਿ URL ਨੂੰ ਉਸੇ-ਮੂਲ ਲਈ ਮੁੜ ਲਿਖਣਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਇੱਕ ਵਾਰ ਜਦੋਂ SW ਇੱਕ ਕਲਾਇੰਟ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਉਸ ਕਲਾਇੰਟ ਤੋਂ ਹਰੇਕ ਨੈੱਟਵਰਕ ਬੇਨਤੀ - ਭਾਵੇਂ ਪੰਨੇ ਵਿੱਚ JavaScript ਕਿਹੜਾ URL ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ - ਪਹਿਲਾਂ ਸਰਵਿਸ ਵਰਕਰ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ।

// Service Worker entry point
self.addEventListener('fetch', (event) => {
  event.respondWith(handleProxyRequest(event))
})

ਇੰਟਰਸੈਪਸ਼ਨ ਪਾਈਪਲਾਈਨ

ਜਦੋਂ ਸਰਵਿਸ ਵਰਕਰ ਇੱਕ ਬੇਨਤੀ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਇਹ ਕਈ ਫੈਸਲੇ ਪੜਾਵਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ:

-- Service Worker pseudocode: request interception pipeline

function handleProxyRequest(fetchEvent):
    request = fetchEvent.request

    -- Stage 1: Synthetic CORS preflight (never hits the network)
    if request.method == "OPTIONS":
        return syntheticCORSResponse(request)

    -- Stage 2: Pass through requests that shouldn't be proxied
    if shouldBypass(request.url):
        return originalFetch(request)

    -- Stage 3: Ensure __pot is present; recover from context if missing
    enrichedRequest = attachOriginToken(request, fetchEvent)

    -- Stage 4: Forward to gateway
    response = originalFetch(enrichedRequest)

    -- Stage 5: Strip and replace security headers in the response
    return sanitizeAndReturn(response)

ਪਾਰਦਰਸ਼ੀ ਹੈਡਰ ਫਾਰਵਰਡਿੰਗ

ਇੱਕ ਸੂਖਮ ਚੁਣੌਤੀ: ਬ੍ਰਾਊਜ਼ਰ JavaScript ਨੂੰ Fetch API ਰਾਹੀਂ ਕੁਝ "ਵਰਜਿਤ" ਬੇਨਤੀ ਸਿਰਲੇਖ (ਹੋਸਟ, ਮੂਲ, ਰੈਫ਼ਰਰ, ਆਦਿ) ਸੈੱਟ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਸਰਵਿਸ ਵਰਕਰ ਪ੍ਰਤੀਬੰਧਿਤ ਸਿਰਲੇਖਾਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਕਸਟਮ ਪਾਸਥਰੂ ਹੈਡਰ ਵਿੱਚ ਏਨਕੋਡ ਕਰਕੇ ਇਸਦੇ ਆਲੇ ਦੁਆਲੇ ਕੰਮ ਕਰਦਾ ਹੈ; ਗੇਟਵੇ ਫਿਰ ਡੀਕੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਟਾਰਗੇਟ ਸਰਵਰ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ:

-- Pseudocode: encode browser-restricted headers for the gateway

function addPassthroughHeaders(request, outboundHeaders):
    restricted = {}
    for name, value in request.headers:
        if name not in COMMON_ALLOWED_HEADERS:
            restricted[name] = value

    if restricted is not empty:
        outboundHeaders["X-Proxy-Passthrough"] = json_encode(restricted)

-- Gateway side: decode and apply before forwarding upstream
function applyPassthroughHeaders(incomingHeaders):
    encoded = incomingHeaders["X-Proxy-Passthrough"]
    if encoded:
        for name, value in json_decode(encoded):
            request.headers[name] = value
        request.headers.delete("X-Proxy-Passthrough")

ਭਰੋਸੇਯੋਗ ਵਿਚੋਲੇ ਵਜੋਂ SW ਦੇ ਸੁਰੱਖਿਆ ਪ੍ਰਭਾਵ

ਸੁਰੱਖਿਆ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਸੇਵਾ ਕਰਮਚਾਰੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਸਥਿਤੀ 'ਤੇ ਕਬਜ਼ਾ ਕਰਦਾ ਹੈ: ਇਹ ਇਸਦੇ ਦਾਇਰੇ ਵਿੱਚ ਕਿਸੇ ਵੀ ਪੰਨੇ ਤੋਂ ਕੀਤੀ ਗਈ ਬੇਨਤੀ ਦਾ ਨਿਰੀਖਣ, ਸੰਸ਼ੋਧਨ ਅਤੇ ਜਾਅਲੀ ਕਰ ਸਕਦਾ ਹੈ। ਜਾਇਜ਼ ਪ੍ਰੌਕਸੀ ਵਰਤੋਂ ਲਈ, ਇਹ ਪੂਰਾ ਬਿੰਦੂ ਹੈ। ਇੱਕ ਖਰਾਬ ਪ੍ਰੌਕਸੀ ਲਈ, ਇਹ ਇੱਕ ਬਹੁਤ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹਮਲਾ ਸਤਹ ਹੋਵੇਗੀ।

ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਸਰਵਿਸ ਵਰਕਰ ਸਕ੍ਰਿਪਟ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸਰਵਉੱਚ ਹੈ। ProxyOrb ਸਖਤ ਕੈਸ਼ ਨਿਯੰਤਰਣਾਂ ਦੇ ਨਾਲ HTTPS ਉੱਤੇ ਇਸਦੇ ਆਪਣੇ ਮੂਲ ਤੋਂ ਇੰਟਰਸੈਪਟਰ ਸਕ੍ਰਿਪਟ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਹਮਲਾਵਰ ਇੱਕ ਸੋਧੇ ਹੋਏ ਸੇਵਾ ਕਰਮਚਾਰੀ ਨੂੰ ਇੰਜੈਕਟ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਹ ਪ੍ਰਭਾਵਿਤ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ — ਨਾ ਸਿਰਫ ਪ੍ਰੌਕਸੀ ਟ੍ਰੈਫਿਕ, ਬਲਕਿ ਉਸ ਮੂਲ ਦੇ ਅਧੀਨ ਪੰਨਿਆਂ ਤੋਂ ਕੋਈ ਵੀ ਬੇਨਤੀ।

7. iframes: The Frame-Ancestors Problem

iframes represent a distinct challenge from regular sub-resources because they involve a nested browsing context with its own navigation, its own SOP boundary, and its own set of embedding restrictions.

X-Frame-Options and frame-ancestors

Two mechanisms prevent pages from being embedded in iframes:

Legacy: X-Frame-Options: DENY or X-Frame-Options: SAMEORIGIN

Modern: Content-Security-Policy: frame-ancestors 'none' or frame-ancestors 'self'

When the gateway proxies a target page that sends either of these, the page cannot be embedded in an iframe under the proxy origin. Since X-Frame-Options: SAMEORIGIN references the target origin (example.com), and the proxy serves the page from proxyorb.com, the browser's same-origin check fails.

The proxy must strip these headers from proxied responses and replace the CSP with a permissive version:

-- Gateway pseudocode: override embedding-restrictive headers

response.headers.delete("X-Frame-Options")
response.headers.delete("Content-Security-Policy")
response.headers.delete("Content-Security-Policy-Report-Only")

-- Set a permissive replacement that allows the proxy to embed content
response.headers["Content-Security-Policy"] =
    "upgrade-insecure-requests; frame-ancestors 'self'; " +
    "default-src * data: blob: about: ws: wss: 'unsafe-inline' 'unsafe-eval'"

Iframe Interception and Script Injection

Embedded iframes present a second problem: their content is loaded from the proxy, but the iframe's browsing context does not automatically have the Service Worker or the main-thread interceptor active. If the proxied page creates an <iframe src="https://widget.example.com/...">, that iframe URL must also be rewritten to the proxy format, and the proxy's interceptor scripts must be injected into the iframe's document.

The iframe interceptor operates at two levels:

Level 1 — Prototype patching (catches programmatic iframe creation):

-- Pseudocode: intercept iframe src assignment

override HTMLIFrameElement.prototype.src setter:
    if value is not already a proxy URL:
        value = toProxyURL(value)   -- rewrite to proxy format
    call original setter(value)
    scheduleProxyInjection(this)    -- inject interceptor into iframe document

Level 2 — MutationObserver fallback (catches DOM-inserted iframes):

-- Pseudocode: observe DOM for dynamically added iframes

observer = new MutationObserver(mutations):
    for mutation in mutations:
        for node in mutation.addedNodes:
            if node is an <iframe>:
                rewriteSrcIfNeeded(node)
                injectProxyScript(node)

observer.observe(document, { childList: true, subtree: true })

The sandbox Attribute Problem

The HTML sandbox attribute restricts what an iframe can do: sandbox="allow-scripts allow-same-origin" controls script execution, form submission, cross-origin access, etc. For proxy injection to work, the iframe needs to run scripts and have access to the parent's proxy context.

The allow-same-origin token is particularly nuanced: when present along with allow-scripts, it defeats the sandbox's origin isolation — the iframe runs with the origin of the embedding page. When absent, the iframe gets a unique opaque origin, which would break proxy script injection entirely.

ProxyOrb's current approach for sandbox attributes is to remove the sandbox attribute entirely before injecting the proxy script:

-- Pseudocode: handle sandbox attribute before proxy injection

function handleSandboxedIframe(iframe):
    if iframe.hasAttribute("sandbox"):
        -- Remove so the proxy can inject scripts and access contentWindow
        iframe.removeAttribute("sandbox")
    injectProxyScript(iframe)

This is a significant security trade-off: the sandboxing was intentionally placed by the original site to restrict the embedded content's capabilities. Removing it expands what that content can do. It is the kind of decision that is invisible to end users but materially affects the security posture of the proxy session.

8. ਪ੍ਰੌਕਸੀ ਆਪਰੇਟਰਾਂ ਲਈ ਸੁਰੱਖਿਆ ਪ੍ਰਭਾਵ

ਅਟੈਕ ਸਰਫੇਸ ਲੈਂਡਸਕੇਪ

ਜਦੋਂ ਉਪਭੋਗਤਾ ProxyOrb ਦੁਆਰਾ ਬ੍ਰਾਊਜ਼ ਕਰਦੇ ਹਨ, ਤਾਂ ਪ੍ਰੌਕਸੀ ਦੇ ਮੂਲ ਦੁਆਰਾ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਦੀਆਂ ਕਈ ਸ਼੍ਰੇਣੀਆਂ ਪ੍ਰਵਾਹ ਕਰਦੀਆਂ ਹਨ:

ਸੈਸ਼ਨ ਕੂਕੀਜ਼: ਕਿਉਂਕਿ ਸਾਰੀਆਂ ਟਾਰਗੇਟ ਸਾਈਟਾਂ proxyorb.com ਰਾਹੀਂ ਪ੍ਰੌਕਸੀ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਕੂਕੀਜ਼ ਉਸ ਮੂਲ ਦੇ ਅਧੀਨ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ ਉਪਭੋਗਤਾ ਦੇ ਉਹਨਾਂ ਦੇ ਬੈਂਕ, ਈਮੇਲ ਅਤੇ ਸੋਸ਼ਲ ਮੀਡੀਆ ਦੇ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਸੈਸ਼ਨ ਇੱਕ ਸਿੰਗਲ ਡੋਮੇਨ ਦੇ ਅਧੀਨ ਸਾਰੀਆਂ ਕੂਕੀਜ਼ ਹਨ। ਸਰਵਿਸ ਵਰਕਰ ਦੇ 'ਪ੍ਰਮਾਣ ਪੱਤਰ: 'ਸ਼ਾਮਲ ਕਰੋ' ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਕੂਕੀਜ਼ ਹਰ ਪ੍ਰੌਕਸੀ ਬੇਨਤੀ ਦੇ ਨਾਲ ਹਨ।

ਰੈਫਰਰ ਹੈਡਰ: ਅੱਪਸਟ੍ਰੀਮ ਸਰਵਰਾਂ ਨੂੰ ਭੇਜਿਆ ਗਿਆ 'ਰੈਫਰਰ' ਹੈਡਰ ਦੱਸਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਕਿਹੜਾ ਪੰਨਾ ਦੇਖ ਰਿਹਾ ਸੀ। ਟਾਰਗੇਟ ਸਰਵਰ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੌਕਸੀ ਧਿਆਨ ਨਾਲ ਆਪਣੇ ਖੁਦ ਦੇ ਡੋਮੇਨ ਨੂੰ ਰੈਫਰਰ ਮੁੱਲਾਂ ਤੋਂ ਹਟਾ ਦਿੰਦੀ ਹੈ। ਜੇਕਰ ਕੋਈ ਬੇਨਤੀ https://proxyorb.com/some/path?__pot=... ਤੋਂ ਉਤਪੰਨ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਆਊਟਬਾਉਂਡ ਰੈਫਰਰ ਸਿਰਲੇਖ ਨੂੰ ਮੂਲ ਟਾਰਗੇਟ URL (https://example.com/some/path) ਦੇ ਰੂਪ ਵਿੱਚ ਪੁਨਰਗਠਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ — ਪ੍ਰੌਕਸੀ ਡੋਮੇਨ ਕਦੇ ਵੀ ਅੱਪਸਟ੍ਰੀਮ ਸਰਵਰਾਂ ਨੂੰ ਲੀਕ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

-- Pseudocode: normalize referer before forwarding upstream

function sanitizeReferer(referer):
    if referer is a proxy URL:
        return reconstruct_original_url(referer)   -- e.g. "https://example.com/path"
    if referer's origin equals proxy_origin:
        return ""   -- suppress: don't leak proxy domain to upstream
    return referer

JavaScript ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸੰਦਰਭ: ਪ੍ਰੌਕਸੀ ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਹਰ JavaScript ਫਾਈਲ ਨੂੰ ਸੋਧਿਆ ਜਾਂਦਾ ਹੈ (URL ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ) ਅਤੇ ਪ੍ਰੌਕਸੀ ਦੇ ਮੂਲ ਵਿੱਚ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ। ProxyOrb ਦੁਆਰਾ ਪ੍ਰੌਕਸੀ ਕੀਤੀ ਗਈ evil.example.com ਤੋਂ ਇੱਕ ਖਤਰਨਾਕ ਸਕ੍ਰਿਪਟ proxyorb.com ਮੂਲ ਵਿੱਚ ਚੱਲਦੀ ਹੈ ਅਤੇ ਉਸ ਮੂਲ ਦੀ ਸਥਾਨਕ ਸਟੋਰੇਜ, ਕੂਕੀਜ਼, ਅਤੇ IndexedDB ਤੱਕ ਪੂਰੀ ਪਹੁੰਚ ਹੁੰਦੀ ਹੈ — ਜਿਸ ਵਿੱਚ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਪਹੁੰਚ ਕੀਤੀ ਗਈ ਹਰ ਹੋਰ ਟੀਚਾ ਸਾਈਟ ਦਾ ਡੇਟਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ।

ਖਤਰਨਾਕ ਪ੍ਰੌਕਸੀ ਧਮਕੀ ਮਾਡਲ

ਵਿਦਿਅਕ ਉਦੇਸ਼ਾਂ ਲਈ, ਇਸ ਬਾਰੇ ਸਪੱਸ਼ਟ ਹੋਣਾ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿ ਇੱਕ ਖਤਰਨਾਕ ਪ੍ਰੌਕਸੀ ਕੀ ਕਰ ਸਕਦੀ ਹੈ ਜੋ ProxyOrb ਜਾਣਬੁੱਝ ਕੇ ਨਹੀਂ ਕਰਦਾ:

  1. ਕ੍ਰੀਡੈਂਸ਼ੀਅਲ ਹਾਰਵੈਸਟਿੰਗ: ਇੱਕ ਖਤਰਨਾਕ ਪ੍ਰੌਕਸੀ ਗੇਟਵੇ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹੋਏ ਹਰੇਕ ਬੇਨਤੀ ਬਾਡੀ (ਪਾਸਵਰਡ ਅਤੇ ਫਾਰਮ ਡੇਟਾ ਵਾਲੇ) ਨੂੰ ਲੌਗ ਕਰ ਸਕਦੀ ਹੈ।

  2. ਸੈਸ਼ਨ ਹਾਈਜੈਕਿੰਗ: ਕਿਉਂਕਿ ਸਾਰੀਆਂ ਟਾਰਗੇਟ ਸਾਈਟ ਕੂਕੀਜ਼ ਪ੍ਰੌਕਸੀ ਡੋਮੇਨ ਦੇ ਅਧੀਨ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇੱਕ ਖਤਰਨਾਕ ਪ੍ਰੌਕਸੀ ਆਪਰੇਟਰ ਗੇਟਵੇ ਰਾਹੀਂ ਉਹਨਾਂ ਕੂਕੀਜ਼ ਸਰਵਰ-ਸਾਈਡ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ।

  3. ਸਮੱਗਰੀ ਇੰਜੈਕਸ਼ਨ: ਪ੍ਰੌਕਸੀ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਪੰਨੇ ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਸੋਧਦੀ ਹੈ (ਸਰਵਿਸ ਵਰਕਰ ਨੂੰ ਇੰਜੈਕਟ ਕਰਨ ਅਤੇ URL ਨੂੰ ਮੁੜ ਲਿਖਣ ਲਈ)। ਇੱਕ ਖਤਰਨਾਕ ਪ੍ਰੌਕਸੀ ਮਨਮਾਨੇ JavaScript ਨੂੰ ਇੰਜੈਕਟ ਕਰ ਸਕਦੀ ਹੈ — ਕੀਲੌਗਰ, ਕ੍ਰਿਪਟੋ ਮਾਈਨਰ, ਵਿਗਿਆਪਨ ਧੋਖਾਧੜੀ ਸਕ੍ਰਿਪਟਾਂ — ਉਪਭੋਗਤਾ ਲਈ ਅਦਿੱਖ।

  4. SSL ਸਟ੍ਰਿਪਿੰਗ: ਜੇਕਰ ਪ੍ਰੌਕਸੀ ਗੇਟਵੇ-ਟੂ-ਯੂਜ਼ਰ ਲੈਗ ਲਈ HTTPS ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ HTTP 'ਤੇ ਡਾਊਨਗ੍ਰੇਡ ਕਰਦੀ ਹੈ, ਤਾਂ ਸਾਰਾ ਟ੍ਰੈਫਿਕ ਪਲੇਨਟੈਕਸਟ ਹੁੰਦਾ ਹੈ।

ProxyOrb HTTPS ਐਂਡ-ਟੂ-ਐਂਡ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਬੇਨਤੀ ਬਾਡੀਜ਼ ਨੂੰ ਲੌਗ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਦੇ ਆਪਰੇਟਰ ਕੋਲ ਇਹ ਸਮਰੱਥਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਇਸੇ ਕਰਕੇ ਭਰੋਸੇਯੋਗ ਪ੍ਰੌਕਸੀ ਆਪਰੇਟਰ ਦੀ ਚੋਣ ਕਰਨਾ ਓਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਿੰਨਾ ਕਿ ਇੱਕ ਭਰੋਸੇਮੰਦ VPN ਪ੍ਰਦਾਤਾ ਨੂੰ ਚੁਣਨਾ।

ਮਿਸ਼ਰਤ ਸਮੱਗਰੀ

ਆਧੁਨਿਕ ਬ੍ਰਾਊਜ਼ਰ ਮਿਸ਼ਰਤ ਸਮੱਗਰੀ ਨੂੰ ਬਲੌਕ ਕਰਨ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ: ਇੱਕ HTTPS ਪੰਨਾ HTTP ਉਪ-ਸਰੋਤ ਲੋਡ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ProxyOrb ਗੇਟਵੇ ਤੋਂ ਸਾਰੇ ਆਊਟਬਾਉਂਡ ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ HTTPS ਲਾਗੂ ਕਰਕੇ ਇਸ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ, ਭਾਵੇਂ ਟੀਚਾ URL HTTP ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। CSP ਓਵਰਰਾਈਡ ਵਿੱਚ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਲੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਵੀ HTTP ਉਪ-ਸਰੋਤ URL ਨੂੰ HTTPS ਵਿੱਚ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਲਈ ਨਿਰਦੇਸ਼ ਦੇਣ ਲਈ ਅੱਪਗ੍ਰੇਡ-ਅਸੁਰੱਖਿਅਤ-ਬੇਨਤੀ ਸ਼ਾਮਲ ਹਨ।

ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਫਾਇਦੇਮੰਦ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ ਉਹਨਾਂ ਸਾਈਟਾਂ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ ਜੋ ਜਾਣਬੁੱਝ ਕੇ HTTP (ਪੁਰਾਣੇ CDN, ਲੋਕਲਹੋਸਟ ਸਰੋਤ, ਆਦਿ) ਉੱਤੇ ਸਰੋਤਾਂ ਦੀ ਸੇਵਾ ਕਰਦੀਆਂ ਹਨ।

9. The Ongoing Arms Race: Conclusion

When we started building ProxyOrb, the primary compatibility challenges were CORS and X-Frame-Options. Since then, Chromium has shipped CORB, CORP, COEP, COOP, and is developing Document-Isolation-Policy. The direction of travel is clear: browsers are becoming more aggressive about enforcing cross-origin boundaries, and each new mechanism requires proxy infrastructure to adapt.

The most significant upcoming challenge is likely the full deployment of COEP across major web applications. Sites that use SharedArrayBuffer for performance (video editors, IDEs, collaboration tools) are increasingly setting COEP: require-corp. As ProxyOrb strips this header to maintain compatibility, users who need the high-performance features that COEP enables will find them degraded in a proxy context.

For security researchers, the proxy architecture reveals something important: the same-origin policy is not a firewall. It is a model of trust based on URL structure. Web proxies exploit the fact that the SOP makes no intrinsic distinction between "these two resources are legitimately same-origin" and "these two resources have been URL-rewritten to look same-origin." The entire browser security stack above the SOP — CORS, CORB, CORP, COEP, COOP — can be seen as an attempt to add defenses that are more robust than URL-based origin identity.

Understanding this is essential for anyone auditing proxy services, designing browser security policies, or evaluating the real-world security posture of applications that may be accessed through proxies.

ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ

ਕੀ ਇੱਕ ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਇੱਕੋ-ਮੂਲ ਨੀਤੀ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੀ ਹੈ?

ਬਿਲਕੁਲ ਨਹੀਂ। ਇੱਕ ਵੈੱਬ ਪ੍ਰੌਕਸੀ URL ਰੀਰਾਈਟਿੰਗ ਦੁਆਰਾ ਕੰਮ ਕਰਦੀ ਹੈ: ਇਹ ਸਾਰੇ ਕ੍ਰਾਸ-ਮੂਲ URL ਨੂੰ ਇੱਕੋ-ਮੂਲ URL ਵਿੱਚ ਬਦਲਦਾ ਹੈ, SOP ਦੇ ਅੰਤਰ-ਮੂਲ ਪਾਬੰਦੀਆਂ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦੀ ਬਜਾਏ ਅਪ੍ਰਸੰਗਿਕ ਬਣਾਉਂਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਸਾਰੀ ਸਮੱਗਰੀ ਪ੍ਰੌਕਸੀ ਦੇ ਆਪਣੇ ਮੂਲ ਤੋਂ ਆਉਂਦੀ ਪ੍ਰਤੀਤ ਹੁੰਦੀ ਹੈ, ਇਸਲਈ ਕੋਈ ਅੰਤਰ-ਮੂਲ ਸੀਮਾਵਾਂ ਨੂੰ ਪਾਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਆਰਕੀਟੈਕਚਰਲ ਤੌਰ 'ਤੇ ਬਾਈਪਾਸ ਤੋਂ ਵੱਖਰਾ ਹੈ — SOP ਅਜੇ ਵੀ ਆਪਣੇ ਨਿਯਮਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ; ਪ੍ਰੌਕਸੀ ਸਿਰਫ਼ ਸਮੱਗਰੀ ਨੂੰ ਇੰਜਨੀਅਰ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ ਉਹ ਨਿਯਮ ਕਦੇ ਟਰਿੱਗਰ ਨਾ ਹੋਣ।

CORS ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਸਰਵਰਾਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ?

CORS ਦੋ ਪੱਧਰਾਂ 'ਤੇ ਪ੍ਰੌਕਸੀ ਸਰਵਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਪਹਿਲਾਂ, ਪ੍ਰੌਕਸੀ ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ 'ਵਿਕਲਪਾਂ' ਪ੍ਰੀਫਲਾਈਟ ਬੇਨਤੀਆਂ ਨੂੰ ਰੋਕਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਆਗਿਆਕਾਰੀ CORS ਸਿਰਲੇਖਾਂ ਨਾਲ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਅਸਲ ਟੀਚਾ ਸਰਵਰ ਦਾ ਪ੍ਰੀਫਲਾਈਟ ਜਵਾਬ (ਨਿਸ਼ਾਨਾ ਮੂਲ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹੋਏ) ਪ੍ਰੌਕਸੀ ਮੂਲ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਦੀ CORS ਜਾਂਚ ਨੂੰ ਸੰਤੁਸ਼ਟ ਨਹੀਂ ਕਰੇਗਾ। ਦੂਜਾ, ਪ੍ਰੌਕਸੀ ਨੂੰ ਟੀਚਾ ਸਰਵਰ ਜਵਾਬਾਂ ਤੋਂ CORS ਸਿਰਲੇਖਾਂ ਨੂੰ ਹਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰੌਕਸੀ ਮੂਲ ਦਾ ਹਵਾਲਾ ਦੇਣ ਵਾਲੇ ਸਿਰਲੇਖਾਂ ਨਾਲ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਰਵਿਸ ਵਰਕਰ ਵਿੱਚ ਪਹੁੰਚ-ਕੰਟਰੋਲ-ਅਲੋ-ਕ੍ਰੀਡੈਂਸ਼ੀਅਲਸ: ਸਹੀ ਸੈਟਿੰਗ, `ਕ੍ਰੀਡੈਂਸ਼ੀਅਲ: 'ਸ਼ਾਮਲ ਕਰੋ' ਦੇ ਨਾਲ, ਭਾਵ ਪ੍ਰੌਕਸੀ ਦੇ ਮੂਲ ਤੋਂ ਸਾਰੀਆਂ ਕੂਕੀਜ਼ ਹਰ ਪ੍ਰੌਕਸੀ ਬੇਨਤੀ ਦੇ ਨਾਲ ਹੁੰਦੀਆਂ ਹਨ।

CORB ਕੀ ਹੈ ਅਤੇ ਇਹ ਪ੍ਰੌਕਸੀ ਸੇਵਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ?

ਕ੍ਰਾਸ-ਓਰਿਜਨ ਰੀਡ ਬਲੌਕਿੰਗ (CORB) ਇੱਕ Chromium ਰੱਖਿਆ ਹੈ ਜੋ ਕੁਝ ਸੰਵੇਦਨਸ਼ੀਲ ਕਰਾਸ-ਓਰੀਜਨ ਜਵਾਬਾਂ (HTML, JSON, XML) ਨੂੰ ਰੈਂਡਰਰ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ਜਦੋਂ ਕ੍ਰਾਸ-ਓਰੀਜਨ ਉਪ-ਸਰੋਤਾਂ ਵਜੋਂ ਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤੀਆਂ ਵੈੱਬ ਪ੍ਰੌਕਸੀਆਂ ਲਈ, CORB ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਚਾਲੂ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ URL ਮੁੜ ਲਿਖਣਾ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਇੱਕੋ-ਮੂਲ ਬਣਾਉਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ, CORB ਸਰਵਿਸ ਵਰਕਰ ਦੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰਜਿਸਟਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਮਿਆਦ ਦੇ ਦੌਰਾਨ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕੁਝ ਬੇਨਤੀਆਂ URL ਰੀਰਾਈਟਿੰਗ ਤੋਂ ਬਚ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਅਸਲ ਅੰਤਰ-ਮੂਲ ਬੇਨਤੀਆਂ ਵਜੋਂ ਭੇਜੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। CORB ਨੂੰ ਇੱਕ ਸਪੈਕਟਰ ਮਿਟੀਗੇਸ਼ਨ ਦੇ ਤੌਰ 'ਤੇ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ WHATWG Fetch ਨਿਰਧਾਰਨ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਕੀ ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਸਿਰਫ਼ HTTP-ਕੁਕੀਜ਼ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦੇ ਹਨ?

ਨੰਬਰ HttpOnly ਕੂਕੀਜ਼ ਟਾਰਗੇਟ ਸਰਵਰ ਦੁਆਰਾ ਸੈਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ JavaScript ਦੁਆਰਾ ਪੜ੍ਹੀਆਂ ਨਹੀਂ ਜਾ ਸਕਦੀਆਂ — ਜਿਸ ਵਿੱਚ JavaScript ਇੱਕ ਸਰਵਿਸ ਵਰਕਰ ਵਿੱਚ ਚੱਲ ਰਹੀ ਹੈ। ਹਾਲਾਂਕਿ, ਉਪਭੋਗਤਾ ਦੀ ਤਰਫੋਂ ਬੇਨਤੀਆਂ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਵੇਲੇ ਗੇਟਵੇ ਇਹ ਕੂਕੀਜ਼ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਉਹਨਾਂ ਨੂੰ ਬੇਨਤੀ ਸਿਰਲੇਖਾਂ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। 'HttpOnly' ਫਲੈਗ ਕਲਾਇੰਟ-ਸਾਈਡ JavaScript ਚੋਰੀ ਨੂੰ ਰੋਕਦਾ ਹੈ ਪਰ ਪ੍ਰੌਕਸੀ ਸਰਵਰ ਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਟ੍ਰਾਂਜਿਟ ਵਿੱਚ ਕੂਕੀ ਮੁੱਲਾਂ ਨੂੰ ਦੇਖਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ। ਇਹ ਇਸਦੇ ਸਮਾਨ ਹੈ ਕਿ ਕਿਵੇਂ 'HttpOnly' XSS ਤੋਂ ਸੁਰੱਖਿਆ ਕਰਦਾ ਹੈ ਪਰ ਸਰਵਰ-ਸਾਈਡ ਰੁਕਾਵਟ ਦੇ ਵਿਰੁੱਧ ਨਹੀਂ।

ਕੀ ਬ੍ਰਾਊਜ਼ਰ ਸੁਰੱਖਿਆ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੁਰੱਖਿਅਤ ਹੈ?

ਇਹ ਧਮਕੀ ਮਾਡਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ. ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਵੈੱਬ ਪ੍ਰੌਕਸੀ ਦੁਆਰਾ ਦਿੱਤੀ ਗਈ ਸਾਰੀ ਸਮੱਗਰੀ ਪ੍ਰੌਕਸੀ ਦੇ ਮੂਲ ਵਿੱਚ ਚਲਦੀ ਹੈ, ਭਾਵ ਇੱਕ ਪ੍ਰੌਕਸੀਡ ਸਾਈਟ ਦੀ JavaScript ਵਿੱਚ ਇੱਕ ਕਮਜ਼ੋਰੀ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਕਿਸੇ ਹੋਰ ਪ੍ਰੌਕਸੀਡ ਸਾਈਟ ਦੇ ਸੈਸ਼ਨ ਤੋਂ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦੀ ਹੈ (ਕਿਉਂਕਿ ਉਹ ਉਸੇ ਮੂਲ ਦੇ ਕੂਕੀ ਜਾਰ ਅਤੇ ਸਟੋਰੇਜ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ)। ਪਰਾਕਸੀ ਦਾ ਆਪਰੇਟਰ ਟਰਾਂਜ਼ਿਟ ਵਿੱਚ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਤੱਕ ਪਹੁੰਚ ਵਾਲੀ ਇੱਕ ਭਰੋਸੇਯੋਗ ਧਿਰ ਵੀ ਹੈ। ਪ੍ਰਤੀਬੰਧਿਤ ਵਾਤਾਵਰਣ ਵਿੱਚ ਗੈਰ-ਸੰਵੇਦਨਸ਼ੀਲ ਸਮੱਗਰੀ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ, ਜੋਖਮ ਆਮ ਤੌਰ 'ਤੇ ਸਵੀਕਾਰਯੋਗ ਹੁੰਦਾ ਹੈ। ਸੰਵੇਦਨਸ਼ੀਲ ਸੇਵਾਵਾਂ (ਬੈਂਕਿੰਗ, ਹੈਲਥਕੇਅਰ, ਸਰਕਾਰ) ਦੇ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਸੈਸ਼ਨਾਂ ਲਈ, ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇਹ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਪ੍ਰੌਕਸੀ ਆਪਰੇਟਰ ਕੋਲ ਉਸ ਟ੍ਰੈਫਿਕ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਤਕਨੀਕੀ ਸਮਰੱਥਾ ਹੈ, ਅਤੇ ਉਸਨੂੰ ਆਡਿਟ ਯੋਗ ਨੋ-ਲੌਗ ਨੀਤੀਆਂ ਅਤੇ ਮਜ਼ਬੂਤ ​​ਸੰਚਾਲਨ ਸੁਰੱਖਿਆ ਅਭਿਆਸਾਂ ਵਾਲੀਆਂ ਕੇਵਲ ਪ੍ਰੌਕਸੀ ਸੇਵਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

This article reflects ProxyOrb's architecture as of early 2026. Browser security mechanisms evolve rapidly; readers are encouraged to check the WHATWG Fetch Standard, the W3C Content Security Policy specification, and Chromium's security design documents for the most current information.