Security Overview

Prynt reads business data from your databases to produce documents, so security is part of the design, not an option. This page summarizes how the platform protects your data, your accounts and your databases. The details of each area are in the linked pages.

Principles#

• Your databases stay private. The Gateway connects out from your network; no inbound port is opened.
• Read-only, always. Queries run in read-only transactions after a check that rejects anything but reads. The API accepts template codes and parameters, never SQL.
• Credentials are write-only. Database passwords are never shown again; with a gateway they are encrypted for it in your browser and Prynt cannot read them.
• Least privilege. Roles limit what each person can do, scopes limit what each API key can do.
• Everything that matters is recorded in an append-only audit log.

Hosting and encryption in transit#

• Prynt runs as a managed service hosted in the European Union.
• The application, the API and this site are served over HTTPS only, with HTTP Strict Transport Security (one year, including subdomains).
• Direct database connections must use TLS (see direct connections); gateways connect over HTTPS and secure WebSockets.

Tenant isolation#

Customers are organizations; an organization has one or more workspaces, each with its own templates, data sources, API keys, webhooks and runs. Isolation is enforced twice:

• by the application, which scopes every query to the workspace of the request;
• by the database, with PostgreSQL Row-Level Security on the tables of workspace content (templates and versions, datasets, assets, shared queries, data sources and connections, API keys, webhooks, runs and render jobs). A connection without a tenant context sees no rows at all.

An API key belongs to one workspace and can never read another workspace's templates or data sources.

Roles and permissions#

Every member has a role in the organization. Roles are cumulative: each one has all the permissions of the roles below it. Nobody can grant, change or act on a role above their own, and ownership is transferred, never granted.

viewerrole

Sees templates and versions, previews them and sees only their own runs. templates.read

designerrole

Changes the layout of templates with the field catalog: texts, logos, colors, fonts, fields and simple conditions; manages assets. Never sees SQL, data sources or connections and cannot publish: requests publication from an approver. + templates.write, assets.manage

developerrole

Owns data and integration: data sources and gateways, SQL, datasets, shared queries, publishing, API keys, webhooks, all runs, audit log and usage. + datasources.read, datasources.manage, sql.execute, datasets.manage, shared_queries.manage, templates.publish, apikeys.manage, webhooks.manage, runs.read, audit.read, usage.read

adminrole

Also manages members and invitations, workspaces, their settings and environments. + org.members.manage, workspace.manage

ownerrole

Exactly one per organization: also its settings, deletion and ownership transfer. + org.manage

data_partnerrole

Your software house, outside the ranking: data and connections of the workspaces you grant it, nothing else. Can ask for publication, never publish. templates.read, templates.write, datasources.read, datasources.manage, sql.execute, datasets.manage, shared_queries.manage

• A workspace can give a developer, designer or viewer a different role in that workspace only. Owners and admins keep their role everywhere.
• The matrix is visible in the application under Roles; commands you are not allowed to use are hidden or disabled, and the API refuses them anyway.
• Suspended members keep their role and history but cannot access anything until reactivated.
• The API only renders published versions. A designer's changes reach production only when a member who can publish approves their publish request (a workspace can limit approvers to some roles); requests and decisions are in the audit log. See Publish requests.

Your software house (data partner)#

Invite the software house that knows your ERP from Organization settings → Members → Invite your software house: it gets the data_partner role and prepares the data of your templates once (connections, read-only queries, field catalog, mapping, document lists), so your people only change the graphics.

• It opens only the workspaces you choose; the others do not exist for it. You give or take access in each workspace's settings.
• It never sees your members, billing, license, settings, API keys or audit log, and it cannot publish: it can only ask for publication, and you approve. The role is given only by an invitation, never by a role change.
• Organization settings → Software house lists everything its members did in your organization, data accesses included (data source, rows, outcome; never the values), also after you remove them.
• A software house can have its own Prynt organization, enabled as a partner by Prynt: it sees the list of its customers (names only) and keeps catalogs per ERP that it copies into each customer's templates. Nothing of a customer ever goes to the partner or to another customer.

Are you a software house? Read Prynt for software houses; for companies, see Prynt for companies.

Accounts, 2FA and sessions#

Passwords

