Security

Last updated: 13 June 2026

Content Engine holds two things worth protecting: the content you create, and the credentials you connect so it can publish for you. This page describes what the product actually does about both.

Everything on this page is a control that exists in the running product, not an aspiration. Where we do not yet have something a security reviewer would ask for, it is listed under “What we do not claim” rather than omitted.

Your account

• Passwords are stored only as bcrypt hashes. We cannot read your password, and neither can anyone with access to the database.
• Sessions are held in httpOnly cookies, so scripts running on the page cannot read your session token even if a cross-site scripting flaw were introduced.
• Password reset links are single use. Only a SHA-256 hash of the link’s token is stored, requesting a new link invalidates the previous one, and completing a reset signs out every other session — because the usual reason to reset a password is that someone else has it.
• Repeated failed sign-ins are throttled per account and per address, and the throttle counters are scoped so that traffic to one route cannot lock you out of another.

The credentials you connect

Connecting WordPress or Shopify means handing us a credential for a site you own. We treat it accordingly.

• Site credentials — WordPress application passwords and Shopify access tokens — are encrypted with AES-256-GCM before they are written to the database, and decrypted only at the moment a publish or a connection test needs them.
• API keys you store for AI providers are encrypted the same way.
• Credentials are never returned by our API, never written to logs, and never included in an error message. Error messages name which field is missing, never its value.

Separation between customers

Content Engine is multi-tenant, so the most important property is that one organisation can never read or change another’s data. Every database read and write is scoped to the caller’s organisation in the service layer, and a central guard rejects any request whose parameters name a workspace outside it. A request for something belonging to another customer is answered exactly like a request for something that does not exist, so it cannot even be used to discover that the other thing is there.

Payments

Card details never reach our servers. Checkout is hosted by Stripe and we hold no card data at all — not even a publishable key in the browser. Payment webhooks are rejected unless their signature verifies, so nobody can grant themselves a subscription by posting to our endpoint.

The application itself

• HTTPS only, with HSTS (including subdomains, preloaded), so browsers refuse to connect over plain HTTP.
• A Content Security Policy that blocks plugins and framing, restricts where scripts and connections may come from, and pins form submissions to this origin.
• Requests are rate limited per user, per route, on roughly 330 endpoints, and request bodies are size-capped before they are parsed.
• Any HTML that comes from outside — an imported article, for example — is sanitised before it is rendered, using an allow-list rather than a list of things to remove.

Where your data lives

Content and account data are stored in a managed PostgreSQL database. Generated images are held in private object storage and served through the application, which confines every request to your own workspace’s files; the storage bucket itself is not publicly readable. Data is not sold, and it is not used to train models for other customers.

What we do not claim

So that this page is useful rather than reassuring, here is what we do not have today:

• No SOC 2, ISO 27001 or comparable third-party audit.
• No third-party penetration test report, and no bug-bounty programme.
• No contractual uptime guarantee. If you need any of these before you can adopt the product, tell us and we will be straight with you about the timeline.

Reporting a vulnerability

If you believe you have found a security problem, please write to [email protected] with enough detail to reproduce it. We would rather hear about it early and imperfectly than late. Please do not run automated scans or load tests against production, and please do not access or modify data belonging to anyone other than yourself — there is nothing to be learned from that which a description would not tell us.

Who operates the service

StoresWiki LLC, Lewes, Delaware, USA.