Security patterns for public webhook endpoints, including dedicated secrets, schema validation, replay protection and least privilege.
In plain English
This guide assumes public inputs will eventually be probed. Keep secrets private, authenticate requests, validate data and make failure behavior conservative.
Assume the URL will be discovered
Public endpoints are scanned. Security should not depend on a path being obscure. Authenticate each event and reject anything that does not match the expected method, content type and schema.
Use a dedicated webhook secret
Never reuse a broker password or API key as the webhook token. A webhook secret should only authorize submission of a signal to your validation layer, not direct access to the broker account.
Replay protection
CREATE TABLE webhook_events (
event_id TEXT PRIMARY KEY,
received_at TEXT NOT NULL,
status TEXT NOT NULL
);Insert the event ID transactionally. If the primary key already exists, return a duplicate response and do not execute it again.
Validate before logging
Logs are another data store. Redact tokens and credentials. Keep enough information for diagnosis: event ID, source, symbol, action, status code and reason.
Network controls are extra layers
IP allowlists can reduce noise when the sender publishes stable addresses, but do not rely on them as your only authentication mechanism. Vendor infrastructure can change, and proxies can complicate source addresses.
Before you rely on this in production
- Secrets are rotated after exposure.
- Inputs are denied by default unless valid.
- Logs redact credentials.
- Permissions are limited to what the bot needs.