Webhook form security checklist
A security checklist for webhook-backed forms that send requests into n8n, Make, Zapier, Power Automate, or custom APIs.
A webhook form security checklist should verify HTTPS endpoints, input validation, tenant scoping, bot protection, idempotency, retry behavior, secret handling, least-privilege workflow credentials, and logging that avoids leaking sensitive data.
Verify these before publishing.
Require HTTPS
Do not send form submissions or approval callbacks to plaintext endpoints.
Validate before acting
The workflow should validate required fields and source-system IDs before mutation.
Scope tenant context
Customer or organization IDs from the request must be checked against the expected workspace or tenant.
Protect public forms
Use bot protection, rate limiting, and validation appropriate to the form's exposure.
Use least-privilege credentials
n8n credentials should only perform the actions required by the workflow.
Keep secrets out of payloads
Do not put API keys, bearer tokens, or private credentials in visible form fields or webhook bodies.
Log safely
Capture delivery status and request IDs without exposing sensitive submission data unnecessarily.
- A public form accepts arbitrary organization IDs without revalidation.
- The workflow trusts hidden fields from the browser as authoritative.
- A webhook credential can mutate more systems than the form requires.
- Failure logs contain secrets or full sensitive payloads.
- Retries can create duplicate tickets, users, or approvals.
Are webhook forms safe?
Webhook forms can be safe when validation, tenant scoping, bot protection, idempotency, and credential boundaries are handled explicitly.
Should hidden fields be trusted?
No. Hidden browser fields are user-controllable. Treat them as hints and revalidate important context server-side or in the receiving workflow.