Security and Responsible Disclosure

How SemPost protects your data, how we handle incidents, and how to report a security vulnerability to us.

Version and validity

Version: 30 October 2026. This version applies from that date.
Last updated: 30 October 2026.
From: CS Digital Wonders (CS Digital Wonders LLC, a limited liability company organized under the laws of the State of Wyoming, USA; 30 N Gould St Ste N, Sheridan, WY 82801, USA). SemPost is a product of CS Digital Wonders.
How changes are announced: we record every change in the Changes section at the end of this page. If a change affects the commitments in our Data Processing Agreement, we announce it as that agreement describes.

Summary

This page describes the security measures that protect SemPost and your data, how we handle security incidents, and how you can report a vulnerability. It describes what is in place; it is not a certification. The technical and organisational measures that we commit to as your processor are listed in Annex II of our Data Processing Agreement.

To report a vulnerability, email [email protected]. For help with your account, email [email protected].

Where your data is hosted

Servers: our application, websites, database and cache run on servers of Contabo in the USA.
In front of the servers: Cloudflare's network. All requests to SemPost pass through Cloudflare before they reach our servers.
Files: media files and encrypted database backups are stored in Cloudflare R2. No storage region is set for our buckets, so Cloudflare chooses where the files are stored; this can be outside the EU and Turkey.
Service providers: our social media gateway and AI providers process data in their own locations. They are listed on the Sub-processors page.
Music: a separate server of ours, at Contabo in Germany, renders background music from note data. It receives no personal data.

Encryption

In transit. Connections to SemPost use HTTPS with TLS 1.2 or 1.3, both between your browser and Cloudflare and between Cloudflare and our servers (with a Cloudflare origin certificate). Browsers are told to use HTTPS only (HTTP Strict Transport Security) .

At rest. These items are encrypted or hashed in our database:

two-factor authentication secrets, store credentials and tokens, Shopify tokens, the keys for our social gateway, our providers' API keys and webhook secrets are encrypted field by field (Fernet), with key rotation;
passwords are stored as Argon2id hashes;
session, email-link and invitation tokens are stored only as SHA-256 hashes;
two-factor recovery codes are stored as HMAC values.

Database backups are encrypted with AES-256 on our server before they are uploaded. Cloudflare R2 encrypts the files it stores. Other data in the database is protected by the access controls described on this page.

Keeping workspaces apart

Every database table that holds workspace data uses PostgreSQL row-level security, enabled and forced. A request can only reach the rows of its own workspace.
The application's database role cannot read the tables that hold identities and platform settings.
An automated test checks that every route of the application requires the right authorisation.
The app (app.sempost.ai), the Shopify app (embed.sempost.ai) and our admin console run on separate addresses.
Inside a workspace there are four roles: viewer, editor, admin and owner. Everyone in a workspace can see the names, email addresses and two-factor status of the other members. Admins and owners can see the workspace's audit log, with shortened IP addresses .

Signing in

Email verification: you can sign in only after you have confirmed your email address.
Passwords: new passwords must meet our password rules and are checked against known data breaches with Have I Been Pwned. Only the first 5 characters of the password's SHA-1 hash leave our server.
Failed attempts: after 3 failed attempts a Cloudflare Turnstile check is added, and after 10 the account is locked for 15 minutes, doubling each time. Turnstile also protects the sign-up, password reset, verification and invitation forms.
Two-factor authentication: you can turn on an authenticator app (TOTP), with 10 recovery codes and protection against reusing a code. A workspace owner can require two-factor authentication for every member; this rule does not apply inside the Shopify admin, where Shopify's own sign-in protects access. If you use two-factor authentication, a new session inside Shopify also asks for your authenticator code.
Sessions: sessions are kept on our server and end after 7 days without activity, and after 30 days at most. You can see your sessions and end one or all of the others. Changing or resetting your password ends your other sessions.
Cookies: the session cookie is HttpOnly, Secure and SameSite=Lax and uses the __Host- prefix. We store only a SHA-256 hash of the session token. The Shopify app sets no cookies: every request carries Shopify's ID token.

Access by our team

Our staff work in a separate admin console. It is permanently behind Cloudflare Access, and our servers verify the Access login again.
Every sign-in to the admin console requires two-factor authentication. Sensitive actions require a fresh code, at most 15 minutes old.
Admin sessions end after 30 minutes without activity and after 12 hours at most.
Support staff can view, but only super admins can change sensitive settings such as payment and Shopify keys.
Admin actions are recorded in the audit log. Sensitive changes, and deletions made at a customer's request, are recorded with a written reason .
Our staff access customer data only when they need to, as described in section 6 of our Data Processing Agreement.

