सेम ओरिजिन पॉलिसी और वेब प्रॉक्सी: एक टेक्निकल सिक्योरिटी एनालिसिस

जब हमने ProxyOrb बनाया, तो हर डिज़ाइन decision पर एक fundamental paradox सामने आता था: एक वेब प्रॉक्सी इसलिए काम करता है क्योंकि वो ब्राउज़र को यह यकीन दिलाता है कि third-party content दरअसल same-origin content है। यानी, definition के हिसाब से, ब्राउज़र के core security model को धोखा देना। लेकिन modern browsers ने पिछले पंद्रह साल में ठीक इसी तरह के origin confusion के खिलाफ layer-by-layer defenses बनाई हैं।

यह article उस tension को first principles से examine करता है। अगर आप security researcher, penetration tester, या browser security engineer हैं और जानना चाहते हैं कि वेब प्रॉक्सी सिक्योरिटी असल में सेम ओरिजिन पॉलिसी से कैसे interact करती है — conceptual level पर नहीं, बल्कि HTTP headers, Chromium source code और production engineering trade-offs के level पर — तो यह article आपके लिए है।

हम SOP foundation, URL rewriting, CORS, CORB/CORP, COEP/COOP, Service Workers, iframes, और proxy operators और उनके users दोनों के लिए security implications को cover करेंगे।

1. सेम ओरिजिन पॉलिसी का आधार

सेम ओरिजिन पॉलिसी (SOP) एक three-tuple से define होती है: scheme + host + port। दो URLs तभी same-origin होती हैं जब तीनों components exactly match करें। https://example.com:443 और http://example.com:80 same server की तरफ point करते हैं फिर भी cross-origin हैं।

अक्सर गलतफहमी यह रहती है कि SOP actually क्या रोकती है और क्या allow करती है। SOP इन्हें block नहीं करती:

• origins के पार images load करना (<img src>)
• origins के पार scripts load करना (<script src>)
• origins के पार stylesheets load करना (<link rel="stylesheet">)
• cross-origin iframes embed करना (हालांकि embedded document का content isolated रहता है)
• cross-origin form submissions भेजना (<form action>)

SOP जो actually रोकती है वो है fetch() या XMLHttpRequest के ज़रिए की गई cross-origin requests का response read करना। Request जाती है — network round-trip होता है — लेकिन response body और headers उस JavaScript से छुपाए जाते हैं जो किसी different origin पर run हो रही है।

यह distinction वेब प्रॉक्सी के लिए बेहद ज़रूरी है। प्रॉक्सी का पूरा काम ही यही है कि दो origins (proxy server और target server) को एक में collapse करे, cross-origin boundary को खत्म करे। एक बार जब सभी resources https://proxyorb.com से आती दिखें, तो responses read करने पर SOP-based restrictions लागू ही नहीं होतीं।

वेब प्रॉक्सी जिस "legitimate space" को exploit करता है वो है URL rewriting: https://example.com/api/data की जगह हर request https://proxyorb.com/api/data?__pot=aHR0cHM6Ly9leGFtcGxlLmNvbQ== बन जाती है। ब्राउज़र की नज़र में यह same-origin request है। SOP को bypass नहीं किया गया — बल्कि सभी content का apparent origin बदलकर उसे irrelevant बना दिया गया।

2. ProxyOrb का URL Rewriting Architecture

Security implications समझने के लिए encoding mechanism को समझना ज़रूरी है। ProxyOrb __pot (proxy origin token) नाम का एक URL parameter use करता है जिसमें Base64-encoded target origin होता है।

__pot Parameter

__pot parameter हमेशा target का origin (scheme + host, कोई path नहीं) encode करता है, पूरी URL नहीं। यानी https://example.com/some/deep/path?foo=bar और https://example.com/other/page दोनों का __pot value एक ही होगा: aHR0cHM6Ly9leGFtcGxlLmNvbQ== (यह https://example.com की Base64 encoding है)। असली path और query string proxy URL के अपने path और query string में verbatim preserve रहती है।

जब user https://proxyorb.com/?__pot=aHR0cHM6Ly9leGFtcGxlLmNvbQ== पर navigate करता है, तो gateway उसे decode करके original URL reconstruct करता है:

-- 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

