Security is architecture, not a checkbox.

This page describes how Askery is built and operated to protect your data. It is written to be accurate to the platform as it works today - a Next.js application on managed Postgres with Supabase Auth and row-level security - and to be clear about what is shipping versus what is on the roadmap. It is provided for transparency and is not a contractual warranty; binding commitments, where they exist, live in your agreement, our Data Processing Addendum and Privacy Policy.

Tenant isolation

Every form, response and setting belongs to a workspace. Access is enforced by Postgres row-level security (RLS) at the database layer - not only by application code. A user can only ever read or write data in workspaces they are a member of, and that membership check is evaluated by the database on every query. Even if an application bug constructed an unscoped query, RLS policies still deny rows the caller is not entitled to. Authorization is therefore a property of the data model, not a code path that can be forgotten.

The single audited write path

Public form submissions never get a direct anonymous INSERT grant. Instead, every public response is written through one security-definer database function that validates the submission against the published form and records it. There is exactly one path into response storage, it is audited, and the server re-validates input against the canonical form schema before anything is written - the client is never trusted. Submissions are owner-only at rest: the public can write a response to a published form but can never read responses back.

Authentication and access model

Authentication is handled by Supabase Auth. Sessions are bound to the authenticated user, and workspace membership and roles determine what each user can see and do, enforced by the RLS policies above. Access follows least privilege: the privileged service-role key is confined to the server, is never prefixed for client exposure, and never reaches the browser. Secrets are server-only environment values, not shipped in client bundles.

Encryption and transport

All traffic to Askery is served over TLS (HTTPS), including public forms. Data is encrypted in transit. Our managed Postgres infrastructure provides encryption of data at rest at the storage layer. Credentials are never transmitted or stored in clear text - see password handling below.

Password-protected forms

Form passwords and user passwords are never stored in plaintext or reversibly. They are stored only as salted bcrypt hashes, in isolated tables that no API surface can read back. Password verification happens server-side; a wrong attempt reveals nothing about the stored secret. A protected form will not render its questions until the password check passes.

Anti-spam and abuse protection

Public forms ship with a built-in honeypot field that ordinary respondents never see and bots tend to fill. The check runs on the client AND inside the security-definer write RPC, so a script POSTing directly to our endpoint is dropped just as silently as one that uses the rendered HTML.

Every public write goes through a per-IP, per-form rate limit enforced at the database (30 submissions per minute per IP/form bucket). IPs are stored only as opaque SHA-256 buckets, never in plaintext. For forms that face active abuse, owners can enable a Cloudflare Turnstile challenge from the form's Share tab - privacy-friendly, no cognitive challenge for most users, and a strong gate for targeted automation. Combined with the single audited write path, this keeps spam off your responses without making real respondents jump through hoops.

Signed webhooks and integrations

Outbound webhooks are designed to be verifiable: deliveries can be signed so the receiving system can confirm a payload genuinely came from Askery and was not tampered with in transit. Customers are responsible for validating signatures on their endpoint and for the security of any third-party destination they configure; integrations a customer adds operate under that customer's control.

Versioning and audit trail

Form definitions are versioned so that changes are traceable and responses always reference stable question and option identifiers rather than mutable labels - answers stay correctly attributed even after a form is edited. The audited write path and structured event logging give us a record of how responses entered the system. Configurable retention and richer admin-facing audit logs are designed into the data model and are on the roadmap below.

Backups and resilience

The managed Postgres infrastructure performs routine automated backups on a defined rotation. Backups exist to support recovery and continuity; they are not used for any secondary purpose, and data deleted from production ages out of backups on the rotation schedule rather than persisting indefinitely.

Data ownership, export and deletion

There is one canonical form schema and no lock-in. You can export your responses (including CSV) at any time and leave with all of your data, cleanly. On account closure or a verified deletion request, associated personal data is deleted or irreversibly anonymized within a commercially reasonable period (target: within 30 days), subject to legal retention requirements and the backup rotation described above. For customer-collected respondent data, the customer is the controller and controls export and deletion - see the DPA.

Sub-processors and hosting transparency

Askery relies on a small, vetted set of sub-processors - cloud hosting and managed Postgres, transactional email, payment processing, privacy-respecting analytics, and support tooling. Each is bound by written confidentiality and security obligations. The current itemized list, with purpose and hosting region, is maintained for customers, and notice of additions or replacements is available as described in the DPA. Regional data residency is on the roadmap; today the primary data store sits in Singapore (ap-southeast-1).

Compliance posture

Askery is built to be compliance-aware from the first migration: multi-tenant isolation, an audited write path, and data-subject export and deletion are architectural, not bolt-ons. We do not claim certifications we do not hold - Askery is not currently SOC 2 or ISO 27001 certified. We are designing toward a formal SOC 2 program; GDPR and CCPA/CPRA obligations are addressed today through our Privacy Policy and DPA, including Standard Contractual Clauses for international transfers.

Roadmap

Workspace audit logs ship today on Pro and above; configurable retention windows, regional data residency, SSO/SAML and a formal SOC 2 program are designed into the data model and roll out without re-architecture. Sub-processor list is published at /legal/subprocessors; progress on certifications goes here as the program matures.

Responsible disclosure

If you believe you have found a security vulnerability, please report it privately to support@askery.app with enough detail to reproduce it. Please do not access or modify data that is not yours, avoid privacy violations and service degradation, and give us a reasonable opportunity to remediate before any public disclosure. We acknowledge legitimate reports within one business day, work in good faith on a fix, and will not pursue good-faith researchers who follow this policy.