Webhook Security: Signing, Secrets, and Replay Protection

A webhook endpoint that places real orders is an unauthenticated URL that spends money. Worth treating accordingly.

What TradingView provides, precisely

Nothing, and it is better to know that plainly than to assume otherwise.

Each alert fires an independent POST. There is no session, no authentication header from TradingView, and no built-in signing. Compare that with webhook providers that sign payloads with a shared secret so the receiver can verify both origin and integrity. TradingView does not offer this.

TradingView does publish the IP addresses it sends from, for allowlisting. And its own documentation carries a warning worth repeating: do not include sensitive information such as login credentials or passwords in the webhook body.

Why a shared secret is not signing

The common pattern is a secret field in the JSON body that the receiver checks before acting. It is the right thing to do and it is weaker than signing in four specific ways.

It is a bearer token sent in full on every request. Signing sends a derived value; a shared secret sends the credential itself, every time.

It proves knowledge, not freshness. A captured request can be replayed exactly and will validate, because nothing in it expires.

It provides no integrity guarantee. Signing covers the whole body, so tampering invalidates it. A secret only proves the secret was known.

It lives in your alert configuration. Anyone with access to your TradingView account can read it in plain text.

None of that makes the pattern useless. It makes it one layer rather than the answer.

The layers

HTTPS, without exception. The secret travels in the body. Over plain HTTP it is readable by anything on the path.

An unguessable URL. A long random path segment means an attacker needs the URL before the secret matters. Weak on its own — URLs leak through logs, proxies, and screenshots — and free.

A long random secret, compared in constant time. Not a word. Not reused anywhere else. Constant-time comparison avoids leaking information through response timing.

Validate before anything else. Check the secret before parsing, routing, or logging the body. Doing this cheaply matters under load, since the validation sits directly in the request path and every rejected request still consumes it. An endpoint that does work before authenticating is an endpoint an attacker can make do work.

An idempotency key. Because replay cannot be prevented cryptographically here, catch it structurally: a unique identifier per signal, with the receiver rejecting anything it has already processed. This is the single most effective control available and it is covered properly as its own subject.

Timestamp rejection. Include a timestamp in the payload and reject requests outside a narrow window. Bounded rather than airtight — an attacker replaying within the window still succeeds — but it converts an indefinite replay opportunity into a brief one.

IP allowlisting, as a secondary control. TradingView publishes its sending addresses. Restricting inbound traffic to those addresses is genuine defence in depth. Treat it as secondary because the ranges change, and an allowlist that silently goes stale drops legitimate alerts. Monitor for rejected requests from unexpected sources rather than assuming the list is current.

Bound what the payload can do. The most important control and the least discussed. An endpoint that submits whatever quantity it is handed is one malformed alert from a very large order. Compute size from your own capital rules and treat the incoming value as a suggestion. Cap order size, cap daily order count, and reject symbols outside an expected set.

Where the endpoint runs

Deployment topology changes what controls are available to you.

On a shared multi-tenant service, you get whatever security model the vendor implemented, and your broker credentials sit in their database. On a self-hosted deployment the endpoint and its network policy are both yours, which makes IP allowlisting, rate limiting, and request logging things you can actually configure — and keeps broker credentials in your own environment rather than a vendor's.

The honest counterpart is that it hands you the work. An endpoint you own is an endpoint you have to patch, monitor, and keep available. That favours operators comfortable running infrastructure.

Detection matters as much as prevention

Assume something will eventually get through, and make sure you would notice.

Log every request before parsing, including rejected ones — the raw body is the only evidence of what actually arrived, and TradingView keeps no sending-side record you can inspect. Alert on rejected secrets, on orders outside expected hours, and on order rates above normal. Reconcile positions against the broker independently rather than trusting your own state.

And know how to revoke. Broker credentials can be rotated, grants revoked, and the endpoint taken offline. Knowing the sequence before an incident is worth more than any single control.

The honest limits

You cannot verify a TradingView webhook cryptographically. Every mitigation here works around that rather than solving it.

A shared secret in a payload is a password in a message body. Layers reduce the probability of a successful attack and do not eliminate it.

IP allowlisting depends on a published list that changes. Timestamp windows narrow replay without closing it.

Which is why the last line of defence is not security at all. If a hostile order could be catastrophic, the exposure was created by position size, not by the webhook. The divide-by-20 rule — capital divided by twenty as the ceiling per position — bounds what any single order can cost regardless of who sent it.

Frequently asked questions

Does TradingView sign webhook requests? No. There is no HMAC signature and no authentication header. A shared secret in the payload is the common substitute.

How do I secure a TradingView webhook? Layer it: HTTPS, an unguessable URL, a long random secret validated first in constant time, an idempotency key, timestamp rejection, IP allowlisting as a secondary control, and server-side limits on what any payload can do.

Can I whitelist TradingView IP addresses? Yes, TradingView publishes them. Treat it as defence in depth, because the ranges change and a stale list drops legitimate alerts.

Is a shared secret enough? It is one layer. It proves the sender knew the secret but not that the request is fresh or unmodified.

Should I put broker credentials in the payload? No. TradingView's own documentation warns against including credentials or passwords in a webhook body.

Disclaimer: This article is educational content about software engineering and trading automation. It is not investment advice, financial advice, tax advice, legal advice, or a recommendation to buy or sell any security. Any instruments named are used solely to illustrate mechanics. Options trading involves substantial risk of loss and is not suitable for all investors. Please read Characteristics and Risks of Standardized Options before trading options. Automated trading systems carry additional risks including software defects, missed or duplicated signals, network and connectivity failures, third-party service changes and outages, and unintended order behaviour that may prevent orders from being placed, modified, or cancelled. Past performance does not indicate future results, and no configuration, alert setup, position-sizing rule, or risk setting can guarantee a profit or prevent a loss.

StaxInvesting LLC sells self-hosted trading software. It is not a broker-dealer, investment adviser, or financial institution, and it does not manage accounts, hold member funds, place trades on behalf of members, or access member brokerage accounts. Members run the software in their own cloud environment, connect their own brokerage accounts under their own credentials, and are solely responsible for their configuration, their credential security, their compliance with third-party terms of service, and every trade executed in their account. Third-party platform details described here reflect publicly available documentation as of publication and are subject to change without notice; always verify against current official documentation. Consult a qualified financial adviser and tax professional regarding your individual circumstances.