इसके बाद gateway request को real target server पर forward करता है, Origin header को rewrite करके ताकि upstream server अपना ही domain देखे, proxy domain नहीं:

-- 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

Service Worker के ज़रिए Client-Side URL Rewriting

Gateway server side handle करता है। Client side — HTML, JavaScript, और CSS responses में URLs को rewrite करना ताकि सभी sub-requests proxy से होकर गुज़रती रहें — यह काम Service Worker करता है।

Core transformation किसी भी URL को proxy format में convert करती है:

-- 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

उदाहरण के लिए, proxy की गई किसी page में referenced https://cdn.example.com/bundle.js बन जाती है https://proxyorb.com/bundle.js?__pot=aHR0cHM6Ly9jZG4uZXhhbXBsZS5jb20=।

यह rewriting comprehensive है: इसमें fetch(), XMLHttpRequest, <script src>, <img src>, WebSocket connections, और <link> tags सब cover होते हैं। जब page का हर URL proxy origin की तरफ point करे, तो browser कभी cross-origin request नहीं करता — construction से ही हर request same-origin है।

बिना Full Navigation के __pot Recover करना

एक subtle edge case तब आता है जब requests proxied page के अंदर से originate होती हैं लेकिन __pot parameter नहीं होता — मसलन, एक relative fetch('/api/data') जो Service Worker के URL rewrite करने से पहले fire हो जाए, या dynamically-injected script की कोई request जो URL rewriter से निकल गई।

Service Worker missing token को एक cascading lookup से resolve करता है:

-- 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

Gateway के पास भी एक parallel recovery path है: अगर कोई request __pot के बिना आए लेकिन उसमें Referer header हो जो same-origin URL की तरफ point करे और उस URL में __pot हो, तो gateway referer से token extract करके current request में attach कर देता है। यह उन navigation scenarios को handle करता है जहाँ token gateway तक पहुँचने से पहले page के अपने JavaScript ने strip कर दिया था।

3. CORS: Explicit Cross-Origin Permission System

CORS (Cross-Origin Resource Sharing) इसलिए बनाया गया था ताकि servers specific response headers भेजकर cross-origin access को opt in कर सकें। CORS प्रॉक्सी सर्वर के perspective से दो अलग problems create करता है।

Problem 1: CORS Preflight Interception

जब किसी page पर run हो रहा JavaScript non-simple headers (जैसे Authorization, Content-Type: application/json) के साथ fetch() request करता है, तो browser पहले एक OPTIONS preflight request भेजता है। अगर target server का preflight response permissive CORS headers नहीं include करता, तो real request block हो जाती है।

ProxyOrb के architecture में, Service Worker सभी OPTIONS requests को intercept करता है और synthetically जवाब देता है — network तक पहुँचने से पहले ही — एक ऐसा response return करके जो real request को unblock करे:

-- 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",
    })

Gateway level पर, हर proxied response को 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

Access-Control-Allow-Credentials: true और non-wildcard Access-Control-Allow-Origin का combination significant है। CORS तब explicit origin value (न कि *) demand करता है जब credentials include हों। Service Worker सभी outbound requests credentials: 'include' के साथ issue करता है, इसलिए gateway को wildcard की जगह exact requesting origin echo back करना पड़ता है।

इसका मतलब है कि proxyorb.com के under stored सभी cookies — user ने proxy से जितनी target sites visit की हैं उन सभी की accumulated cookies — हर proxied request के साथ भेजी जाती हैं। यह intentional है (logged-in sites के लिए session state maintain होती है), लेकिन यह एक important security consideration भी है जिसकी हम Section 8 में चर्चा करेंगे।

CORS Header Strip-and-Replace Pattern

एक proxied response में target server के CORS headers हो सकते हैं जो browser के perspective से wrong हैं (वो proxy origin नहीं, target origin reference करते हैं)। Service Worker उन्हें strip करके replace करता है:

-- 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: Chromium की कड़ी Defenses

CORS servers के explicit opt-in पर operate करता है। Chromium ने दो ऐसे mechanisms add किए हैं जो CORS configuration के बावजूद, by default active रहते हैं।

Cross-Origin Read Blocking (CORB)

CORB को Chrome 67 (2018) में Spectre mitigations के हिस्से के रूप में introduce किया गया था। Core insight यह है: भले ही किसी cross-origin response की body JavaScript कभी read न करे, लेकिन यह fact कि उसे renderer process ने fetch और decode किया, यानी वो उस process के address space में exist करती है। Spectre-class attacks फिर उसे side channels के ज़रिए extract कर सकते हैं।