Protection of requests and servers

Forged requests: protection against cross-site request forgery with origin checks and a signed double-submit value.
Rate limits: limits on sign-in and account actions, invitations, billing, uploads, AI generation and other costly requests.
Server-side request forgery: when SemPost reads a product page, it only connects over HTTPS to public addresses.
Webhooks: every incoming webhook is checked for a valid signature. Stripe events older than 5 minutes are rejected; Shopify requests with an invalid signature are refused.
Network: our servers accept web traffic only from Cloudflare's network and check a secret header from Cloudflare. Requests for unknown host names are rejected. The database and the cache accept connections only from the server itself, and the cache requires a password.
Hardening: every service runs in a restricted systemd sandbox. Security headers limit framing, content type sniffing, referrer data and browser features.
Content Security Policy: our websites enforce a Content Security Policy. The app, the admin console and the Shopify app send a Content Security Policy with nonces in report-only mode: it records what it would block, without blocking it yet. Only your store's Shopify admin may frame the Shopify app .
Attack protection: Cloudflare's network filters traffic before it reaches our servers, including protection against denial-of-service attacks .

Social accounts: the access tokens of your social networks are held by our gateway Zernio, not by SemPost. We keep only a key limited to your workspace's profile, encrypted. When you disconnect an account, it is removed at Zernio.
Shopify: we ask only for read access: to products, inventory, discounts, markets, publications, languages and translations. We do not ask for access to your customers or orders. Shopify tokens are encrypted. If you connect your own Shopify app, its secret is encrypted and is only ever sent to your store's own myshopify.com address.
WooCommerce: we use read-only keys, stored encrypted, or the public Store API without keys.
Payments: you pay on pages of Link (Stripe). Card numbers, billing addresses and tax IDs never reach SemPost. Our Stripe key has only the permissions we need and is stored encrypted.

Files and media

Media files are kept in a private storage bucket. They can only be opened through signed links that expire: after 5 minutes in the app, 1 hour for AI providers and 24 hours for the backup publishing path.
Uploaded images (JPEG, PNG or WebP, up to 20 MB) are re-encoded, resized to at most 2048 pixels wide and stripped of their metadata, such as camera details and location. Videos (up to 200 MB and 3 minutes) are converted to at most 1080p in an isolated process. A workspace can upload up to 1 GB a day.
Uploaded files are scanned for malware before anything opens them; a file flagged as harmful is refused and never stored .
Images and videos generated with AI carry C2PA content credentials, which show that SemPost made them with AI.

Backups and recovery

The database is backed up to Cloudflare R2 with pgBackRest: a full backup every Sunday, a differential backup every day and the write-ahead log at least every 5 minutes.
Backups are encrypted before they leave our server.
We keep four full backups. This lets us restore the database to any point in time within about the last 4 weeks. Deleted data can remain in these backups until they expire; it is not used for anything else meanwhile.
An hourly job checks the backups and emails us if something is wrong.
Every month, an automatic test restores the latest backup to a separate copy and compares it with the live database .
Media files in R2 and the cache are not part of these backups. Keep your own copies of files you cannot afford to lose.

Logs and monitoring

Application logs are structured. Email addresses, tokens and passwords are masked, and only listed fields are written. For slow or failed requests we log only the path, the method and the status. Values in database queries are hidden in error messages.
Web server logs record the IP address, time, method, path without query string, status, referrer without query string and browser.
Database logs record statements that take longer than half a second; such an entry can contain the values used in the statement .
Retention: server logs are rotated, and old entries are deleted automatically .
Audit log: about 110 kinds of actions are recorded with time, IP address and browser. Entries are kept for 2 years; IP addresses and browser details are blanked after 1 year .
Monitoring: a health check and the hourly backup check email us when something fails. When an incident affects the service, we tell the affected workspaces by email .
The app contains no third-party analytics, tag manager or error-tracking software.

How we build SemPost

We use automated tests, including the authorisation test above.
Changes to billing and to the Shopify app get a security review before release.
The build pipeline scans for secrets that should not be in the code. The build server only runs the deployment job.
A register lists the database fields that hold personal data, and an automated test stops a new one from being added without a decision on how it is deleted .
Dependencies are scanned for known vulnerabilities, and the most sensitive areas (sign-in, permissions, billing and the Shopify app) have been reviewed against selected items of OWASP ASVS Level 2 .

