如何在C/C++ WebAssembly中直接访问当前URL以实现域名防盗用？

Great question—restricting WASM modules to your own domains is a common pain point, since passing plaintext domain parameters from JS is trivial to tamper with. Let's walk through your options, starting with the core constraint:

First off, WebAssembly can't directly access the browser's window object or current URL on its own. WASM runs in a sandboxed environment with no direct access to browser APIs—all interactions with the DOM or browser state have to go through JavaScript bindings. But that doesn't mean you can't implement secure domain validation; you just need to make the JS-to-WASM handoff harder to tamper with.

Here are practical, harder-to-circumvent approaches:

1. Signed Domain Tokens (HMAC Validation) #

Instead of passing the raw domain to WASM, have your JavaScript compute a signed token using a secret key shared between your JS and WASM code. Here's how it works:

• In your JS:
  1. Fetch the current window's origin (e.g., window.location.origin).
  2. Generate an HMAC signature of the origin using a pre-shared secret key (obfuscate this key in your JS to slow down extraction).
  3. Pass both the origin and the signature to your WASM module.
• In your C++ WASM code:
  1. Receive the origin and signature.
  2. Recompute the HMAC of the origin using the same secret key (embedded in your WASM code—note: this can still be reverse-engineered, but raises the bar significantly).
  3. If the computed signature doesn't match the one passed in, terminate execution of your WASM logic.

Example snippet for C++ (using OpenSSL compiled to WASM):

#include <string>
#include <openssl/hmac.h>

bool validate_domain(const std::string& origin, const std::string& received_signature) {
    const unsigned char secret[] = "your-pre-shared-strong-secret";
    unsigned char computed_signature[EVP_MAX_MD_SIZE];
    unsigned int sig_len;

    HMAC(EVP_sha256(), secret, sizeof(secret)-1, 
         reinterpret_cast<const unsigned char*>(origin.c_str()), origin.length(),
         computed_signature, &sig_len);

    // Convert computed signature to hex string for comparison
    std::string computed_hex;
    for (unsigned int i = 0; i < sig_len; i++) {
        char buf[3];
        sprintf(buf, "%02x", computed_signature[i]);
        computed_hex += buf;
    }

    return computed_hex == received_signature;
}

2. Server-Side Authorization Tokens #

For even stronger protection, add a server-side check:

• When your WASM module initializes, have your JS send a request to your backend server (the browser automatically includes the Origin header).
• Your server validates that the Origin header matches your allowed domains, then returns a short-lived, signed authorization token.
• Pass this token to your WASM module, which validates the token using a public key (embedded in WASM) corresponding to the server's private signing key.

This approach makes it nearly impossible for unauthorized domains to get a valid token, since your server controls issuance.

3. Embedded Domain Hashes (Basic Layer) #

If you want a simpler (but less secure) first line of defense, embed SHA-256 hashes of your allowed domains in your WASM code. Your JS computes the hash of the current origin and passes it to WASM, which checks if it exists in the allowed hash list.

Note: This is easier to bypass than HMAC or server-side tokens (attackers could reverse-engineer the allowed hashes), but it's better than plaintext domain checks.

Important Caveats #

No solution is 100% foolproof—determined attackers can reverse-engineer WASM code to extract secrets or bypass checks. But these methods raise the bar significantly, making casual theft or reuse impractical for most scenarios.

内容的提问来源于stack exchange，提问作者TonyB