CORB कुछ cross-origin responses को renderer process में enter होने से रोकता है। Specifically, जब <script> या <img> tag कोई cross-origin response fetch करे और उस response का Content-Type text/html, text/xml, या application/json हो, तो Chromium body को inspect करता है (CORB spec में defined MIME-type sniffer use करके) और अगर type match करे तो renderer को देने से पहले response को empty से replace कर देता है।

वेब प्रॉक्सी के लिए CORB catastrophic होता अगर requests actually cross-origin होतीं। <script> tag से fetch की गई application/json return करने वाली API endpoint चुपचाप empty return कर देती। लेकिन चूँकि ProxyOrb सभी URLs को same-origin rewrite करता है, CORB की cross-origin condition कभी trigger नहीं होती — browser कभी cross-origin JSON response नहीं देखता क्योंकि उसके perspective से सभी responses proxyorb.com से आती हैं।

एकमात्र case जहाँ CORB matter करता है वो है Service Worker पूरी तरह register होकर requests intercept करने से पहले का transition period। अगर उस window में कोई request URL rewriting से बच निकले, तो CORB उसे block कर सकता है। यही race condition का कारण है कि ProxyOrb एक main-thread interceptor layer भी maintain करता है जो किसी भी page JavaScript के run होने से पहले synchronously XMLHttpRequest, fetch, और DOM attribute setters को patch करता है — Service Worker startup के दौरान fallback provide करने के लिए।

यह बताना ज़रूरी है कि CORB को partially Opaque Response Blocking (ORB) ने supersede किया है, जिसे Chromium adopt करने की प्रक्रिया में है। ORB CORB rules को refine करता है ताकि false positives कम हों लेकिन Spectre protections बनी रहें। Proxy compatibility implications similar हैं।

Cross-Origin Resource Policy (CORP)

CORP, Fetch spec में defined है, servers को यह declare करने देता है कि उनके resources केवल same-origin या same-site contexts से load होने चाहिए:

Cross-Origin-Resource-Policy: same-origin

जब Chromium किसी cross-origin sub-resource request पर यह header encounter करे, तो वो response को completely block कर देता है। यह CORB से ज़्यादा aggressive है — यह content type की परवाह किए बिना apply होता है और MIME sniffing से bypass नहीं किया जा सकता।

फिर से, चूँकि ProxyOrb की URL rewriting यह ensure करती है कि browser के perspective से सभी requests same-origin हैं, target servers के CORP headers blocking trigger नहीं करते। Gateway इन headers को defensively responses से strip भी करता है, उन edge cases को handle करने के लिए जहाँ कोई request URL rewriting के बिना slip through हो जाए।

CORP की deeper issue actually एक ऐसा case है जहाँ proxy architecture compatibility में मदद करती है: अगर https://api.example.com और https://www.example.com दोनों को proxy किया जा रहा है, तो दोनों same proxy origin पर map होते हैं, इसलिए एक से दूसरे का fetch genuinely same-origin है — CORP restrictions उनके बीच apply नहीं होतीं।

5. COEP और COOP: क्रॉस ओरिजिन आइसोलेशन

Chrome 92 (2021) से शुरू होकर, SharedArrayBuffer तक access — और extension में, कुछ performance APIs के लिए use होने वाले high-resolution timers तक — उन pages तक restrict कर दी गई जिन्होंने क्रॉस ओरिजिन आइसोलेशन में opt in किया है। इस opt-in के लिए दो response headers एक साथ काम करते हैं।

Cross-Origin-Embedder-Policy (COEP)

Cross-Origin-Embedder-Policy: require-corp

जब कोई page यह header भेजे, तो browser enforce करता है कि उस page द्वारा load किया गया हर sub-resource या तो:

1. Same-origin हो, OR
2. Explicitly Cross-Origin-Resource-Policy: cross-origin भेजे, OR
3. Credentialed fetch के लिए permissive CORS response हो

वेब प्रॉक्सी के लिए problem: अगर कोई target site अपने main document पर COEP: require-corp भेजे, और वो document proxy से उस header के साथ serve किया जाए, तो browser अब demand करता है कि उस page द्वारा load किया गया हर sub-resource भी opt in करे। जो resource नहीं करता — और ज़्यादातर नहीं करेंगे — उसके लिए network error आता है।