Security incidents

When we notice a possible security incident, we:

contain it, for example by blocking access or rotating keys;
find out what happened, which data and which customers are affected, and how;
fix the cause and restore normal service;
inform the people who need to know, within the times below;
record what happened and what we changed.

The company's management is responsible for handling security incidents.

Notification times:

Customers whose content is affected (we act as their processor): without undue delay and within 48 hours after we become aware of the breach, by email to the workspace owners, as set out in section 11 of our Data Processing Agreement.
Supervisory authorities (where we are the controller, for example for account data): within 72 hours where the GDPR requires it, and within 72 hours to the Turkish Personal Data Protection Board.
Affected people: without undue delay when a breach is likely to result in a high risk to them.
Service status: by email to the affected workspaces while an incident affects the service .

Reporting a vulnerability

We welcome reports from security researchers and from anyone who finds a weakness in SemPost.

How to report

Email [email protected], in English or Turkish. Please include:

the address or feature that is affected;
the steps to reproduce the problem;
what an attacker could do with it;
any proof, such as screenshots or a short video;
how we can reach you, and whether you want to be named when we thank you.

We do not publish a PGP key for encrypted reports.

Scope

In scope:

www.sempost.ai and docs.sempost.ai;
app.sempost.ai, including its API;
embed.sempost.ai, the SemPost app inside Shopify;
admin.sempost.ai, only for problems you can find without signing in. Do not try to get past Cloudflare Access.

Out of scope:

services of other companies that we use, such as Cloudflare, Link (Stripe), Shopify, Zernio, the social networks and our AI providers. Please report problems there to the company concerned; tell us too if SemPost users are affected;
denial of service, load tests and spam;
social engineering or phishing of our staff or customers, and physical attacks;
problems that need a device or browser that is already compromised;
reports from automated scanners, or about missing best-practice settings, without a demonstrated security impact.

Rules for testing

Test only with accounts and workspaces you created yourself. A free trial is enough; it is available once per account. For the Shopify app, use a development store that you own.
Do not access, change or delete other people's data. If you reach data that is not yours, stop, do not keep or share it, and tell us.
Do not publish to social accounts that you do not own, and do not send messages to other people through SemPost.
Keep the number of requests low and respect our rate limits.
Do not use a vulnerability for anything other than showing it to us, and do not ask for payment in return for not disclosing it.
Give us reasonable time to fix the problem before you tell anyone else: until we have fixed it, or 90 days after your report, whichever is earlier. We are happy to agree a date with you.

Safe harbour

If you act in good faith and follow these rules, we will treat your research as authorised. We will not take legal action against you and will not ask any authority to act against you because of it. If someone else takes legal action against you for research that followed these rules, we will make it known that we authorised it. This does not authorise testing of other companies' services.

After you report

We confirm that we have received your report within 3 business days.
We tell you our first assessment within 10 business days.
We aim to fix critical problems within 7 days, high-severity problems within 30 days and medium-severity problems within 90 days of confirming them; low-severity problems are fixed in our regular work. We keep you updated until the problem is fixed and tell you when it is fixed.
If you agree, we thank you by name in a list on this page.
We do not run a paid bug bounty programme.

security.txt

We publish the contact details for security reports in machine-readable form at https://www.sempost.ai/.well-known/security.txt (RFC 9116). The file contains:

Contact: mailto:[email protected]
Expires: 2027-10-30T00:00:00.000Z
Preferred-Languages: en, tr
Canonical: https://www.sempost.ai/.well-known/security.txt
Policy: https://www.sempost.ai/legal/security

We renew the file before the date in "Expires". The file is published on www.sempost.ai only, and it is not signed with OpenPGP. The Turkish version of this page is at https://www.sempost.ai/tr/legal/security.

Certifications

SemPost does not hold security certifications, such as ISO/IEC 27001, and has no SOC 2 report. We have not yet commissioned an external penetration test. Certifications held by our providers do not apply to SemPost itself.

What you can do

Turn on two-factor authentication, and require it for your whole workspace.
Give each team member the lowest role that is enough, and remove people who leave.
Check your sessions now and then, and end the ones you do not recognise.
Look at the workspace's audit log if something seems wrong.
Keep your own copies of important files.
If you receive an email that claims to be from SemPost and looks suspicious, forward it to [email protected].

Changes

Date	Change
30 October 2026	First published