Securing TradingView Webhook Pipelines from Replay Attacks

Connecting TradingView alerts to a live brokerage account via custom webhooks is incredibly powerful, but it exposes your server to public internet traffic. An unsecured webhook endpoint is a massive financial vulnerability; if malicious actors discover your URL, they can trigger unauthorized trades on your account.

The Vulnerability of Obscurity

Relying on a secret, hard-to-guess URL string (e.g., webhook.php?secret=123xyz) is security through obscurity. URL parameters can be logged by intermediary servers, browser histories, or network sniffers.

Layered Security Architecture

A production-grade execution pipeline requires multiple layers of validation before a trade is ever passed to the execution API.

1. IP Whitelisting

TradingView publishes a strict list of IP addresses from which their alerts are sent. Your PHP endpoint must immediately drop any request that does not originate from these specific subnets.

$allowed_ips = ['52.89.214.238', '34.212.75.30', '54.218.53.128', '52.32.178.7'];
$request_ip = $_SERVER['REMOTE_ADDR'];

if (!in_array($request_ip, $allowed_ips)) {
    http_response_code(403);
    die('Unauthorized IP');
}

2. Payload Signatures

Even with IP whitelisting, IP spoofing remains a theoretical threat. To counter this, include a cryptographically secure hash in your TradingView alert message. Your backend should recalculate the hash based on the payload data and a shared secret key. If the hashes do not match, the payload has been tampered with or is entirely fraudulent.

3. Time-to-Live (TTL) Stamps

To prevent replay attacks—where a valid, intercepted payload is sent to your server repeatedly—include a Unix timestamp in your TradingView alert. If the PHP receiver processes an alert that is more than 30 seconds old, it should be discarded automatically.