Cross-Origin-Opener-Policy (COOP)

Cross-Origin-Opener-Policy: same-origin

COOP यह control करता है कि कोई page cross-origin pages के साथ browsing context group share कर सकता है या नहीं। जब same-origin set हो, तो cross-origin navigation एक नया browsing context group open करती है, जिससे window.opener references और page और किसी cross-origin opener के बीच postMessage channels टूट जाते हैं।

Proxy के लिए, COOP COEP जितना immediately destructive नहीं है, लेकिन यह उन sites को ज़रूर तोड़ता है जो cross-origin postMessage flows पर rely करती हैं (OAuth popup flows इसका सबसे common example है)।

Proxy Operator की Dilemma

यह ProxyOrb पर सबसे कठिन trade-off है:

Option A: Responses से COEP और COOP strip करना।

• फायदा: Sub-resource loading normally काम करती है; proxied page ये restrictions apply नहीं करती।
• नुकसान: हम ऐसे security headers हटा रहे हैं जो target site ने intentionally set किए थे। अगर site Spectre-class attacks से sensitive data protect करने के लिए cross-origin isolation use कर रही थी, तो ये headers strip करने से वो risk फिर expose हो जाता है।

Option B: COEP और COOP preserve करना।

• फायदा: Target site का security intent honor होता है।
• नुकसान: जो भी sub-resource explicitly CORP: cross-origin set नहीं करती वो load होने में fail करेगी, जिससे ज़्यादातर complex web applications टूट जाएंगी।

ProxyOrb की current strategy Option A है: gateway responses से Cross-Origin-Embedder-Policy और Cross-Origin-Opener-Policy strip करता है। यह site compatibility maximize करता है। Security trade-off consciously किया गया है: वेब प्रॉक्सी के users यह accept करते हैं कि वो content को उसके intended deployment context से अलग environment में run कर रहे हैं।

हर नया browser security mechanism एक pattern follow करता है: पहले opt-in के रूप में introduce होता है (sites चाहें तो header भेजें), फिर धीरे-धीरे नई APIs के लिए default बनता है, और eventually mandatory enforcement के लिए consider होता है। COEP इसी path पर चला: Chrome 83 में optional, Chrome 91 में SharedArrayBuffer के लिए required। Third-party content embed करने वाली sites जो बिना coordination के थीं, उनका content broken हो गया। Web proxies इस problem को compound करते हैं क्योंकि वो definition से third-party content mediate करते हैं।

Browser security community इस problem से aware है। Emerging Document-Isolation-Policy proposal process isolation को cross-origin isolation requirements से decouple करने का aim रखता है, जिससे potentially सभी sub-resources को opt in करवाए बिना Spectre mitigations मिल सकें। जब वो ship होगा, isolation headers के साथ proxy compatibility बेहतर हो सकती है।

6. Service Worker: Browser-Side Trust Layer

Service Worker केवल एक optimization नहीं है — यह ProxyOrb के security model के लिए architecturally essential है। यहाँ बताते हैं क्यों।

Registration Scope Origin से Bind होती है

Service Worker एक scope के साथ register होता है जो हमेशा registering page के origin के अंदर होती है। जब ProxyOrb अपना Service Worker register करता है, तो scope https://proxyorb.com/ होती है, यानी यह उस origin के अंतर्गत किसी भी page से हर fetch को intercept करती है।

यही fundamental reason है कि why same-origin URL rewriting काम करती है: एक बार SW किसी client को control करे, तो उस client की हर network request — चाहे page में JavaScript किसी भी URL को fetch करने की कोशिश करे — पहले Service Worker से गुज़रती है।

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

Interception Pipeline

जब Service Worker कोई request intercept करता है, तो वो कई decision stages से गुज़रती है:

-- 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)

Transparent Header Forwarding

एक subtle challenge: browser JavaScript को Fetch API के ज़रिए कुछ "forbidden" request headers (Host, Origin, Referer, etc.) set करने से restrict करता है। Service Worker इसे workaround करता है — restricted headers को एक single custom passthrough header में encode करके; gateway फिर उन्हें decode करके target server पर forward करने से पहले apply करता है:

