Security at Parapho

Signed agreements are among the most sensitive documents a business holds. This page describes the technical and organizational measures we use to protect them. These measures also form the security annex to our Data Processing Addendum.

Identity and access

• Mandatory two-factor authentication. Every account must enroll an authenticator app (TOTP, RFC 6238) before reaching any data. Codes can be used only once, recovery codes are single-use and stored as hashes, and sensitive changes such as passwords, recovery codes and account deletion require a fresh code.
• Strong password storage. Passwords are hashed with scrypt (N=2¹⁵) and a unique salt, and must be at least 12 characters.
• Brute-force protection. Sign-in, two-factor and sensitive endpoints are rate limited. Accounts lock with exponential back-off after repeated failures. Responses don't reveal whether an account exists.
• Sessions. Random 256-bit session tokens are held in HTTP-only, Secure, SameSite cookies, and only their hashes are stored. The session ID rotates after two-factor verification. Sessions expire after 30 minutes idle or 12 hours at most, and you can review and revoke them yourself.
• Roles. Workspaces have owner, admin and member roles. Integration secrets, team management and the email log are restricted to admins.

Tenant isolation

Every customer table in our PostgreSQL database is protected by row-level security. The application connects as a non-privileged database role, and each request runs in a transaction scoped to a single workspace, so the database itself refuses to return or write another workspace's rows, even if application code has a bug. Unauthenticated signers can reach only the single recipient record matched by the hash of their link.

Encryption

• In transit: TLS 1.2+ everywhere, with HSTS preload. Connections to the database are TLS with full certificate verification.
• At rest: Amazon RDS storage encryption and Amazon S3 server-side encryption with AWS KMS customer-managed keys (AES-256). The S3 bucket blocks all public access, and objects are served only through authorized application routes.
• Application-level secrets: two-factor secrets and webhook signing secrets are additionally encrypted with AES-256-GCM. API keys and signing links are stored only as SHA-256 hashes.

Signing integrity

• Signing links are single-purpose, at least 256 bits, and rotate whenever a new link is issued, so older links stop working. Optional access codes add a second factor for signers.
• Signing order is enforced on the server. Signers can fill in only their own fields, and the server validates every value.
• Completed documents are flattened, given a certificate of completion with the full audit trail, digitally signed (PDF PKCS#7 signature, so readers such as Adobe Acrobat flag any later change), and fingerprinted with SHA-256. Anyone can confirm integrity at /verify without uploading the file.
• Signer attachments are type-checked, size-limited, stored privately, and fingerprinted on the certificate.
• Audit events record timestamp, IP address and user agent for every view, consent, signature, decline, reminder and void.

Application security

• A strict Content Security Policy that allows no third-party origins, plus frame-ancestors limited to origins each workspace registers for embedding.
• CSRF tokens tied to the session, plus origin checks on all state-changing requests.
• Uploads are checked for PDF structure and size; encrypted PDFs are rejected.
• Webhook URLs are validated against private network ranges to prevent server-side request forgery. Payloads are signed with HMAC-SHA256 and a timestamp.
• No third-party analytics, advertising, fonts or tracking scripts.
• Payments run through Stripe Checkout and the Stripe Billing Portal (PCI DSS Level 1). Card data never reaches Parapho. Stripe webhooks are signature-verified and processed idempotently.

Infrastructure and operations

• Hosted on AWS, with the database in private subnets, automated encrypted backups kept for 35 days, and point-in-time recovery.
• Least-privilege IAM roles. No long-lived access keys in the application. Secrets are held in AWS Secrets Manager.
• Dependencies are pinned and scanned for known vulnerabilities.
• Expired sessions are purged automatically, and security logs are kept for 12 months.

Responsible disclosure

If you believe you've found a security vulnerability, email [privacy@yourdomain] with the details. Please give us reasonable time to fix it before disclosing it publicly. Don't access other people's data, degrade the service, or run automated scanning beyond what you need to show the issue. We won't pursue legal action against good-faith research that follows these guidelines.