Proxy detection in JavaScript: browser and backend

A JavaScript proxy detection integration has two trust zones: collection in the browser and a result verified by your backend. Keep private lookup credentials on the server, associate the returned event with the protected action and handle delayed results explicitly. Browser-supplied risk fields are not an authorization decision.

JavaScript can also mean a Node.js backend making an IP lookup. Decide which model you are implementing before copying a snippet. They collect different evidence and fail in different ways.

Choose the integration shape

A server IP lookup sends a trusted client address to an external API. A browser-assisted product observes the current environment, then exposes a result through its supported API or webhook delivery. The latter can connect masking evidence to the device and application user.

ShieldLabs combines current device/network evidence, identity and account-level abuse detection. Fingerprint exposes an event-based SDK and server integration. Their actual result contracts and account settings matter more than a generic isProxy() helper.

A supported public-key snippet

The ShieldLabs collection pattern uses a site public key. The placeholder below must be replaced with the key issued for your own site. A public collection key and a private server credential have different purposes; keep the latter out of the bundle.

<script type="module">
  const mod = await import(
    'https://cdn.shieldlabs.ai/snippet.js?publicKey=YOUR_PUBLIC_KEY'
  );
  mod.checkAnonymous();
</script>

Install through the supported framework or SDK path for your application. Confirm that the script is allowed by the relevant content security policy and runs at the intended checkpoint. If navigation interrupts collection, an installed snippet alone does not establish that a usable result reached the backend.

Follow the current ShieldLabs documentation for result retrieval, user association and webhook setup. Do not invent an endpoint from the product name or assume that a client callback has already authenticated an account action.

Bind the observation to a real action

Create an application action reference when a signup, login or redemption begins. Record the account reference when known, the supported provider event reference, and the time. Retrieve or receive the result through the documented trusted channel, then associate it with that action.

Reject a result belonging to a different action or user. Handle a duplicate delivery idempotently so it updates the stored assessment without repeating a signup, charge or reward. A reusable queue message should carry a stable action identifier and a known processing state.

Do not let the browser select another customer’s stored event and call it its own. The exact verification mechanism depends on the product, but ownership checks belong on the server. The result must be relevant to the action being authorized.

Handle deadlines and delivery failures

The application needs states such as waiting, received, incomplete and unavailable. Define the deadline at the user-visible action, then decide how each missing state affects the flow. A failed check should not be silently stored as a low-risk verdict.

A delayed result may still be useful for investigation or a later protected action. That does not mean an application can retroactively stop an action it already allowed. Keep the timestamp and decision reason so reviewers can understand which evidence was available at the time.

If a webhook is used, follow the provider’s documented verification, retries and acknowledgement requirements. Avoid a long synchronous processing chain in the handler. Store the delivery reference and perform repeat-safe work before acknowledging according to that contract.

Compare browser and backend visibility

Use browser tools to check whether collection loaded, then inspect the corresponding server result in your permitted environment. A network response in DevTools is useful evidence of transport, but inspect the actual account and event association as well.

Start with public checkers to understand the evidence, then run an integrated evaluation. Separate request-path timing from background delivery using the latency and caching guide.

Keep response normalization narrow

Network classification, confidence, visitor risk and account-abuse findings are separate objects. Preserve the provider’s meaning for each. An application may combine them in a decision, but it should not transform “VPN detected” into “fraud confirmed” without the relevant evidence.

Our response field guide gives a normalization checklist. Use the ten-API comparison to shortlist interfaces, then verify current SDK and plan access in the linked review.

FAQ

Sources

• ShieldLabs documentation, supported collection and result delivery.
• Fingerprint server integration, trusted event handling.
• MDN Content Security Policy, controlling script loading.
• MDN X-Forwarded-For, client address trust for server lookups.