-- 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 का Trusted Intermediary के रूप में Security Implications

Security perspective से, Service Worker एक privileged position occupy करता है: यह अपनी scope में किसी भी page से की गई किसी भी request को inspect, modify, और forge कर सकता है। Legitimate proxy use के लिए, यही पूरा point है। लेकिन एक malicious proxy के लिए, यह एक extremely powerful attack surface होगा।

यही कारण है कि Service Worker script की trustworthiness सबसे ज़रूरी है। ProxyOrb interceptor script को अपने origin से HTTPS पर strict cache controls के साथ serve करता है। अगर कोई attacker modified Service Worker inject कर सके, तो वो affected users के सभी traffic को intercept कर सकता है — केवल proxy traffic नहीं, बल्कि उस origin के अंतर्गत pages की कोई भी request।

7. iframes: Frame-Ancestors की Problem

iframes regular sub-resources से एक अलग challenge present करते हैं क्योंकि उनमें अपना nested browsing context होता है, अपनी navigation, अपनी SOP boundary, और embedding restrictions का अपना set।

X-Frame-Options और frame-ancestors

दो mechanisms pages को iframes में embed होने से रोकते हैं:

Legacy: X-Frame-Options: DENY या X-Frame-Options: SAMEORIGIN

Modern: Content-Security-Policy: frame-ancestors 'none' या frame-ancestors 'self'

जब gateway किसी target page को proxy करे जो इनमें से कोई भी भेजे, तो proxy origin के अंतर्गत किसी iframe में वो page embed नहीं हो सकती। चूँकि X-Frame-Options: SAMEORIGIN target origin (example.com) reference करता है, और proxy proxyorb.com से page serve करता है, browser का same-origin check fail हो जाता है।

Proxy को proxied responses से ये headers strip करने होते हैं और CSP को permissive version से replace करना होता है:

-- 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 और Script Injection

Embedded iframes एक दूसरी problem present करते हैं: उनका content proxy से load होता है, लेकिन iframe का browsing context automatically Service Worker या main-thread interceptor को active नहीं रखता। अगर proxied page कोई <iframe src="https://widget.example.com/..."> create करे, तो उस iframe URL को भी proxy format में rewrite करना होगा, और proxy के interceptor scripts को iframe के document में inject करना होगा।

Iframe interceptor दो levels पर operate करता है:

Level 1 — Prototype patching (programmatic iframe creation को catch करता है):

-- 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 (DOM-inserted iframes को catch करता है):

-- 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 })

sandbox Attribute की Problem

HTML sandbox attribute restrict करती है कि iframe क्या कर सकता है: sandbox="allow-scripts allow-same-origin" script execution, form submission, cross-origin access आदि control करता है। Proxy injection काम करने के लिए iframe को scripts run करने और parent के proxy context तक access की ज़रूरत होती है।

allow-same-origin token particularly nuanced है: जब allow-scripts के साथ present हो, तो यह sandbox की origin isolation को defeat करता है — iframe embedding page के origin के साथ run होती है। जब absent हो, तो iframe को एक unique opaque origin मिलता है, जो proxy script injection को completely तोड़ देगा।

Sandbox attributes के लिए ProxyOrb का current approach है कि proxy script inject करने से पहले sandbox attribute को completely हटा दें:

-- 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)

यह एक significant security trade-off है: sandboxing को original site ने intentionally embedded content की capabilities restrict करने के लिए रखा था। उसे remove करने से वो content और ज़्यादा कर सकती है। यह उस तरह का decision है जो end users को invisible है लेकिन proxy session के security posture को materially affect करता है।

8. Proxy Operators के लिए Security Implications

Attack Surface का नक्शा

जब users ProxyOrb से browse करते हैं, तो sensitive data की कई categories proxy के origin से flow होती हैं:

Session Cookies: चूँकि सभी target sites proxyorb.com से proxy होती हैं, cookies उस origin के under store होती हैं। User के bank, email, और social media के साथ authenticated sessions — सभी एक single domain के अंतर्गत cookies हैं। Service Worker का credentials: 'include' का मतलब है कि ये cookies हर proxied request के साथ जाती हैं।

