Sign-In
Webtzm has no password of its own. Sign-in is Google only, so there is no Webtzm password to be guessed, reused, leaked, or stored, and your Google account keeps whatever two-factor protection you have already set on it.
The authorization flow uses PKCE. Session cookies are HttpOnly and SameSite=Lax, and are marked Secure outside local development, so page scripts cannot read them and they are not sent on cross-site form posts.
Google Permissions
Webtzm asks for the narrowest Google permission that does the job, and asks for the second one only if you choose a feature that needs it.
- Core connection:
openid,email,profile, anddrive.file. Thedrive.filescope covers only files Webtzm creates for you and files you explicitly select. It is not access to your Drive. - Gmail sending:
gmail.send, requested separately and only if you turn on email delivery. It can send; it cannot read your mail. You can disconnect it without disconnecting the core connection.
There is no broad Drive scope, no full Sheets scope, and no mail-reading scope. A Sheet is reachable because Webtzm created it, or because you chose it through Google's own file picker — loaded from Google and run inside your own Google session, granting nothing wider than drive.file.
Encryption
- Traffic between your browser, Webtzm, and Google APIs is HTTPS. Responses carry HSTS,
X-Content-Type-Options: nosniff,X-Frame-Options: DENY, and a strict referrer policy. - Google OAuth refresh tokens are encrypted at rest with authenticated AES-GCM. The encryption key is held separately from the token records, and short-lived access tokens are not persisted by default.
- Application logs and stored error messages are written to exclude OAuth tokens, raw form answers, upload URLs, and Google response bodies.
Isolation And Access
Forms, submissions, Google connections, delivery records, and usage counters are isolated per workspace, and every request is checked against your membership and role in that workspace. One workspace cannot read the records of another.
Reading records back out of Webtzm is off unless you turn it on. A read key is created deliberately, is scoped to a single workspace, and can be revoked at any time.
Public endpoints are rate limited per workspace and globally, so one form under load or abuse cannot exhaust the service for everyone else.
Form Submissions
A form accepts submissions only from the domains you list, which is what stops someone copying your endpoint onto a page of their own. A submission from an unlisted origin is refused and named to the visitor as the blocked site; no submitted value is stored — only that site's address is kept, in a short list capped per form, so the form's owner can allow it with one click.
Submitted values are not kept indefinitely. On Free they are redacted once delivery succeeds or finally fails. On Pro you choose 7, 30, or 90 days. Delivery and usage records that contain no submitted values may be kept to document service operation and enforce limits. Retention and deletion in the privacy policy has the detail.
Spam protection is optional and is your decision per form. Where you enable it, Webtzm checks the submission before accepting it, and the user guide states plainly what those checks do and do not catch.
Payments
Card details never reach Webtzm. Checkout and billing management are hosted by Stripe, and no full card number is stored here. A plan change is applied only after the signed webhook from Stripe arrives and its signature is verified, so a forged callback cannot move a workspace onto a plan it did not buy.
Subprocessors
- Google Cloud — the destination for your selected output, and the identity provider for sign-in.
- Cloudflare — hosting, storage, and delivery of the service.
- Stripe — payment processing and subscription management.
Webtzm does not sell data, does not share it with advertisers or data brokers, and does not use Google user data to train general-purpose AI models.
Report A Vulnerability
Email support@webtzm.com with the words security report in the subject. Include what you found, how to reproduce it, and what you believe the impact is.
We aim to acknowledge a report within three business days and to tell you what we intend to do about it. Please give us a reasonable chance to fix an issue before publishing it, and please do not access, change, or delete data that is not yours while investigating. We will not pursue action against good-faith research that follows those two requests.
There is no paid bug bounty at this time, and there is no phone channel — email is the only support route.
What We Do Not Claim
Webtzm is a small service and states only what is true of it today. It holds no SOC 2, ISO 27001, or comparable third-party certification, and has not completed an external penetration test. There is no published uptime commitment. Current service status and any incident from the last 90 days are on the status page, and an outage or incident that affects delivery is also communicated by email to the workspace owners it affects.
No online service removes every risk. This page is updated when the way Webtzm handles your data materially changes.