Security

What we do to keep your site yours

You trust us with your site, your customers’ contacts and sometimes their orders. Here is where that data lives, who can reach it and what happens when something breaks — including what we cannot do yet.

Privacy policy Contact

Where your data lives

No servers under a desk. We run on infrastructure operated by companies whose main business it is.

Sites and files: Cloudflare, EU

Published pages, photos and uploads sit in Cloudflare storage in the EU. Your site is served from their network, not from one machine that can go down.

Database: Neon, Frankfurt

Page content, orders, bookings and newsletter subscribers live in a database in Frankfurt, Germany. European data does not leave Europe.

Connection: HTTPS and a free certificate

Everything is encrypted. The certificate for your domain is issued and renewed by Cloudflare; the lowest version of encryption allowed is TLS 1.2. A domain goes live only once its certificate is valid — otherwise visitors would see a warning.

Accounts and sign-in

We do not write sign-in ourselves. It runs on a library thousands of projects use and which is patched faster than we could manage.

  • Your password is never stored. The database holds only a scrypt fingerprint of it, from which the password cannot be recovered — not even by us.
  • The shortest password allowed is eight characters.
  • Registration does not go through without a verified email. Without that, anyone could open an account under someone else’s address.
  • A password reset link is valid for one hour and works only once. **Resetting a password also signs out every other device** — anyone who got into the account is thereby out.
  • Password guessing has a ceiling: after twenty attempts from one address, nothing gets through for fifteen minutes.
  • **Breached passwords are refused.** When you register or change a password we check whether it has shown up in a data breach — and if it has, we ask for another. The password itself is never sent anywhere, only the first five characters of its fingerprint.
  • Settings shows the **devices where your account is open**, and one button signs the others out.
  • When the password changes or two-factor authentication is turned off, **you get an email about it**. It is the fastest way to learn about someone else getting in before they do damage.
  • Settings holds the **account activity log** — sign-ins, security changes, publishing and restores for the past six months. It is there for one question: was that me?
  • A sign-in lasts seven days. Its cookie is set so that no script on the page can read it, and it travels only over an encrypted connection.
  • **Two-factor sign-in** can be switched on in Settings. A six-digit code from an app on your phone is then added to your password — anyone who gets the password still cannot get in without the phone. For a lost phone you get one-time backup codes.
  • An account can also be created **with Google**. You then have no password at all, so none can be guessed or pulled from somebody else’s leak. On that route we do not ask for our code — Google handles the second factor there, so turn it on with them too.

One site’s data never mixes with another’s

  1. Whose data loads is decided from the sign-in alone, never from anything the request carries. Substituting someone else’s account number does not return their data — it returns an error.
  2. Switching to a site that does not belong to the account is refused. Deliberately not a silent switch to another site: a silent swap is worse than an error, because nobody notices it.
  3. That we never forget it somewhere is not a matter of attention but of an automatic check across the whole source code. It walks every database query and verifies it asks only about one site’s data. Work around it and the tests fail, so the change never ships.

When we first ran that check in August 2026, it found sixty-eight places where the filter was missing. By the next day there were none — and since then a machine watches it, not a good memory.

We cannot get into your account by ourselves

This is the most common worry and the answer is simple: the customer grants access, we cannot take it.

  • Without your permission the admin will not let us into your account — the request is refused, not served.
  • Permission always has an end. Seven days by default; longer is your choice and you can revoke it any time.
  • You can close off individual parts of the account — orders or subscribers, say — and open only the part where the thing you wrote about is stuck.
  • Every visit is recorded: who, when and where they looked. You see that list in your settings, not us in some internal log.
  • If you tell us someone else got into your account, we can sign out every device immediately and lock the account for a few hours. We do not look at your data while doing it, and we will not set a new password for you — that stays yours alone.

When you break something yourself

The most common data loss is not an attack but a typo. So almost everything can be undone.

A backup before every publish

Each time you publish, the state of the site is saved — every page and the design. How many we keep depends on your plan; you restore them yourself, and a restore either completes or does nothing — never halfway.

Twenty versions of every page

Each page keeps its last twenty versions. Stepping back is one click, not a plea for help.

The original photo for a month

We shrink photos so the site loads fast, but we keep the original for a month. If a resize goes wrong, there is something to start from again.

Backups belong to a site, not an account

With several sites under one account, each keeps its own line of backups. Publishing one site never touches the others — a test enforces it, not just tidy code.

A deleted photo goes to the bin

A photo deleted in the gallery is held aside for thirty days before it goes for good. A misclick is not the end — unlike closing your account, which stays irreversible.

A weekly copy of everything

Once a week everything in your account — pages, posts, orders, bookings, subscribers, forms and module settings — is set aside in storage. We keep the last eight weeks plus the first copy of each month for a year.

The sites you build here

Security is not only about your account. People visit your site and they have to be safe too.

  • On every published site the browser is forbidden to run a script that does not belong there. It is not enough that we keep foreign code out — if that ever failed, the browser stops it as well.
  • Content proposed by AI is not filtered but rebuilt from allowed elements only. What our list does not know has no way into the page, because nothing is copied verbatim.
  • Analytics and marketing scripts are placed on the page switched off and start only once the visitor consents. Consent is not a picture over the screen — until someone gives it, nothing is measured.
  • Forms are protected by a visitor check against bots, a hidden trap for spam programs and a limit on messages from one address.
  • Only images can be uploaded, and at most five megabytes. The file type is read from its contents, not its name, so an executable renamed to look like a photo does not get through. Uploaded files are also served in a way that cannot run code, even if someone smuggled some inside.

Payments

  • Your card number is never here. Stripe handles the payment on its side and we only learn that it went through.
  • Messages from the payment gateway are verified by signature — without one they are discarded. A forged “paid” message unlocks nothing.
  • The same message delivered twice is counted once.
  • When you sell through your site, the money goes straight to your own Stripe account and never passes through ours.

When something goes down

  1. A published site keeps running even when our database is out. Finished pages sit as files in storage and serving them asks nothing of the database. Editing stops working, your site does not.
  2. A query that fails because the database is just waking up is retried on its own. The user never sees it.
  3. When the fault is on our side, we say so. In July 2026 an exhausted database quota showed up as “wrong password” — people thought they had forgotten it while the fault was ours. Since then we tell the two apart, and failures are reported to us by email.

What we do not have yet

A security page where everything is solved is not credible. Here is what we are missing, and we know it.

  • Our own two-factor step for Google sign-in. When you sign in with Google, the second step is handled by Google, not by us — our code from the app is not required in that case. We recommend turning two-factor authentication on for the Google account itself.
  • A strict content rule for the admin is watching, but not yet blocking. The photo editor computes in your browser and loads part of a library to do it; before we switch the rule on for real, we measure it in everyday use so that it does not block something you need.
  • An independent security audit. We review the code ourselves and automated checks enforce part of the rules, but we have not paid for an outside review.
  • A guaranteed uptime figure. We do not promise percentages we could not prove. If there is an outage, you will hear it from us.

Found a problem?

Write to info@webeas.com. We take reports seriously, reply within 48 hours, and will not pursue anyone who reports a vulnerability in good faith. We do not pay bounties yet — when we can, it will say so here.

info@webeas.com

Trying it costs nothing

The account is free and commits you to nothing. You can download your data and leave with it any time.

Build your site free Free forever · no card needed · cancel anytime

We measure traffic with Google Analytics — it only runs with your consent and rejecting is just as easy. It is the same banner every site on Webeas gets. Privacy policy