Referer Headers: Upstream servers को भेजा गया Referer header reveal करता है कि user कौन सी page देख रहा था। Proxy target server को forward करने से पहले referer values से अपना domain carefully strip करता है। अगर कोई request https://proxyorb.com/some/path?__pot=... से originate हो, तो outbound Referer header original target URL (https://example.com/some/path) के रूप में reconstruct होता है — proxy domain upstream servers को कभी leak नहीं होता।

-- 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 Execution Context: Proxy से serve हर JavaScript file को modify (URLs rewritten) किया जाता है और proxy के origin में execute किया जाता है। ProxyOrb से proxy किया गया evil.example.com का एक malicious script proxyorb.com origin में run होता है और उस origin के local storage, cookies, और IndexedDB तक full access रखता है — जिसमें हर दूसरी target site का data शामिल है जिसे user ने proxy से access किया है।

Malicious Proxy Threat Model

Educational purposes के लिए, यह explicit होना ज़रूरी है कि एक malicious proxy क्या कर सकता है जो ProxyOrb deliberately नहीं करता:

1. Credential Harvesting: एक malicious proxy gateway से गुज़रते हुए हर request body (जिसमें passwords और form data हो) को log कर सकता है।

2. Session Hijacking: चूँकि सभी target site cookies proxy domain के अंतर्गत store हैं, एक malicious proxy operator उन cookies को gateway के ज़रिए server-side access कर सकता है।

3. Content Injection: Proxy necessarily page content modify करता है (Service Worker inject करने और URLs rewrite करने के लिए)। एक malicious proxy arbitrary JavaScript inject कर सकता है — keyloggers, crypto miners, ad fraud scripts — user को invisible।

4. SSL Stripping: अगर proxy gateway-to-user leg के लिए HTTPS connections को HTTP में downgrade करे, तो सभी traffic plaintext हो जाता है।

ProxyOrb end-to-end HTTPS पर operate करता है और request bodies log नहीं करता। किसी भी वेब प्रॉक्सी के operator के पास ये capabilities होती हैं, यही कारण है कि एक trustworthy proxy operator चुनना उतना ही matter करता है जितना trustworthy VPN provider चुनना।

Mixed Content

Modern browsers mixed content blocking enforce करते हैं: एक HTTPS page HTTP sub-resources load नहीं कर सकती। ProxyOrb इसे gateway से सभी outbound connections पर HTTPS enforce करके handle करता है, भले ही target URL HTTP use करे। CSP override में upgrade-insecure-requests शामिल है ताकि browser को load करने से पहले किसी भी HTTP sub-resource URL को HTTPS में upgrade करने के लिए instruct किया जा सके।

यह generally desirable है, लेकिन यह उन sites को तोड़ सकता है जो deliberately HTTP पर resources serve करती हैं (legacy CDNs, localhost resources, आदि)।

9. चलती आँख-मिचौनी: निष्कर्ष

जब हमने ProxyOrb बनाना शुरू किया था, तो primary compatibility challenges CORS और X-Frame-Options थे। तब से, Chromium ने CORB, CORP, COEP, COOP ship किए हैं और Document-Isolation-Policy develop कर रहा है। Direction of travel clear है: browsers cross-origin boundaries enforce करने में ज़्यादा aggressive होते जा रहे हैं, और हर नए mechanism के लिए proxy infrastructure को adapt करना पड़ता है।

सबसे significant upcoming challenge शायद major web applications में COEP का full deployment होगा। Performance के लिए SharedArrayBuffer use करने वाली sites (video editors, IDEs, collaboration tools) increasingly COEP: require-corp set कर रही हैं। जैसे-जैसे ProxyOrb compatibility maintain करने के लिए इस header को strip करता है, जो users COEP enable करने वाले high-performance features चाहते हैं उन्हें proxy context में degraded experience मिलेगी।

Security researchers के लिए, proxy architecture कुछ important reveal करती है: सेम ओरिजिन पॉलिसी firewall नहीं है। यह URL structure पर based trust का एक model है। वेब प्रॉक्सी इस fact को exploit करते हैं कि SOP "ये दो resources legitimately same-origin हैं" और "इन दो resources को same-origin दिखने के लिए URL-rewrite किया गया है" में कोई intrinsic distinction नहीं करती। SOP के ऊपर पूरा browser security stack — CORS, CORB, CORP, COEP, COOP — को ऐसी defenses add करने की कोशिश के रूप में देखा जा सकता है जो URL-based origin identity से ज़्यादा robust हों।