• At least 10 characters, no composition rules; common and breached passwords, passwords equal to your email and repetitive or sequential ones are refused, and so are your last 5 passwords.
• Passwords are stored as salted PBKDF2-HMAC-SHA512 hashes (100,000 iterations).
• Your email address must be verified before the first sign-in. After 10 failed sign-ins the account is locked for 15 minutes.

Two-factor authentication

• Turn on two-factor authentication in your account's security settings with any authenticator app (TOTP, 6 digits). You get 10 single-use recovery codes, shown once.
• You can let a device be remembered for 30 days, and forget remembered devices at any time.
• The owner and admins can require two-factor authentication for every member of the organization (Data & privacy). API keys are not affected.

Sessions

• A session ends after 12 hours of inactivity and in any case after 24 hours; with Keep me signed in (on by default at sign-in) it lasts up to 30 days (7 days of inactivity). The session cookie is HttpOnly, Secure and SameSite=Lax.
• Your account lists your open sessions: close one, or all but the current one. Changing your password signs out your other sessions; resetting it signs out all of them.

Sign-in uses email and password (with two-factor authentication when enabled); single sign-on is not available yet.

API keys#

• Keys are shown once; Prynt stores only their SHA-256 and compares in constant time. The visible prefix (prynt_live_… or prynt_test_…) identifies a key in lists, logs and secret scanners.
• Scopes (render, templates.read, datasets.execute…), an optional expiration and immediate revocation. Test keys can never use a production environment.
• Each key is rate limited (600 requests per minute by default).

Details in Authentication.

Access to your databases#

• Every query is checked before it runs (a single statement starting with SELECT, WITH, VALUES or TABLE; no INSERT, UPDATE, DELETE, MERGE, TRUNCATE, INTO or FOR UPDATE), then runs in a read-only transaction that is always rolled back.
• Queries have timeouts and row and size limits; parameters are always bound, never concatenated into SQL.
• Gateways repeat the read-only check and apply their own limits, and only execute requests signed by Prynt.
• Direct connections are checked against private and reserved networks at every connection, with TLS required.
• Prynt warns when a database user can write or has administrative privileges, and gives you the script for a read-only user.
• Designers never receive SQL. The lists of real documents they pick in the preview run a stored lookup query on the server, read-only and audited; only members with sql.execute can write it.

See Data sources, Gateway and Direct connections.

Secrets at rest#

• Database passwords of direct connections, webhook signing secrets and two-factor keys are encrypted with envelope encryption: AES-256-GCM with a data key per organization, wrapped by a master key (or by a key in Azure Key Vault, which never leaves the vault). Each value is bound to its organization, record and purpose.
• Credentials for a gateway are sealed in your browser with the gateway's public key (ECDH P-256, HKDF-SHA256, AES-256-GCM): Prynt stores an envelope it cannot open.
• Sessions, API keys, recovery codes and registration tokens are stored only as hashes.

Audit log#

The organization's Audit log (permission audit.read: developers, admins and owner) records who did what and when: members, roles and invitations, workspaces and environments, templates (published, rolled back…), assets, shared queries, data sources, connections and gateways, SQL executed in the Designer, API keys, webhooks, security settings, exports and deletions. Each entry carries the actor (user or API key), the resource, the IP address and the correlation ID. Entries are append-only: the database refuses to change or delete them.

Privacy and GDPR tools#

• Your data: Account → Privacy downloads a copy of your personal data (profile, memberships, sessions, two-factor status, your activity) and deletes your account. Content you created stays with its workspaces without your name; audit entries are kept but anonymized.
• Organization data: the owner can export everything (members, workspaces, templates with every version, assets, shared queries, data source settings, runs, audit log, usage) as a ZIP. Passwords, keys and secrets are never included; the download link is valid for 7 days.
• Deleting an organization: access ends immediately; everything is erased for good after a 30-day grace period, during which the owner can restore it.
• Generated documents are not an archive: stored documents expire (24 hours by default), and parameter values marked as confidential are kept out of the run log.

Reporting a vulnerability#

If you believe you have found a security vulnerability in Prynt, please contact us privately, with the steps to reproduce it, and give us reasonable time to fix it before disclosing it. Do not access data that is not yours and do not degrade the service while testing.