Formstack Integration Security Review

A Formstack Personal Access Token is tied to the user who created it and follows that user’s account permissions rather than a scope defined on the token itself. We test what every token’s owner can do, and whether that still matches what the integration needs.

Why Formstack findings sit in your tokens and webhooks, not the form builder

Formstack’s V2025 API authenticates every call with a Personal Access Token generated from the Formstack Administration console and sent as an Authorization Bearer header, optionally with an expiry set at creation. The token is tied to the user who generated it and inherits that user’s in-app permissions rather than carrying its own scope, so we test what every token’s owner can actually do inside the account and whether an integration is holding a token more privileged than it needs.

A Formstack webhook pushes submission data to an external URL in real time and supports a configurable payload format, HMAC signing and failure notifications. We test whether HMAC signing is actually turned on and verified by the receiving endpoint, not left available but unused, and how the endpoint behaves when a webhook is retried after a failure.

A parent Formstack account can manage subaccounts, and Formstack’s own documentation notes that a subaccount record includes details such as SMTP credentials. Separately, Portals give a branded hub for a curated set of forms with their own portal users, managed independently of the main account’s users. We test whether a subaccount’s credentials and a portal’s user list stay confined to that subaccount or portal, or whether either can be reached from outside it.