यह समझना उन सभी के लिए essential है जो proxy services audit कर रहे हों, browser security policies design कर रहे हों, या उन applications की real-world security posture evaluate कर रहे हों जिन्हें proxies से access किया जा सकता है।

अक्सर पूछे जाने वाले सवाल

क्या वेब प्रॉक्सी सेम ओरिजिन पॉलिसी को bypass करता है?

बिल्कुल नहीं। वेब प्रॉक्सी URL rewriting से काम करता है: यह सभी cross-origin URLs को same-origin URLs में transform करता है, जिससे SOP की cross-origin restrictions bypass होने की बजाय irrelevant हो जाती हैं। Browser के perspective से, सभी content proxy के अपने origin से आती दिखती है, इसलिए कोई cross-origin boundary cross नहीं होती। यह architecturally bypass से अलग है — SOP अपने rules enforce करती रहती है; proxy बस content को इस तरह engineer करता है कि वो rules कभी trigger न हों।

CORS वेब प्रॉक्सी सर्वर को कैसे affect करता है?

CORS proxy servers को दो levels पर affect करता है। पहला, proxy को OPTIONS preflight requests intercept करके permissive CORS headers के साथ respond करना होता है, क्योंकि real target server का preflight response (target origin reference करते हुए) proxy origin के browser के CORS check को satisfy नहीं करेगा। दूसरा, proxy को target server responses से CORS headers strip करके proxy origin reference करने वाले headers से replace करने होते हैं। Access-Control-Allow-Credentials: true setting, Service Worker में credentials: 'include' के साथ मिलकर, यह ensure करती है कि proxy origin के सभी cookies हर proxied request के साथ जाएं।

CORB क्या है और यह proxy services को कैसे impact करता है?

Cross-Origin Read Blocking (CORB) एक Chromium defense है जो कुछ sensitive cross-origin responses (HTML, JSON, XML) को cross-origin sub-resources के रूप में load होने पर renderer process में enter होने से रोकती है। Correctly-configured वेब proxies के लिए, CORB generally trigger नहीं होती क्योंकि URL rewriting सभी requests को same-origin बना देती है। हालाँकि, Service Worker पूरी तरह register होने से पहले के period में CORB issues cause कर सकती है, जब कुछ requests URL rewriting से बच निकलकर genuine cross-origin requests के रूप में भेजी जा सकती हैं। CORB को Spectre mitigation के रूप में introduce किया गया था और यह WHATWG Fetch specification में defined है।

क्या वेब proxies HTTP-only cookies access कर सकते हैं?

नहीं। HttpOnly cookies target server द्वारा set होती हैं और JavaScript द्वारा read नहीं की जा सकतीं — Service Worker में run होने वाले JavaScript सहित। हालाँकि, gateway user की तरफ से requests forward करते समय ये cookies receive करता है, क्योंकि browser उन्हें request headers में भेजता है। HttpOnly flag client-side JavaScript theft से बचाता है लेकिन proxy server को transit में cookie values देखने से नहीं रोकता। यह analogous है जैसे HttpOnly XSS से बचाता है लेकिन server-side interception से नहीं।

ब्राउज़र सिक्योरिटी perspective से वेब प्रॉक्सी use करना safe है?

यह threat model पर depend करता है। Browser के perspective से, वेब proxy से serve सभी content proxy के origin में run होती है, यानी एक proxied site के JavaScript में vulnerability दूसरी proxied site के session के data को potentially access कर सकती है (चूँकि वो same origin के cookie jar और storage share करते हैं)। Proxy का operator भी एक trusted party है जिसे transit में सभी traffic का access है। Restricted environments में non-sensitive content access करने के लिए, risk generally acceptable है। Sensitive services (banking, healthcare, government) के authenticated sessions के लिए, users को समझना चाहिए कि proxy operator के पास technically उस traffic observe करने की capability है, और केवल auditable no-log policies और strong operational security practices वाली proxy services use करनी चाहिए।

यह article early 2026 के अनुसार ProxyOrb के architecture को reflect करता है। Browser security mechanisms तेज़ी से evolve होते हैं; readers को most current information के लिए WHATWG Fetch Standard, W3C Content Security Policy specification, और Chromium के security design documents देखने की सलाह दी जाती है।